The day you find out what you actually own is the day you try to leave. You go looking for the export button, and what comes back is HTML soup, or a dump of some proprietary block format that doesn't map onto anything, or a ZIP of assets with the structure flattened out of them. The content you wrote is technically in your hands. The documentation — the thing with navigation, search, versioning, the AI layer — stays behind, because it was never a file you owned. It was a view the platform rendered for you, and the rendering doesn't come with you.
Most teams discover this at the worst possible moment: pricing changed, the product got acquired, a feature you depend on got deprecated, or you simply outgrew the tool. By then the migration is a project with a timeline, and during that timeline your docs are in two places, half-broken, while every AI agent and search crawler reading your product gets a worse answer than they did last month.
The fix isn't choosing a "better" proprietary platform. It's choosing tooling where lock-in was never possible in the first place. Here's what to look for.
The three things you need to own
Documentation isn't one asset. It's three, and a portable setup keeps all three in your hands:
The source of truth. Your docs should be plain Markdown or MDX, in a Git repository you control, edited with any tool you like. If the canonical version of a page lives only inside a vendor's WYSIWYG editor and a database you can't query, you don't have a source of truth — you have a cache of one.
The build and deploy. You should be able to turn that source into a running site yourself, with a command you can read, and host the result wherever you want. If the only way to publish your docs is through the vendor's pipeline to the vendor's infrastructure, the vendor owns your uptime.
The retrieval surface. Search, the AI assistant, the MCP server, llms.txt, the per-page Markdown mirrors — the layer that makes your docs usable by machines. If that's bolted onto the vendor and rebuilt from scratch the moment you leave, then leaving means going dark for AI agents until you've rebuilt it. In an era where agents read your docs to write integrations against your product, that's not a cosmetic gap.
A tool that hands you all three is a tool you can walk away from on a Tuesday afternoon. A tool that hands you one of them — usually a mediocre export of the source — is one you're locked into, regardless of what the marketing page says about "your content, your control."
The lock-in checklist
Before you commit to any documentation tool, run it through these questions. The honest ones answer all of them "yes" without flinching:
Not "exportable to Markdown" — authored as Markdown, living in a repository you own, where git log is the edit history and a pull request is the review workflow. If the answer involves a proprietary editor as the only first-class way in, the source isn't really yours.
There should be a command — open source, inspectable — that takes your Markdown and produces the site. If you can run it on your laptop and in your own CI, you're not dependent on the vendor's pipeline staying up, staying affordable, or staying in business.
A static site or a plain Next.js app you can deploy to Vercel, Netlify, Cloudflare, or your own box is portable. A bundle that only runs inside the vendor's hosting environment is a hostage. Ask what the build produces, not just what it looks like.
Your docs should live on your domain (docs.yourcompany.com), with your SSL, from the start — not on a vendor subdomain you'll have to migrate off later, and not behind a pricing tier that charges rent for the privilege of using your own name.
If you switch tools, can you take the search index, the AI assistant config, the MCP endpoint, the llms.txt artifacts? Or do they evaporate? The retrieval surface should be generated from your source, by something you can run, so that moving the source moves the surface with it.
Add it up honestly: re-platforming the content, rebuilding navigation, re-pointing the domain, regenerating the AI layer, the redirects, the period where docs are half-migrated. If that number is large, you're locked in now — the contract just hasn't been called yet.
Why this matters more than it used to
Lock-in used to be an inconvenience you'd absorb every few years. It's getting more expensive, for a structural reason: your documentation is increasingly the interface between your product and the people building on it. Developers integrate by asking an AI agent, the agent reads your docs, and the integration code reflects whatever the docs said. When your docs are mid-migration — split across two platforms, half the redirects not in place, the retrieval surface rebuilt from scratch and not yet warm — every agent reading your product during that window writes against a worse picture of it. You don't see those integrations break. They break in your customers' repos, weeks later, as support tickets you can't trace back to the migration.
Critical infrastructure that you don't own is a risk you can't model. Documentation became critical infrastructure when agents started reading it as runtime context. The conclusion follows: own it.
How Doccupine is built around this
Doccupine is two products, and both are designed so that walking away is always possible:
The CLI (npx doccupine) is open source. It watches a directory of MDX files — yours, in your repo — and generates a complete, ordinary Next.js documentation site: navigation, theming, AI chat, MCP server, sitemap, robots.txt, llms.txt, per-page Markdown mirrors, all of it. You can run that build on your machine and deploy the output to any host that runs Next.js, for free, with no account. Nothing about the source is proprietary; it's MDX and a handful of JSON config files you can read in a minute.
The hosted platform is for teams who'd rather not run that pipeline themselves — it provisions a GitHub repo, deploys to production, manages your custom domain, handles billing and auth and team roles, runs the pending-changes review workflow, and gives each user their own AI keys. But the repo is yours (managed or your own, your choice), the content is the same MDX, and the moment you want out you git clone and you have everything. The free tier carries a small "Powered by Doccupine" footer; paid tiers don't. That's the upgrade — convenience and your own brand, not access to your own content.
The point isn't that you'll leave. It's that a tool worth using doesn't need to trap you to keep you.
If you're untangling a docs setup that locked you in harder than you expected, I'd genuinely like to hear how it went — the details help us keep our own answer to that "cost of leaving" question honest. I read every reply at [email protected].