Most of what we publish argues that teams underinvest in documentation. This post is the other argument. It's the one we make on sales calls when we're trying to talk a prospect out of hiring us.

Some of you should not be hiring a documentation agency right now. Here is how to tell, written by the agency you would have hired.

The pitch that's usually right, and sometimes isn't#

"AI-ready documentation" has hardened into a category with a universal pitch: every doc set needs it, every company should fund it, every month of delay compounds. We believe that pitch more often than not. We also watch it get sold into rooms where the money would do more good somewhere else.

This post names the specific conditions where the investment is premature, misdirected, or actively counterproductive, and what to fund instead. If you see your company in one of these cases, close the tab, keep the budget, and come back when the shape of the problem changes. We would rather lose the deal than take it and watch it fail.

Four cases where it's the wrong move#

1. You're pre-product-market-fit#

If the product is still finding its shape, documentation freezes a shape it isn't ready to keep. Every rewrite costs you the last rewrite, and the cost is not just dollars: it is the quiet tax of a team defending pages that no longer describe the thing they are building.

You're in this case if you recognize two or three of these: under a few hundred active users, a pivot or meaningful repositioning in the last two quarters, feature surface changing monthly, pricing still in flux, a founder still running most demos personally. At that stage, polish is a distraction and it ossifies decisions you are not ready to make.

What to fund instead:

A /docs folder in the repo that a new user can follow without Slacking the founder.
A README that gets someone to first value in under ten minutes.
Three Looms: install, core workflow, the thing everyone gets stuck on.
A standing calendar reminder to revisit this list when active users cross a threshold you pick now.

Come back when the product stops moving under the writer's feet.

2. You have fewer than fifty active users asking questions#

The ROI math we've written about elsewhere does not survive low query volume. Retrieval quality, structured content, semantic chunking: all of it is machinery for serving questions at scale. If nobody is asking the docs questions yet, the machinery runs empty.

You're in this case if your support inbox gets fewer than a handful of doc-shaped questions a week, if your analytics show a long tail of single-visit pages and no repeat search terms, or if you cannot name the top five questions your users actually ask. The budget that would fund a doc overhaul is better spent on ten customer conversations that tell you which pages will matter once traffic shows up.

What to fund instead:

Run onboarding yourself, on video calls, until you've done it twenty times.
Write down the three questions you keep answering. Those are your first three pages.
Instrument your docs site and your support channel so that when volume arrives, you can see which pages deserve the real investment.

Three pages written from real conversations beat fifty pages written from a content brief.

3. Internal-only tools with a fixed human audience#

If the audience is twelve people in your org and they sit three desks away, AI-ready documentation is overkill. Internal tools benefit from runbooks, diagrams, and decision records. None of those need retrieval optimization. The reader context the category is designed for, thousands of anonymous users hitting a retriever, does not exist in your building.

You're in this case if the tool is not exposed to customers, the user list is stable and nameable, and onboarding a new user is a conversation rather than a funnel. The work to do is real; it just isn't the work an AI-ready docs engagement is shaped for.

What to fund instead:

Architecture decision records, written when the decision is made, not after.
One-page runbooks for the five things that break.
A culture of writing things down, enforced by whoever reviews PRs.
A searchable home for the above, whether that's a wiki, a repo, or a Notion space. Not a publishing stack.

One caveat worth naming: if an internal AI copilot, an agent, or an LLM-powered search tool is pointed at this corpus, the calculus shifts. Retrieval quality suddenly matters, because the consumer is no longer twelve humans who can ask each other; it is a model that will confidently hallucinate when the source material is thin. In that case you are back in scope, and you should tell us.

4. You're about to deprecate the product#

This one sounds obvious and we see it more than we'd like. A team about to sunset a product line funds a documentation overhaul because the internal metrics say it's overdue. It was overdue two years ago. Funding it now is an expensive way to feel responsible.

You're in this case if the product is in maintenance mode, if the roadmap names a successor, if engineering headcount on it has been cut, or if the renewal conversations have turned into migration conversations. The right investment is a graceful wind-down, not a rebuild.

What to fund instead:

A migration guide that respects the customers who stayed.
A freeze date for the existing docs, published, honored.
Deprecation notices with real timelines on the pages that will outlive the product in search results.
The successor product's docs, done properly from the start.

The kindest thing you can do for a sunsetting product is stop pretending it has a future.

The meta-case: opportunity cost#

Even when AI-ready docs is the right investment in isolation, it competes for the same budget as customer research, a support hire, better onboarding tooling, a developer advocate, or a design pass on the product itself. We have watched teams fund a documentation overhaul when the money should have gone to a second support engineer. The docs needed the work. Support needed it more, and the support engineer would have taught us what the docs should say.

A rough sequence that holds up across the companies we've worked with:

If you can't name your top ten user questions, fund customer research first.
If support is drowning, fund support tooling or a support hire first.
If onboarding loses users in the first session, fund onboarding first.
If none of the above is true and your docs are the bottleneck between users and answers, fund the docs. That is where we come in.

AI-ready docs is not a universal good. It is one investment among several competing for the same headcount. Fund it when it is the highest-leverage move on the board. Do not fund it because the category is hot.

What the right investment looks like when it isn't us#

A short list, not exhaustive:

Customer research. If you don't know what your users ask, docs won't save you.
Better onboarding. A ten-minute onboarding flow does more than a five-hundred-page doc set for most products under ten thousand users.
Support tooling. If support is the current bottleneck, fix support first and let the ticket data tell you what to document next.
A hire. Sometimes the right documentation investment is a developer advocate, a technical support engineer, or a solutions architect who happens to write well. Title on the job req matters less than the work that gets done.
A product fix. If the same question keeps arriving, the answer is sometimes a better empty state, not a better doc page.

Any of these can be the highest-return move for a quarter. None of them are us. We are fine with that.

Closing#

A good agency says no more than it says yes. If the honest answer is that you should not be hiring us right now, you just read it. We would rather you spend the next two quarters fixing the thing that actually blocks your users and come back when the math works than take your money today and deliver a doc set that sits unread.

Come back when the product is stable, the users are asking, and the money is the best money you can spend that quarter. We will be here, and we will remember you said no first.