I Automated Everything Except the Docs My Users Actually Read

Last week I shipped an entire invoicing feature — database migration, API endpoints, frontend UI, tests — in a single afternoon. Claude Code wrote the migration, an MCP server handled the Stripe integration, and CI deployed it before I finished my coffee.

Then a user emailed: “How do I create a recurring invoice?”

I stared at the message for a long time. I had automated literally everything about building this feature except explaining it to the person who needed to use it.

The 2026 Workflow Has a Blind Spot

If you’re building with MCP tools and AI coding agents, your workflow probably looks something like this: describe what you want, review generated code, run tests, deploy. The loop is tight. Developers are reporting full MVPs in a day — database setup, email integration, auth flows — all without leaving the terminal.

But here’s what that workflow produces: working software with zero user-facing documentation.

The irony is sharp. We’ve automated the hard part (building the thing) and left the supposedly easy part (explaining the thing) completely manual. And then we wonder why our support channels are noisy and our onboarding metrics are bad.

”Auto-Generated Docs” Solves the Wrong Problem

When developers hear “auto-generated documentation,” they think Sphinx, Doxygen, or Docusaurus. These are solid tools. They parse your code comments and produce API references. But API references are developer docs — they explain what createInvoice(params: InvoiceInput) accepts and returns.

Your users don’t care about InvoiceInput. They care about “How do I create a recurring invoice?”

There’s a fundamental gap between code-level documentation and user-facing help content. One is generated from source code. The other requires understanding what the application looks like, what buttons exist, what flows are possible, and how to explain them in plain language.

Most auto-doc tools sit firmly on the code side of that gap. They’re built for developers documenting libraries, not for product teams documenting applications.

What User Docs Actually Require

Writing good user documentation means you need to:

1. Navigate the actual application — click through every screen, every state
2. Capture what users see — screenshots of real UI, not code abstractions
3. Describe workflows in plain language — “Click Settings, then Billing, then Add Payment Method”
4. Keep it current — every UI change invalidates existing screenshots and instructions

This is why user docs rot so fast. It’s not that developers are lazy. It’s that the process is inherently manual and tedious, and it competes with shipping the next feature. When your sprint has 12 tickets and “update help docs” is ticket 13, it never gets done.

The Missing Piece in the MCP Toolchain

The MCP ecosystem has filled in most gaps in the developer workflow. Need to query a database? There’s an MCP server for that. Need to manage GitHub issues? MCP server. Need to interact with Figma designs? MCP server.

But generating user-facing documentation from a running application? That’s been conspicuously absent — until recently.

KodaDocs takes a different approach to auto-generated docs. Instead of parsing source code, it launches your app in a headless browser, discovers routes, captures screenshots, extracts DOM elements, and generates help articles based on what users actually see. The output is a static VitePress site with annotated screenshots and step-by-step guides.

Because it works as an MCP server, it fits directly into the Claude Code workflow:

# Install and configure as an MCP tool
uvx kodadocs mcp

# Then from Claude Code, the tools are available:
# - detect_framework: identifies your project type
# - discover_routes: finds all navigable pages
# - capture_screenshots: headless browser captures of each route
# - assemble_vitepress: generates the full docs site

The key difference: it documents the application, not the code. It sees what your users see.

The Real Cost of Missing User Docs

I used to think skipping user docs was a reasonable trade-off. Ship fast, handle support questions as they come. But the math doesn’t work out.

Every undocumented feature generates a predictable stream of support requests. Each request costs 10-15 minutes of context-switching. Over a month, a single missing help article can cost you an entire day of engineering time.

For solo developers and small teams, this is worse — you’re the support team and the engineering team. Every “How do I…?” email is time stolen from building.

The teams I’ve seen move fastest aren’t the ones who skip docs. They’re the ones who’ve automated docs the same way they’ve automated tests: it happens as part of the build, not as an afterthought.

Making Docs Part of the Build

The pattern that works is treating documentation like you treat your test suite: it runs automatically, it breaks visibly when things change, and it’s never a separate ticket.

If you’re already using MCP tools with Claude Code, adding documentation generation to your workflow is one more tool in the chain. Ship the feature, run the docs pipeline, deploy both together. Your users get help content that matches what they actually see in the app, and you never have to manually screenshot a settings page again.

The 2026 developer workflow has automated almost everything. It’s time to close the last gap — the one your users actually notice.

---

KodaDocs is an open-source tool that generates user-facing help documentation from running web applications. Check out the GitHub repo to try it on your project. See how it works, compare it to Mintlify or GitBook, or follow the zero-to-docs guide.