AI Office Clones 🚀: Can WordCraft & GridCraft Replace 365?

The three apps at a glance

• WordCraft focuses on document creation and editing. It reads and writes .docx files and reports support for features like track changes, footnotes, citations, and mail merge.
• GridCraft focuses on spreadsheets. It reports support for 513 of Excel's 523 worksheet functions and 89% of its ribbon commands.
• DeckCraft focuses on presentations. It opens and saves .pptx files, supports transitions and animations, and can export to PDF. The project reports it hasn't reached its first alpha release yet.

Those percentages reflect reported coverage, not a promise that every feature behaves identically to Office. File formats are messy in practice, and matching a button name - or even a formula name - doesn't mean you've matched every edge case, formatting rule, or output detail.

Clean-room development is not copying Microsoft's code

Thomas describes the work as a clean-room rebuild: the apps were written based on public file-format specifications and observations of how the original products behave, rather than by copying Microsoft's source code. That matters. Reimplementing a file format or workflow isn't the same thing as redistributing a competitor's proprietary code.

The source compares the approach to Compaq's clean-room work on the IBM PC BIOS. It's a helpful example of the general idea, but it's not a legal verdict on these particular projects. Open-source licenses also don't automatically settle every issue around trademarks, interface design, patents, or how a product is marketed. If you're building something commercial here, you still need qualified legal advice and a careful review of both the code and the licenses.

For users, the takeaway is simpler: open source lets you inspect, modify, and redistribute code under the license terms. It doesn't automatically prove an app is secure, stable, compatible, or safe for confidential work.

WordCraft: promising coverage, incomplete assurance

WordCraft reportedly covers 88% of Word's ribbon features. It reads and writes .docx files and has implemented functions that matter in professional workflows, including track changes, footnotes, citations, and mail merge.

That's a real start. But it's not the same as dependable document interchange. The project roadmap reportedly still includes testing against real-world .docx files, improving page layout, making sure charts and SmartArt survive saves, improving stability, and adding native printing before beta.

For a short internal note or a basic draft, those gaps might be fine. For a contract with tracked edits, a report with carefully controlled page breaks, or a letter sent to hundreds of recipients, they can become your problem fast. In other words: the cost of a formatting error depends on the document, not on the percent of ribbon buttons implemented.

GridCraft: formulas are only one part of spreadsheet compatibility

GridCraft's reported 513-of-523 function coverage sounds close to Excel's set. It also reports 89% coverage of ribbon commands. But the developers estimate it's only about 50% ready for real work, and compatibility with real-world .xlsx files is still a priority.

That gap makes sense. A spreadsheet is often more than "cells and formulas." It's formatting, named ranges, charts, imported data, hidden sheets, external references, and years of user-specific assumptions. A function count can't tell you whether the entire workbook calculates correctly after import, edit, and export.

If you try a spreadsheet clone, treat it as unverified until you test it with copies of workbooks you actually use. Compare calculations against known outputs, inspect charts and conditional formatting, then save, close, and reopen in both applications. If the workbook drives payroll, budgets, reporting, or operational decisions, test changes in a controlled copy - not the production file.

DeckCraft: feature counts do not equal presentation fidelity

DeckCraft reportedly covers around 79% of PowerPoint's features and 93% of core features. It can open and save .pptx files, run transitions and animations, and export to PDF. For simple decks or early experimentation, those capabilities could be enough.

But presentation software is judged by what you ship. Fonts, image crops, line breaks, alignment, and animation timing can change the look of a slide on another system. And since the source reporting says DeckCraft hadn't reached its first alpha release yet, it should be treated as an early project, not a tool you'd trust for a high-stakes presentation.

A fair conclusion isn't "these apps are bad." It's that their progress looks impressive for the time invested, while the gap from "a feature exists" to "it behaves reliably across documents" is still substantial.

Faster implementation is not the same as lower total cost

Teams often underestimate the work after a feature first appears to work. A real product needs test coverage, accessibility, error handling, documentation, migration paths, security review, release processes, and support for users whose files don't match the "happy path."

AI can help generate tests and code, but it can also generate plausible mistakes quickly. The bottleneck shifts: less time goes into the initial implementation, while more time needs to go into reviewing behavior, validating compatibility, and understanding how features interact. The total effort depends on what verification can be automated - and how expensive a defect would be.

For a personal tool, a bug might be an annoying afternoon. For a business document or spreadsheet, it could mean a missed change, an incorrect figure, or a broken deliverable. The acceptable level of confidence isn't the same.

Agent integration raises the stakes

The projects reportedly expose application controls to AI agents through MCP (the Model Context Protocol). In practice, an AI assistant could potentially perform actions like creating a chart in a spreadsheet or reformatting a report inside the application - not just suggest steps for a person to follow. You can read about MCP at the official Model Context Protocol site.

This is a sensible direction for software design: if actions are exposed in a structured way, an agent can work with application features rather than relying entirely on screenshots and mouse clicks. But it raises serious security and reliability questions. Which files can the agent access? Can it overwrite or export data? Does a person confirm consequential changes? Is there an audit trail and a reliable undo path?

Those questions matter for any agent-enabled office app. Convenient automation can become a data-loss risk if permissions are too broad and actions are hard to review. The better design isn't "let the agent do more" - it's "give it bounded permissions, visible actions, and human approval when the consequences matter."

Use a risk-based trial, not a big-bang switch

A sensible evaluation can happen in stages:

1. Choose a low-risk use case. Start with a basic document, spreadsheet, or presentation that you can recreate if something goes wrong.
2. Use a copy of a real file. Include representative formatting and features, but remove personal, client, or confidential information unless you've checked the app's security and data handling.
3. Test the full round trip. Open the file, make changes, save it, reopen it, and compare the result in Microsoft Office (or another trusted viewer).
4. Check the details that matter to your workflow. For Word, look at revisions, page breaks, and citations. For spreadsheets, validate key calculations and charts. For presentations, compare layout and exported output.
5. Repeat before relying on it. One successful file is a good sign, not proof of broad compatibility. Test a small set of different files and note where the app struggles.
6. Keep a rollback path. Preserve originals, and decide which application stays authoritative while the trial runs.

This approach makes the evaluation cheaper and more informative. You're not asking whether the app is "good enough" in some abstract sense. You're testing whether it's reliable for your specific workflow - and what the downside looks like if it fails.

When Microsoft 365 remains the pragmatic choice

If your work depends on advanced spreadsheet models, collaborative editing, strict document fidelity, accessibility features, macros, specialized templates, or formal support, Microsoft 365 is likely the lower-risk option today. That doesn't automatically justify the subscription price for every user - it just means paying for proven compatibility can be worth it when failure would interrupt important work.

If your needs are mostly straightforward documents, simple formulas, and basic slides, a free alternative may eventually cover enough. For now, the alpha and pre-alpha status described in the source means a trial makes sense - but a blanket "replace Office" recommendation doesn't.

The same logic applies to any AI-built product. Ask what it does reliably, what it doesn't, who maintains it, and how you'll recover when something breaks. A compelling demo is evidence of progress, not a service-level promise.