Better Ship It Than Admit It

TL;DR:
The time you spent is gone whether you ship or not. [Sunk cost](https://en.wikipedia.org/wiki/Sunk_cost) makes cancellation feel like losing those months and shipping feel like saving them. It's not true. Shipping the broken thing just starts a new clock, and your users are the ones on it.

There is a moment in almost every project where a designer knows. Not suspects. Knows. The flow doesn’t work. The feature solves the wrong problem. The research came back bad and nobody wants to say it out loud. What happens next has almost nothing to do with design judgment. It has everything to do with how much time the team has spent.

The more you’ve built, the harder it gets to kill.

The math that isn’t math

In economics, a sunk cost is money spent that cannot be recovered. The rational thing is to ignore it when making future decisions. What you paid to get here has no bearing on where you should go. This is not controversial. Most people understand it when they hear it stated out loud. And almost none of us does it.

Hal Arkes and Catherine Blumer studied this gap between knowing and doing in 1985. What they found was uncomfortable. The more people had put in, the more committed they became to continuing, regardless of what the evidence said.

“The sunk cost effect is manifested in a greater tendency to continue an endeavor once an investment in money, effort, or time has been made.”

Arkes & Blumer

The mechanism is not stupidity. It is loss aversion doing its usual work. Richard Thaler, who spent decades mapping how humans handle money, showed that losses land about twice as hard as equivalent gains. If you’ve put three months into something, abandoning it feels like losing three months. Shipping it feels like salvaging them. Neither framing is accurate. The three months are gone in both cases. But one of them hurts less in the moment, so that’s the one your brain reaches for.

Designers are not immune. Nobody is. The pull gets stronger when the investment was visible: presentations given, briefs written, other people’s calendars filled because of your work. Stopping now doesn’t just mean admitting the thing was wrong. It means admitting all of that was wrong. That’s a much bigger thing to swallow, so you find reasons not to.

When spending billions beat admitting failure

In 1962, Britain and France signed a treaty to build a supersonic passenger aircraft together. The programme’s estimated cost at signing was £70 million. By the time Concorde entered commercial service in 1976, the actual cost had reached somewhere between £1.5 billion and £2.1 billion, more than twenty times the original estimate. Evidence of commercial failure had been mounting for years before the first flight. Major airlines had withdrawn their options on the aircraft. The economics of supersonic passenger travel at the ticket prices required did not work. Government officials on both sides knew it.

They flew it anyway. Not because the numbers got better. Because stopping meant admitting that everything spent was a total loss. The programme couldn’t be unwound without making that undeniable. Continuing at least kept the story alive.

Economists named this the Concorde fallacy: the tendency to throw good resources after bad ones because abandoning feels more costly than continuing, even when the opposite is true. The aircraft made its last commercial flight in 2003. The project’s commercial failure was total and documented. None of that changed the decisions made in the years when it still could have mattered.

The version that happens every quarter

The Concorde is an extreme case. But the same logic runs through smaller decisions in product teams every week.

You spent four months building a settings panel. Usability testing shows users cannot find what they need in it. The navigation is wrong. You can see it. The fix would require throwing out a significant part of what you built and rethinking the structure. So instead you add labels. You add tooltips. You move things a bit. You ship the panel with the navigational problem intact because the alternative feels like erasing four months of work.

Or you built a feature around an assumption that turned out to be wrong. Users don’t want to share content the way you imagined. The data is clear. But three engineers, two sprints, and one all-hands demo are on the other side of that decision. Killing it now means explaining that the demo was for something that won’t ship. So you ship it, deprioritize it in silence, and wait for it to sit unused until someone removes it eighteen months later. The four months you were trying to protect became twenty-two months. Nothing got saved.

The question that cuts through it

Before you can make a clean decision about something you’ve built, you need to separate two things your brain keeps fusing: what it cost you to get here, and what it will cost your users if you ship it wrong.

The sunk cost is real. The time is gone. That part is fixed no matter what you decide next. What is not fixed is whether your users spend the next year fighting something you knew was broken on the day you shipped it.

One question helps: if someone handed you this feature today, built, no history, no context, and asked you whether to ship it, what would you say? Strip out the memory of the work. Look at the feature and the evidence. The answer that comes up is the one you’ve been avoiding.

Kahneman calls this a reference class forecast: stepping outside your current perspective to evaluate the decision the way an outside observer would. It doesn’t make the sunk cost disappear. It just stops it from running the meeting.

Name this out loud when you see it. Not as an accusation. Teams don’t make sunk cost decisions out of laziness or cowardice. They make them because the pull is real and the framing is invisible. Saying “I think we might be holding onto this because of what we’ve spent” is not a criticism. It’s the only way to get the decision back in front of the real question: what does the user need now?

The work done is not a reason to ship something that doesn’t work. It’s not a reason. It’s not a vote. It’s just the past. Don’t let it decide.