ROI CALCULATOR
The cost of poor planning
Enter your own numbers. Everything recalculates live. Start on the conservative preset and argue upwards from there.
Team and rates
Authoring time per spec
Clarification loop per spec
Rework
Agent cycles
Plansmith seats
$2,000 per planner a year ($166.67/mo), $50 per comment-only seat
Only the people who plan need a full seat. Teammates who follow along take comment-only seats. Developers work from the issue tracker and need no seat at all.
Across 36 people, the seats buy back 241 hours a year at a blended rate. That is 6.7 hours per person per year, or about 100 minutes a quarter. To reject this case you have to believe clearer specs save your team less than that.
Where the recovery comes from, against what it costs
The same figures as a table
| Cost centre | Basis | Annual recovery | Share |
|---|---|---|---|
| Authoring time | 6 hrs to 2 hrs of author time per spec | $97,920 | 27% |
| Clarification loop | 5.0 hrs to 1.7 hrs per spec, both sides | $84,096 | 24% |
| Rework | 12% of capacity, cut by 25% | $168,480 | 47% |
| Agent cycles | 30% of agent spend wasted, 50% recovered | $7,200 | 2% |
| Total annual recovery | $357,696 | 100% |
Sensitivity on the two contestable inputs
Two assumptions carry the model: the share of engineering capacity currently lost to rework driven by unclear specs, and how much of that Plansmith removes. Both are shown across their plausible range. Figures are total annual recovery, with the other three cost centres held at the current inputs.
| Capacity lost to rework | Cut by 15% | Cut by 25% | Cut by 35% |
|---|---|---|---|
| 6%, a disciplined team | $240,000 | $273,000 | $307,000 |
| 9% | $265,000 | $316,000 | $366,000 |
| 12%, base case | $290,000 | $358,000 | $425,000 |
| 15% | $316,000 | $400,000 | $484,000 |
Fully loaded hourly rates of $90 engineering and $85 for spec-authors assume US mid-market salaries at a 1.3x burden multiplier over 2,080 hours. Spec volume of 288 a year assumes 4 per author per month. The authoring and clarification figures are per-spec estimates, to be replaced with your own observed values during a pilot. Rework percentages are ranges and not measurements, which is why the sensitivity grid is there. No figure here is an industry benchmark presented as fact.
Where the money goes today
Ambiguous specs never show up as a line item. They cost capacity in four places, none of which appear on an invoice.
| Cost centre | What happens today | Why it costs what it costs |
|---|---|---|
| Authoring | A spec-author hand writes the spec, structures it, and breaks it into tickets | Skilled product time goes on formatting and decomposition instead of judgement |
| The clarification loop | An engineer hits an ambiguity, asks, waits, context switches, resumes | You pay twice, for the engineer's blocked time and the spec-author's interrupted time, and the switching cost exceeds the question |
| Rework | The feature ships, then is reworked or discarded because it met the ticket but not the intent | The most expensive class of defect. It consumes full delivery capacity before anyone discovers the error |
| Wasted agent cycles | A coding agent is pointed at a vague ticket, builds down the wrong path, output is thrown away | A new cost, and the only metered one. Vague input converts directly into billed tokens you throw away |
Why the number is hard to argue with
Most vendor ROI models collapse under one sceptical question, because they need a large behavioural change to clear a large licence fee. This one does not. The seats are small enough that the argument holds on structure alone.
What this model leaves out
Four real benefits are left out. They are harder to defend in a finance review and the case does not need them.
- Cycle time
- Shipping the same roadmap sooner has revenue value we have not attempted to price.
- Retention
- Rework is among the most commonly cited sources of engineering frustration.
- Escaped defects
- Spec errors that reach production cost materially more than those caught in delivery.
- Token efficiency
- We believe better structured specs cut agent token consumption substantially. That is something to measure in a pilot, not assert in a spreadsheet.
Where the plan gets good.
Start with your business requirements. Review the Specs and prototype, resolve open questions, and hand off a plan your dev team can build.