Nobody budgets for bad software, which is exactly why it is so expensive. The cost of bad software never shows up as one line item; it hides in five different places on your P&L, wearing five different disguises. I went through the categories the way I go through everything — with a scorecard — and ranked them by how much they actually bleed. The numbers don’t lie, but you do have to go looking for them.
Quick ground rule: every figure here is a defensible range for a mid-size company, not a precision estimate for yours. The point of this post is the model. Plug in your own numbers at the end.
How I scored each cost of bad software
Four factors, each scored 1 to 10:
- Magnitude — how many dollars it moves in a typical year.
- Invisibility — how unlikely it is to appear in any report you currently read. Higher means better hidden.
- Compounding — whether it gets worse on its own if ignored.
- Fixability — how much of it you can realistically recover. Higher means more recoverable.
The ranking
1. Engineering rework — score 34/40
Magnitude 9, invisibility 9, compounding 9, fixability 7. Industry studies have put developer time spent on rework, bug-hunting and fighting technical debt anywhere from 20 to 40 percent in codebases with poor quality. Take a five-developer team at a fully loaded U.S. cost of roughly $130,000 per head: even the conservative 25 percent means about $160,000 a year paying people to fix what you already paid them to build. It is ranked first because it is the upstream tax — every category below is partly downstream of this one — and because it never appears in any report. Payroll looks identical whether your team ships features or shovels debt.
2. Customer churn — score 30/40
Magnitude 8, invisibility 7, compounding 9, fixability 6. Buggy, slow, confusing software drives quiet cancellations. On $2M of recurring revenue, two extra points of annual churn is $40,000 gone in year one — and compounding, because that revenue is also missing from every future year’s base. Churn gets logged, but the reason rarely does: customers say "we went another direction," not "your app made my team’s day harder."
3. Lost sales and downtime — score 26/40
Magnitude 8, invisibility 5, compounding 5, fixability 8. The most visible category: the demo that crashes, the checkout that fails, the outage during your busiest week. An online operation selling $3M a year loses roughly $8,200 per day of downtime on averages alone — and outages never pick average days. Scores lower than churn because it is episodic rather than structural, and the most recoverable, since reliability work pays back immediately.
4. Developer turnover — score 25/40
Magnitude 7, invisibility 6, compounding 7, fixability 5. Good engineers do not stay to shovel debt. Replacing one is commonly estimated at 50 to 100 percent of annual salary in recruiting, ramp-up and lost context — call it $60,000 to $130,000 per departure — and each exit takes unwritten knowledge with it, making the codebase worse, which drives the next exit. That loop is the quiet death spiral of bad systems.
5. Decision drag — score 22/40
Magnitude 6, invisibility 8, compounding 6, fixability 2 (hardest to claw back). When reports are wrong or late, managers decide on stale data or gut feel: overbought inventory, mispriced quotes, a bad month discovered six weeks after it happened. Cheapest of the five in most years — and the one that occasionally produces the single most expensive mistake in company history.
The cost table
| Cost category | Typical annual range* | Where it hides |
|---|---|---|
| Engineering rework | $120,000–$260,000 | Payroll (looks normal) |
| Customer churn | $40,000–$150,000 | "Market conditions" |
| Lost sales / downtime | $25,000–$120,000 | Missed revenue targets |
| Developer turnover | $60,000–$130,000 per exit | Recruiting and HR budgets |
| Decision drag | $20,000–$100,000 | Inventory, pricing, margins |
*Mid-size company, ~5 developers, $2M–$5M revenue. Your mileage is the whole point — run your own numbers.
Run your own math
Three questions get you 80 percent of the answer. One: what fraction of your developers’ time goes to fixing versus building? Ask them directly; they know. Multiply by loaded payroll. Two: pull your last ten lost customers and honestly tag how many had software-related complaints on file. Multiply by lifetime value. Three: count last year’s revenue-impacting incidents and hours down. Add the three numbers. In my experience the total cost of bad software lands between 15 and 30 percent of what the company spends on software in the first place — which reframes the decision entirely. Quality is not a cost. It is the highest-margin line item you are not tracking.
One more analyst note, because someone always asks: why rank rework first when downtime makes the headlines? Because of the compounding column. A crashed server is a bad day; a codebase where every change takes three times longer than it should is a bad year, every year, growing quietly. In the scorecard, magnitude gets the attention but compounding decides the ranking — the categories that feed themselves are the ones that end up owning your roadmap. Downtime is a fire. Rework is termites. Most companies insure against the first and ignore the second, and only one of the two is guaranteed to be eating right now.
Two ways out, depending on where you are. If the system is old and the debt is structural, a measured path beats a rewrite — that is what legacy software modernization is for. If you are building new, the cheapest bug is the one that never ships: custom software development done with testing and code review baked in costs more per sprint and dramatically less per year.
Want this scorecard filled in with your numbers instead of my ranges? Schedule a call — bring your incident list and I will bring the spreadsheet.
Finding this analysis useful?
Get one email a week with the most important developments in AI and business technology — explained in plain English, with real numbers and zero spam.
Want this working in your business?
Book a free 30-minute session: we look at your case and tell you what is worth doing (and what is not) — no strings, no sales pitch.
Book a free session →