Quality engineering doesn't save money. It buys the right to decide.
The usual ROI case for quality is built on costs that never happened. The stronger case is that quality engineering is what lets a business make fast, defensible release decisions, and that capacity has a price you can name.
Every quality leader has made the same pitch at least once. Defects found in production cost a hundred times more than defects found in design. Therefore every euro spent on quality saves ninety-nine. Please approve the budget.
It is a weak argument, and finance people know it. It asks them to value something that did not happen, using a multiplier nobody in the room has measured, to justify spending money that definitely will happen. Even when the budget gets approved, it gets approved as insurance. Insurance is the first thing cut when the year gets tight.
I have argued before that we should replace ROI with value when talking about test automation. This post is the longer version of that thought, applied to quality engineering as a whole. Quality engineering's real business outcome is not avoided cost. It is decision capacity: the ability to make a release decision quickly and defend it afterwards.
Why cost avoidance keeps losing the argument
Cost avoidance has three structural problems.
- It is counterfactual. You are asking someone to value an incident that did not occur. If your quality work is good, the evidence for it is an absence, and absences make poor line items.
- It rewards failure. The cost-avoidance case gets stronger after a bad incident and weaker after a quiet year. Your best year becomes your weakest budget conversation.
- It frames quality as a tax. Insurance protects value created elsewhere. Once quality is positioned that way, every cost conversation is about how little of it the business can get away with buying.
None of this means incidents do not cost money. They do, and you should know your numbers. But leading with them puts you in a defensive posture you never get out of.
What the business is actually buying
Watch what happens in a release meeting where the quality signal is weak. People hedge. Someone asks for one more round of manual testing. The date slips a week, or ships with a list of known risks nobody can size. Either way, a decision that should have taken ten minutes takes days, and when it is made, nobody can explain why it was safe.
Now watch the same meeting where the evidence is strong. The question "can we ship?" has an answer, and the answer comes with reasons. If the answer is no, it comes with a specific why not, which means a specific fix.
That difference is what quality engineering produces. Not fewer bugs as an end in itself, but the speed and confidence of decisions that depend on knowing the state of the product. Release decisions, yes. Also: can we take on this customer's custom integration, can we refactor this module this quarter, can we cut this legacy platform without breaking the people still on it.
In The Speed Trap I put it as: speed is not the achievement, justified speed is. That is the ROI story. The business does not want quality. It wants to move fast without gambling, and quality engineering is the only function whose output is the justification.
How to put a number on decision capacity
"Decision capacity" sounds abstract until you price its absence. Three places it shows up in money:
Waiting time on decisions. How long does a release candidate sit between "code complete" and "approved to ship"? Multiply by the number of releases and the cost of the people and opportunities waiting. This is usually a larger number than the incident budget, and it is not counterfactual. It is happening every sprint.
Hedging cost. Manual regression weeks, release freezes, extra approval layers, feature flags left on for months because nobody trusts turning them off. Each one is the organisation buying confidence the slow way because it cannot get it from evidence.
Options not taken. The refactor you never schedule. The platform you cannot retire. The customer deal that requires a change in an area nobody dares touch. These are harder to price, but sales and product leadership can usually name them in five minutes if you ask the right question: what would you do if you trusted the codebase?
It is easy for teams to just push the release on date even, if some issues are still open inside the backlog, schedule wins. Day or two later we get escalation of missing fix while that issue got alredy implemented and hotfix release out of schedule cost the team more than waiting that single day to have the fix included. The business need behind the release was not there and issue fix was highly anticipated. The trust with customer was really hard to earn back..
None of these depend on a multiplier from a textbook. They are measured in your own calendar and your own backlog.
Why the AI era makes this argument easier to win
Two years ago, the bottleneck in most delivery pipelines was producing the change. Today, for many teams, it is being able to trust the change. Generation got an order of magnitude cheaper. Verification did not.
That shift quietly rewrites the business case for quality. When code was expensive, quality looked like overhead on an expensive process. Now that code is cheap, quality engineering is the scarce input. It determines how much of the cheap output can actually be shipped. A team that can generate ten changes a day and justify two has a throughput of two, whatever the commit graph says.
On BowSmith I saw this directly. The constraint was never how fast agents could write code. It was how fast I could produce evidence that the code was right: the test suite, the static analysis, the independent review tier. Every investment in that evidence pipeline turned straight into shipping speed. That is ROI in its plainest form, and there is no counterfactual in it.
Changing the conversation with leadership
If you want to try this framing, change three things in your next budget conversation.
- Lead with decision latency, not incident cost. "Our median time from release candidate to approved release is X days. Here is what is in those days, and here is what would remove them."
- Name the hedges. List every manual safety net that exists because the evidence is not trusted. Each one is a cost the business is already paying, just not in the quality budget.
- Ask for the options. Bring one product or sales leader into the conversation and ask what they would do with a codebase they trusted. Their answer is your upside case.
Then position the investment accordingly. You are not asking for insurance. You are asking for throughput.
The test is simple. If your quality budget would be easier to defend after a major incident than after a quiet year, you are still selling insurance. Where does your current case land? If you want to pressure-test it before it goes in front of finance, book a Quality Coffee and bring the slide you are least sure about.
