Can you vibe code a DOCX editor for $200?

Quick Answer: A weekend with Claude will get you a browser-based editor that opens a .docx, renders the paragraphs, lets you type, and saves it back out. That part is real and it is genuinely impressive. What the $200 does not cover is the rest of the OOXML spec, the security work that comes with accepting files, the round-trip problem, and someone who understands the whole thing for the 2am fire drill. Generating code got cheap. Owning code did not.

I recently found this comment under a demo video for the Apryse DOCX editor:

"You can vibe code one better than that one with Claude so it will probably cost you 200 and you are better off doing that way since people are definitely gate keeping code that is technically free to make."

I think there are a lot of people excited about the possibilities of where we are with vibe coding. I hate to ruin a good buzz but can't resist bringing a bit of sobriety into this conversation. Sadly, the reality of owning code is never quite as fun as the imagination phase.

What does a weekend and $200 actually get you?

Quick Answer: Real code that runs. A .docx is a ZIP file full of XML, so pulling paragraph text out of document.xml is genuinely an afternoon's work, and what comes back opens real files and saves them again. But there is quite an expanse between "working" and great code. The distance between them is ECMA-376: several thousand pages, of which your weekend covered whatever your test file happened to use. Almost none of the rest is exotic.

Here is what is sitting past that quick vibe output, and none of it is unusual. This is just Tuesday for anyone who works on documents:

• Numbering. Abstract definitions, concrete instances, per-level overrides, and restart semantics that nobody agrees on.
• Styles. Inheritance running from document defaults, through linked and latent styles, down to direct formatting on a single run.
• Section properties. Which can change halfway down the file, because of course they can.
• Tables. Vertical merges expressed as continuation flags on the cells below rather than on the cell doing the merging.
• Fields. Storing both a cached result and the recipe to recompute it, so you have to decide which one you believe.
• Everything else. Footnotes, content controls, equations, bidirectional text, embedded objects.

None of that is hidden from you. It is just a whole lot more work than people are expecting to do when they "open a .docx".

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time. - Tom Cargill, Bell Labs

Why does every "can it also do..." request cost more than it sounds?

Quick Answer: Because the cost of saying yes collapsed but the cost of the resulting system did not. Version 0.1 gets shown around, the requests come back, each one sounds like an afternoon, and each one lands somewhere much larger than the person asking realizes.

Where those small requests actually land:

• "Can it do numbered lists?" Abstract versus concrete numbering, level overrides, restart rules, list styles.
• "The indents look wrong." Indent resolution and tab stops. Congratulations, you are now maintaining a layout engine.
• "Print it exactly like Word." Line breaking, font metric substitution, widow control, keep-with-next, rows splitting across pages.
• "Keep the tracked changes." Insertion, deletion, move and format revisions, and every single edit your editor makes now has to be expressible as one of them.
• "Where did the comments go?" See the round-trip section. This one is the mean one.

Six weeks later there are twenty thousand lines in the repo and you have read maybe three thousand of them. The three thousand that broke.

What if you don't control what is uploaded?

Quick Answer: The moment you accept uploads, you have an endpoint consuming arbitrary compressed XML sent by strangers. That is one of the more hostile input classes in computing.

A few of the vulnerability classes to consider:

• XXE. Your XML parser will read files off your server unless somebody explicitly told it not to.
• Decompression bombs. A few kilobytes of ZIP that expands to gigabytes.
• Zip slip. Archive entries containing ../, writing wherever they like the second you extract to disk.

Every one of those appears in the CVE history of every mature document library, found the expensive way - by someone else, years ago.

What is the round-trip problem?

Quick Answer: The failure people brace for is a crash. The failure that actually happens is silent. If you parse a document into your own model and serialize it back out, it drops everything your model did not know about - with no error report in sight.

Someone opens a contract in your editor, changes one word, saves. The tracked changes are gone. So are the comments, the custom XML bindings a downstream system reads, the content controls, and the numbering that survived four rounds of legal review.

