Ship Late or Ship Broken: How to Actually Make the Call

It is six on a Thursday evening. The release is staged, the calendar says tomorrow, and someone in the standup channel asks the question nobody wants to own: ship late or ship broken. A support lead worries about the ticket queue. A product manager worries about the roadmap slipping again. An engineer who has been staring at a flaky checkout test for two hours just wants to go home.

This exact scene repeats at most software companies every few weeks. Almost nobody writes down how the decision actually got made. It usually just defaults to whoever sounds most sure of themselves. This post lays out both sides of that decision in plain numbers. It explains why teams get it wrong in a predictable direction. It gives you a framework you can actually run in the ten minutes you have.

The cost of delay is easy to see and easy to overstate

Delay cost shows up immediately, which is exactly why it dominates the conversation. A team holding a release for a week is not just losing a week. It is paying salaries for engineers who are idle on that feature. It is pushing back whatever was scheduled to follow. It may also miss a marketing date or a customer commitment that was already promised.

Take a ten person engineering team with a fully loaded cost of roughly 15,000 dollars a day. Holding a release for three days to retest a payment flow costs about 45,000 dollars in burn alone. That is before you count the opportunity cost of the next release also sliding by three days.

That number is real, and it is the one everyone in the room can picture without much effort. It is visible the moment the decision is made. That immediacy is precisely why it tends to win arguments it should not win on its own.

The cost of a defect is just as real, but it arrives late and spread out

A defect that reaches production does not send a single invoice. It shows up as a slow accumulation of smaller costs that rarely get billed against the release that caused them. Take a checkout bug that only appears in Safari and reaches production on a Friday release.

• Support load: that Safari bug generates 40 tickets over two weeks, each one costing a support agent 20 minutes to triage and escalate, about 13 hours of support time total.
• Remediation: the fix itself takes a day of two engineers' time, roughly 3,000 dollars, plus a hotfix release with its own retest cycle.
• Trust cost: a customer who hits the broken checkout twice does not file a bug report the second time. They quietly reduce how much they trust the product, and that number never appears on anyone's dashboard.

Add it up and that one moderately serious defect costs somewhere in the low five figures, plus a trust cost nobody bills for. It is smaller than the three day delay cost above. But it recurs every time this happens, and it rarely gets billed against the release decision that caused it.

That is the real asymmetry. Delay cost is a single number you can see tonight. Defect cost is a slow leak you only notice in aggregate months later, spread across support, engineering, and account teams who rarely compare notes. Teams under time pressure systematically choose against the cost they cannot see clearly. That is a bias worth naming out loud in the room, not just a personal failing of whoever made the call.

You cannot make this call if you cannot say what was tested

Here is the precondition that gets skipped most often. Before you can weigh delay against defect risk, you need to know, specifically, what parts of the product were tested for this release and what parts were not. Most teams asked this question on a Thursday evening cannot answer it precisely.

They can say "QA looked at it" or "the regression suite passed." They cannot say which of the 30 checkout scenarios were actually run this week, versus which ones were skipped because time ran out.

Without that answer, the delay versus defect calculation is not really a calculation. It is a guess dressed up as a decision, made by whoever projects the most confidence. A team that keeps its test cases documented and mapped to the features in a release can answer differently. They can say plainly: guest checkout and the three main card types were covered this week, Apple Pay on Safari was not, and that path broke for a real customer last quarter. That single sentence changes the conversation, because the risk becomes a specific, nameable thing instead of a vague feeling.

A decision framework for the ten minutes you actually have

When the release meeting starts and everyone wants an answer, run through this in order.

• State the delay cost in dollars, using team burn rate times the number of days you would hold, plus what else is waiting behind this release.
• State what was tested and what was not, specifically, by feature or flow, not as a percentage.
• For anything untested that touches money, login, or data loss, treat it as a real risk, not a rounding error.
• Ask who absorbs the cost if the untested path breaks: support, engineering, or the customer directly.
• If you cannot answer the second question with any confidence, that itself is the answer. You hold, or you ship with a fast rollback plan and someone watching the dashboard.

This is not a formula that spits out a number. It is a way of making sure the conversation is grounded in what is actually known, rather than in whoever is most persuasive at 6pm on a Thursday.

Skip the borrowed statistic, use your own numbers

You may have seen the claim that a bug found in production costs some large multiple more to fix than one found earlier. That figure traces back to a decades old study that has been stretched well past what it actually measured. It is not used here.

Use the Safari checkout numbers above instead. Roughly 13 hours of support time, a 3,000 dollar hotfix, and a retest cycle add up to a real, bounded cost in the low five figures. That is smaller than a three day delay in this example. The point is not that defects always cost less than delay. The point is that you can only compare the two honestly when both are expressed as real numbers from your own release, not a borrowed industry average.

Our post on choosing QA metrics that actually mean something walks through how to track defect and coverage data over time so this comparison gets easier each release. A companion piece on what defect leakage really costs a team goes deeper into the support and trust side of this math.