Every time a team justifies documentation spend, they reach for the same shortcut: "for a fraction of the cost of an engineer." That sentence is true and tells you nothing. It is the kind of claim that makes finance teams suspicious, and they are right to be.

Here is a model with the variables named, the assumptions on the table, and the arithmetic exposed. A CFO should be able to plug in their own numbers and get an answer they can defend in a board meeting.

The shape of the argument#

Documentation has a measurable ROI, but it is a function with four variables and two decay rates, not a flat multiplier. Most "ROI of docs" arguments pick one variable, hold the other three constant, and call it a case. We will build the whole model, including the parts that weaken it, so the parts that strengthen it hold up under scrutiny.

The conclusion up front: for a mature doc set, a small subset of pages carries the economic case. The rest operate at negative ROI and should be managed accordingly. That is not a flaw in the model. It is the decision the model is built to support.

Four variables, named#

We use four inputs. Give each one a letter so the equation at the end is legible.

Symbol	Name	What it measures
Cp	Cost of production	Fully loaded hours to ship one page, times blended rate
Cm	Cost of maintenance	Fully loaded hours per page per quarter to hold quality steady
Cw	Cost of a wrong answer	Expected dollar cost when the AI or the docs answer incorrectly
Q	Query volume	Times per month a user asks the AI or searches for this page's content

Cost of production (Cp)#

Hours to produce one page, fully loaded. The writer, the engineer review, the screenshot capture, the code sample, the edit pass, the publish step. We typically see the following ranges on mid-market SaaS engagements:

Page type	Human hours
Reference page generated from OpenAPI, human-polished	0.5 to 1 per endpoint
Conceptual page (architecture, data model, mental model)	4 to 8
End-to-end tutorial with working code	8 to 16
Troubleshooting or runbook page	2 to 4

At a blended loaded rate of $150 per hour, a conceptual page lands around $600 to $1,200 to produce. A tutorial lands around $1,200 to $2,400. Treat those as industry-plausible starting points, not measured benchmarks. Your own rate card and review overhead will move them.

Cost of maintenance (Cm)#

Hours per page per quarter to hold quality steady. This is the variable teams refuse to fund and then wonder why drift eats them.

A working rule of thumb:

Cm_quarterly ≈ Cp × 0.15 × (release_velocity / baseline)

Read that as: expect maintenance to run roughly fifteen percent of initial production cost per quarter, scaled by how fast the product underneath is changing. Baseline here is a monthly release cadence. A team shipping weekly multiplies that factor by about four. A team shipping quarterly divides it by three.

A worked sensitivity check on a $1,000 page:

Release cadence	Velocity factor	Cm per quarter	Cm per year
Quarterly	0.33	$50	$200
Monthly	1.0	$150	$600
Weekly	4.0	$600	$2,400

A team that ships weekly spends more maintaining one page over a year than it spent creating it. That is the fact that kills most doc sets. Teams budget production and forget that the bill repeats.

Cost of a wrong answer (Cw)#

This is the variable almost nobody models and everyone pays for. It has three layers.

Support deflection failure. A wrong answer that sends the user to support is a ticket you could have avoided. Blended support cost for B2B SaaS typically runs $15 to $45 per ticket, depending on tier and geography. Use your own number if you have it; it is sitting in your support platform.

Trust erosion. Harder to price, but real. Users who get a wrong answer from your docs or your docs-grounded assistant learn not to trust either. They route around you to Stack Overflow, to a competitor's docs, or to a human in your Slack community. We treat this as a qualitative multiplier on Cw in the 1.2 to 2.0 range for products where the docs are the primary learning surface. Label it an estimate when you use it.

Incident contribution. Rare but expensive. A wrong answer that caused a production outage, a bad migration, or a compliance exposure can run into the thousands or tens of thousands of dollars per event. These are the tail of the distribution, not the median, and they are what make Cw non-trivial to model.

A reasonable range, to be sensitivity-tested against your own data:

Product profile	Plausible Cw per failure
Consumer tool, low stakes	$5 to $20
B2B SaaS, standard tier	$20 to $60
Developer platform, production-critical	$75 to $300
Regulated industry (fintech, health, infra)	$500 to $5,000+

Most teams can build a defensible median by pulling ninety days of support tickets, tagging the ones that a better doc would have deflected, and dividing total handled cost by count.

Query volume (Q)#

How many times per month users land on this page, either through search, a direct link, or a retrieval-augmented AI answer that grounded on it. Pull from analytics and your AI assistant's citation logs. If you do not have citation logs from your assistant, that is the first thing to fix; you cannot model doc ROI without knowing which pages the model is actually reading.

Two decay rates#

Value erodes along two axes at once.

Content decay. The page becomes factually wrong. Driven by release velocity. Fast, visible, and correctable with a maintenance budget.

Structural decay. The page becomes unfindable, unrankable, or drowned by newer neighbors with overlapping scope. Driven by page count growth without information architecture review. Slower, less visible, and much more expensive to fix once it compounds.

Both decay functions are roughly exponential over a one to two year horizon. Content decay dominates in the first six months. Structural decay dominates after eighteen. A doc set that gets content updates but never gets an IA review passes audits in year one and fails them in year three.

The equation#

Annual net value of a single page:

Net_annual = (Q_annual × Cw × deflection_rate) − Cp − (4 × Cm_quarterly)

Where:

