Published Nov 9, 2025

Failure demand is a tax on software development

A failure demand¹ - happens when a customer thinks you’ve failed them, and now you need to go above and beyond to satisfy them. It’s a demand for service beyond what you planned to provide. It’s a bit like compensation for the failure itself. A failure demand is the enemy!

How failure demand manifests

In software products, failure demand can look like…

Custom reports to “prove” the system works correctly because something is hidden or confusing
Handholding through basic workflows because trust has eroded
Emergency calls or escalations that require leadership involvement
Extra meetings, status updates, and reassurance rituals
Overtime spent managing upset stakeholders

I’ve spent too much time on such reports. A customer would be confused about an integration or the performance of some part of the system, so they’d demand a report to verify the data. Then they’d want it permanently in the product “just in case.” An exec would get involved, promise it, and suddenly you’re building features to compensate for fuck-ups you never should’ve made in the first place.

This happens with colleagues too. Customer-facing teams aren’t excited about new features. They ask… “Does it actually work?”

Uncharitable assumptions

Persistent failure demand changes how users approach problems. Instead of assuming the best, they start making uncharitable assumptions.

When something goes wrong, the reaction isn’t “I might have made a mistake” they instinctively think “the system is broken again.”

This loop is painful to escape. A bad data migration means customers assume all data is wrong, even when their own inputs are the problem. They’ll stop debugging on their end, and stop trusting their eyes. Every issue becomes your issue.

The cognitive overhead they’re willing to spend debugging drops to zero. Why would they waste time investigating when they can assume it’s your problem?

Failure demand is systemic

A 2017 NHS study found that underperforming primary care systems push demand to emergency departments. The initial system fails, so a more expensive one compensates.

Poor quality and craftsmanship on product and engineering teams creates problems downstream for customer success and support teams. One team’s failure becomes another team’s demand. It’s a negative externality that’s easy to miss.

Leadership creates failure demand when they measure the wrong things. When you reward teams for shipping new features instead of improving existing ones. When quarterly goals incentivize rushing half-baked work out the door. Unfortunately, and perhaps unfairly, I’ve come to associate these issues with VC-backed companies.

It’s easy to treat the symptom instead of the cause. Hire more support staff! Build escalation processes. Add customer success managers. All of these are responses to failure demand, not solutions to it.

It’s not possible to fix this by cutting corners - the reason you’re in this mess is because culturally… you cut corners! Skip proper error messages and the complexity moves to support tickets. Skip documentation and it moves to customer success. Ship a half-baked feature and it moves to escalations and emergency calls. The complexity doesn’t disappear. It just shows up somewhere - often somewhere more expensive.

Addressing failure demand

Stop shipping things that suck. Failure demand is a tax on poor quality.

Go above and beyond in your product building, craftsmanship, documentation, and training. Bonus points: these are energizing activities to excel at. Your team will enjoy it! Be proactive instead of reactive.

It feels, to a certain kind of management, like you’re wasting time on details. I think to a certain extent that’s been a reasonable take in the past. But that has changed with the rise of AI. Given it is now possible to do more work more quickly, we have the opportunity to perfect that flow, handle all the edge cases, and ship fewer bugs. If you’re using this new-found speed to ship more slop, you’re working in the wrong place.

Companies keep paying the tax because fixing things is hard and unsexy. They hire more support staff, more customer success managers, more implementation consultants. They build elaborate escalation processes and customer health scores.

In most B2B software companies, I believe the ROI on bug fixes is higher than the ROI on new features. It’s conventional wisdom that keeping a customer is cheaper than acquiring a new one - this is how. It’s just that executing on that plan is less sexy. No investment in new features or high-touch customer success is going to fix a rotten foundation.

An area I see this manifesting is when you land your first whale of a customer: failure demand is front and center, because they’re big enough to hit edge cases and new failure modes on a daily basis, in ways your existing customers wouldn’t.

I’d highlight Linear’s approach: Kill bugs before shipping new features.² No new feature work until the issues list is manageable. That said, I think if you’re listening to the creaking of the ship as you sail, you can avoid getting in these holes. If you’re listening.

Bottom line

Failure demand is a tax on poor quality. You can pay it, or you can fix the underlying failures. Those are your only options.

Fixing things builds organic growth, good word of mouth, good vibes. It gives you control over your unit economics. It’s about customer trust and long term value over gimmicks. That that is a good idea is not new, it’s just hard to do.