A documentation platform subscription buys an editor, hosting, search, and a deploy workflow. It also buys a count of seats or sites. These are the parts a vendor can deliver as software.
The subscription does not buy the work that fills those pages. Someone on your team still has to learn what changed in the product. That person decides how to explain the change. They write the page and update the examples. They get the page reviewed. They publish it. Then they do the work again after the next release.
The recurring work is where the larger cost sits. The license fee is a fixed number on an invoice. The hours your team spends writing and updating documentation grow with every release. Every release adds a set of changes that someone must document. Those changes compete for attention with the engineering work that produced them. When documentation falls behind, the people who need it find outdated instructions. The support team fields questions that a current page would have answered. The gap between the product and its documentation widens until someone finds time to close it.
A documentation platform that includes the maintenance changes who owns the recurring work. The vendor’s agents do the writing and publishing. They update the documentation after each release. Your team supplies product context and approves changes instead of producing them.
What you buy and what you still owe
The demo shows a finished documentation site. The pages are written. The examples work. The search returns useful results. You sign up based on that demo. The purchase delivers an empty workspace.
The finished site in the demo was built by someone. After you sign up, that someone is your team. The platform gave you the tools to render and host pages. The content on those pages is still your responsibility.
This split is easy to miss during a sales conversation. The demo answers the question of whether the platform can display a good site. It does not answer the question of who produces the pages on that site. The second question is the one that determines your ongoing cost. A vendor that shows a polished demo and then hands you an empty workspace has kept the easy part and given you the hard part.
When the platform includes the maintenance
A platform that includes the maintenance changes the division of work. Your team supplies product context. You approve each change before it publishes. The vendor’s agents write the pages and publish the changes. They update the documentation after each release.
A buyer should not take that claim on trust. You can verify it by checking what the vendor shows you. Ask to see what changed in a recent update. Ask to see the source behind a change. Find out whether you can flag a problem in plain language. Confirm that approval follows your own policy rather than a vendor default.
The verification matters because the claim is about work, not features. A feature list tells you what the software can do. A record of changes with their sources tells you who did the work that produced those changes. If a vendor claims to maintain your documentation but cannot show you the changes and their sources, the claim is about the software, not about the labor.
Questions that show who owns the work
Some questions, asked of any vendor, reveal where the recurring work actually lives. Ask how soon the first usable version of your documentation arrives. Ask how much of your time the review process takes. Ask how accuracy is tested. Ask what happens when the product changes. Ask how corrections are handled. Ask who owns the files. Ask how the arrangement grows with your program.
A vendor that owns the work has specific answers. The first draft comes from your existing material. Review happens as a reader, not as a writer. Every change is visible with its source. The agents update the documentation after every release. Corrections go to you for approval. The files are plain files that you own. The offering scales with your program through tiers that match program size.
A vendor that has handed the work back to you answers differently. The answers describe what your team needs to do. They point to the editor and the workflow you bought. They explain how your writers use the platform. The work of producing documentation stays on your side of the arrangement.
| Ask the vendor | A vendor that owns the work | A vendor that hands it back |
|---|---|---|
| How soon does the first usable version arrive? | From your existing material | After your team writes it |
| How much of our time does review take? | Reading as a reader | Writing and editing |
| How is accuracy tested? | Every change shown with its source | Your reviewers |
| What happens when the product changes? | The agents update the pages | Your team updates the pages |
| How are corrections handled? | Sent to you for approval | Made by your team |
| Who owns the files? | You, as plain files | You, inside the tool |
| How does it grow with the program? | Plans sized to the program | More seats |
Where this approach has limits
This approach depends on the quality of the product context you supply. The agents write from the material you give them. Sparse or outdated context produces sparse or outdated pages. You remain responsible for the accuracy of the source material.
The approach also depends on your review process. The agents produce changes. Your team approves them. A review process that moves slowly will slow the documentation even when the writing is fast. The agents do not replace your judgment about what to publish. They replace the labor of producing each draft.
A team that writes its own documentation and keeps up with every release may not need this arrangement. The arrangement helps the team that falls behind on documentation after each release and cannot catch up before the next one arrives.
What SaturnDocs does
SaturnDocs is a documentation platform built for the AI agents that now read your docs, and for the people who still do. The agents produce a first draft from your existing material. They write every page and publish each change. They update the documentation after every product release. Every change is visible with its source, and corrections go to you for approval. Your files are plain Markdown files that you own. You supply product context and approve each change before it publishes.
If you want to see how a draft arrives and how a review works, we will set up a session with your own material and walk through it with you.