Q_annual is monthly query volume times twelve.
deflection_rate is the probability that a correctly-documented page prevents a wrong answer or a ticket. We typically model this at 0.3 to 0.6 for well-written pages on well-scoped topics. Use 0.4 as a starting median.
4 × Cm_quarterly is one year of maintenance.

Break-even is the point where expected deflected failures cover production plus a year of maintenance. Rearranging:

Q_annual_breakeven = (Cp + 4 × Cm_quarterly) / (Cw × deflection_rate)

That is the sentence to put in front of a CFO. A page earns its keep when its annual query volume clears that threshold.

A worked example#

The numbers below are illustrative — drawn from the ranges we see across DevDocs audits, chosen to make the shape of the math legible. Do not paste them into a deck as benchmarks. Pull your own ticket cost, page volumes, and release cadence before you run the model internally.

Take a representative mid-market SaaS engagement:

Doc set: 400 pages
Total monthly query volume across the set: 12,000
Blended Cw: $30 per wrong answer
Deflection rate for maintained pages: 0.4
Blended loaded rate: $150 per hour
Release cadence: monthly (velocity factor 1.0)

Traffic distribution follows the pattern we typically see on sets this size: roughly fifty pages drive about eighty percent of the queries. That gives us two populations.

Top fifty pages. Average 9,600 / 50 = 192 monthly queries per page, or 2,304 per year. Assume they are conceptual and tutorial pages at an average Cp of $1,500 and a monthly-cadence Cm of $225 per quarter, or $900 per year.

Annual value per top page:

2,304 × $30 × 0.4 = $27,648 in avoided failure cost
− $1,500 production − $900 maintenance
= $25,248 net per page per year

Across fifty pages: roughly $1.26M in annual net value. Total annual cost to maintain the top fifty at high cadence: 50 × $900 = $45,000. Add amortized production at one-fifth per year (assuming a five-year useful life with IA reviews): another $15,000. Call it $60,000 all-in to hold the top fifty at audit-grade quality.

Bottom 350 pages. Average 2,400 / 350 = about 6.9 monthly queries per page, or 82 per year. Assume a lower average Cp of $800 (more reference material, less tutorial) and a Cm of $120 per quarter, or $480 per year.

Annual value per bottom page:

82 × $30 × 0.4 = $984 in avoided failure cost
− $800 production − $480 maintenance
= −$296 net per page per year

Across 350 pages: roughly −$104,000 per year if you maintain every one of them at the same cadence. Production cost is sunk; the live decision is whether to keep spending $480 a year per page on maintenance for pages that return under $1,000 a year in avoided failures.

The answer for most of them is no. Drop those 350 pages to a light-touch review cadence, say one hour per year at $150, and the math inverts:

82 × $30 × 0.4 = $984
− $150 annual review
= $834 net per page per year

Across 350 pages, about $292,000 in annual net value from pages you were previously operating at a loss. Total savings versus the "maintain everything" baseline: roughly $396,000 per year on a doc set of this size, before counting the value of redirecting senior writer hours to the top fifty.

The grand total, on the recommended mix:

Population	Pages	Strategy	Net annual value
Top	50	High-cadence maintenance to audit grade	~$1.26M
Tail	350	Light-touch review, triage risers	~$292K
Total			~$1.55M

Sensitivity#

The result moves most on two inputs: Cw and deflection_rate. Halve Cw to $15 and the top-fifty net drops to about $555K. Drop deflection_rate to 0.25 and it drops to about $810K. The case is still strongly positive at the top, still negative at the tail. That is the robust finding: the triage decision survives reasonable pessimism on every input.

The case is most fragile on Q. A doc set with 2,000 monthly queries instead of 12,000 looks very different, and a team that cannot measure Q at all should fix that before funding anything else.

The honest part#

Most pages in a mature doc set do not pay for themselves. That is the part the case studies skip.

Four hundred pages where fifty drive eighty percent of the queries means 350 pages operating at negative ROI under uniform maintenance. That is not a failure of the model. It is the call to triage the model exists to support.

The correct move is not "maintain everything." It is:

Maintain the high-Q, high-Cw pages to audit-grade quality on a tight cadence.
Let the rest decay intentionally, with a quarterly review that flags pages climbing in traffic so they get promoted before they embarrass you.
Retire pages that have been dead for two cadences running. An archived page is free. A wrong page is not.

This is an uncomfortable recommendation because it contradicts the instinct that more docs are better docs. More docs are more surface area for decay, more dilution of search ranking, and more pages the retrieval layer has to pick through to ground an answer. A smaller, better-maintained set beats a larger, half-maintained one on every variable in the equation.

What to do with this#

If you want to pressure-test your own doc investment, run this exercise:

Pull Q for the top fifty pages from analytics and AI citation logs.
Set Cw from your own support ticket data, tagged by whether a doc would have deflected.
Apply the break-even formula. Any page below threshold on Q either needs a different strategy or does not need to exist.
Build a maintenance budget for the pages that cleared the bar, priced at fifteen percent of production per quarter, scaled by your release cadence.
Put everything else on a light-touch cadence and a risers watchlist.

The ROI argument for documentation is real, but it is not universal and it is not automatic. The cases where it holds up are the cases where you can name the variables. If your argument for docs investment does not include release velocity, query volume, cost per failure, and decay rate, it is not a model. It is a hope.

A model survives a CFO's pen. A hope does not.