The file opens fine. Word does not complain. It simply is not the same document anymore, and nobody finds out until the moment it matters most.

Preserving the parts you do not understand is much harder than parsing the parts you do. No prompt is going to tell you which parts you did not understand, because by definition, you didn't ask.

Can you maintain code you have never read?

Quick Answer: Software cost lives in maintenance, and maintenance cost is a function of comprehension. Code generation drives the writing cost way lower but it does nothing for the comprehension cost. In fact it most likely makes comprehension worse, because writing the code is how you would otherwise have learned the code.

The question at the point of failure is never "can Claude fix this." It is "do I understand this system well enough to know whether that fix is right, or whether it just moved the bug somewhere I am not currently looking."

Writing scales with the model. Debugging still scales with you. Even after coding for many years, I still struggle to remember exactly what I meant in every line of code that I actually wrote - much less trying to decipher where the AI went wrong on something I had nothing to do with.

Is anyone actually gatekeeping this?

Quick Answer: No, and this is the part of the comment that holds up the least. Plenty of sources out there. LibreOffice is open. So are docx4j, python-docx and a dozen readable OOXML implementations. Nobody is hiding the code, because the code was never the scarce part.

Everyone deserves to be paid for their work. When you make the call to buy vs build, it's rarely because no one is capable of building it. You pay to keep your dev resources focused on solving your own business problems. You pay for that other company to be the expert for your team.

That expert brings years of experience with:

• The zillions of real documents produced by 20 years of Word versions and every third-party generator that emits technically invalid XML which Word renders anyway.
• The bug report from the customer whose merged table cells collapse only at 120% zoom.
• Somebody to call when a filing renders wrong just before the deadline.
• The unglamorous rest of it: security review, indemnity, accessibility conformance.

This is not about a goblin wildly guarding lines of code while sitting on a pile of your money. This is just the part you cannot prompt into existence because it is not code. It is lived, often traumatic, experiences that you are paying to skip entirely. ...and it's often worth every saved minute of your time and avoided suffering.

Toss this problem back over the fence? Yes please, and thank you.

So when should you build it yourself?

Quick Answer: Frequently. For a great many jobs, spending $200 and a weekend is exactly the right call. Not every tool needs to reach perfection or hold up under long term testing and maintenance stress.

Build it yourself when:

• You control the whole workflow, use your documents, and you know exactly how the in and out points need to function.
• Your company or workload is small, no need to over-engineer for something that doesn't need to scale.
• "Wrong" costs a redo, not a lawsuit.
• Nobody outside the building is uploading anything, or more specifically, you can entirely trust the users of the system.
• You would be happy to delete the whole thing next quarter. Throw it up, try it out, and no one is upset when you scrap it for the next iteration.

Reach for something battle-tested when:

• The inputs are other people's documents, arriving from anywhere, in any state.
• The data is other people's data, with residency or compliance rules attached.
• The deadline is other people's deadline, and the failure lands on them. ...or worse, lands on you.
• You need enterprise level scaling. There is no point in starting over on trying to account for every edge case an enterprise-level roll out will turn up.

Where should you start?

1. Build the weekend version anyway. It is the fastest way to find out how much of the format your use case actually touches.
2. Round-trip a really complicated document early. Tracked changes, comments, content controls. Save it, reopen it in Word, and see what quietly vanished.
3. Read the code you shipped. All of it, or at least enough to know which parts you have not read.
4. Decide which 90% you are in for. The first 90% is a weekend now, which is legitimately worth being excited about. The second 90% is the whole rest of your job.

If you get to step 4 and only have interest in that first 90%, then that is when a document SDK earns its keep. You can try ours for 30 days at docs.apryse.com/guides/get-started.

If you're on step 4 and think, "I've got this," go forth and prompt away! Then come back and tell me what broke. I have no doubt the answers here will keep changing as things advance - I'm super interested to see where we are.

Disclosure: I work for a company that sells document SDKs, so weigh all of the above accordingly. The vulnerability classes and the round-trip problem are real either way. Go check them against whatever you build.