April 2026 · GoCodeLab · Dev Mindset

Why Indies Polish Their MVP for 6 Months

"Just one more pass and I can ship it."

If you've been saying that for three months straight, let's be honest. You're not going to ship. Not in this state, anyway. You already know that. You just don't want to admit it, so you're redrawing the onboarding screen one more time. I did the same thing. That's why I'm writing this.

The reason an indie can't ship isn't that the code is incomplete. It isn't that the market is invisible. It comes down to two words. Sunk cost and perfectionism. The two of them hold hands and keep you locked in for six months at a stretch.

Sunk Cost Fallacy — Time Already Spent Wrecks Future Decisions

In 1985 Arkes and Blumer ran a simple experiment. They sold movie theater season tickets at randomly assigned prices. One group paid the full $100. Another group paid a discounted $50. Same movies, same seats, same theater. The $100 group went to the theater more often. They went even when the movie wasn't fun. The thinking: "I already spent $100, so skipping is a loss."

This is the sunk cost fallacy. The core is one line. Already-spent costs should be excluded from future decisions to be rational. They aren't recoverable. But the human brain can't operate that way. Because the spending hurts, you stack more loss on top of the loss you already have.

The problem is that sunk cost isn't only money. Time, effort, ego, ten thousand lines of code written at 2 a.m. — they all fire the same circuit. That's why indie devs are at risk. You've effectively bought a six-month season ticket. You poured in 1,000 hours. The hours feel too valuable to walk away from, so you don't ship. You polish. Polishing piles on more time. You can throw it away even less. So you polish more. That's the anatomy of the six-month loop.

Here's the painful part. Polishing doesn't reduce sunk cost. It grows it. You feel like you're "recovering the investment." It's the exact opposite. Every hour of polish adds another hour to the sunk-cost pile. Shipping gets scarier every day. Today you can ship less than yesterday. You don't see this at week six. You suddenly see it at month six.

Perfectionism Is Sunk Cost Wearing a Mask

This is where perfectionism enters. Perfectionism usually gets framed as "high standards." It sounds noble. But the taxonomy Adderholdt-Elliott laid out in 1987's Perfectionism: What's Bad About Being Too Good? tells a different story. There are two kinds of perfectionism. Normal perfectionism and neurotic perfectionism. The normal perfectionist is satisfied once a standard is met. The neurotic perfectionist moves the standard another step away every time it's reached. The point of satisfaction is permanently one step out.

An indie ripping out the UI a week before launch isn't normal perfectionism. It's neurotic perfectionism. And the key point: neurotic perfectionism operates as a way to justify time already spent. "If I've put in this much, the result has to be at least this good." That sentence auto-plays in your head. That's the calling card the sunk-cost circuit hands out.

So perfectionism is the mask sunk cost wears. They're two names for the same circuit. While you reassure yourself "this is just my perfectionism," the circuit is laughing back, "this is sunk cost."

Honestly, My Own Cases

One time, a week before launch, I tore out the entire UI. To be precise, I had a feeling that I "should probably tear it out," and I followed the feeling. I redid the typography system. I redefined the color tokens. I redrew all twelve screens. That work took three months. Launch slipped by exactly that much.

Across those three months, I had zero users. That much is certain. Was the rebuilt UI objectively better? Looking back, I honestly can't tell. What I can tell is the sentence that auto-played in my head at the time. "I've come this far — shipping at this level would be a waste." It wasn't that the time was valuable. It was valuable because the time was already in. Same as the $100 movie ticket.

To be more honest, there was a side project I buried before that one. Built version 0.1, never shipped, just kept adding features. At first it was "one more thing and ship." A month later, "two more things." Month three I rewrote the onboarding. Month five the codebase was heavy enough that adding a new feature got slow. In the end I didn't ship. To be precise, it wasn't that I couldn't — I didn't. I could have shipped at that point. But the ego voice saying "not at this level" was louder. That app is sleeping in some folder right now. A grave with zero users.

Was the app I shipped three months later more meaningful to users than the version I had a week before the rewrite? I honestly don't know. What I do know is that those three months calmed my own mind. Sunk cost is a payment for the founder's ego, not for the user. That's the truly scary part. When the ego gets expensive, users get further away.

The Escape Frame — 'Not Shipping Now Is the Bigger Loss'

Breaking the sunk-cost circuit isn't a willpower problem. It's a framing problem. You usually ask it like this: "If I throw it out now, isn't six months a loss?" Wrong question. The six months are already gone. Not recoverable. Those months are not coming back regardless of any decision you make.

Reframe the question. "If I don't ship now, I lose the next six months too." That's the real loss. Sunk cost is buried in the past, but not-shipping eats the future every day. Zero users every day. Zero feedback every day. Confidence minus one every day. Polish another six months and the next six months are also zero. Meanwhile the market moves, competitors ship, and your motivation dries up.

There's a one-line question that forcibly cuts the circuit. Every time you feel like polishing, ask yourself this: "If someone handed me this exact code a week ago, would I spend three months polishing it?" If the answer is "no," then you shouldn't spend the next three months polishing it either. Already-spent time has to be excluded from the decision. Arkes & Blumer said this 40 years ago. One line, circuit cut.

One more thing. Shipping isn't the end. It's the entrance. v1.0 is the door to v1.1. You can change the typography after launch. You can rebuild a screen after launch. The difference is you'll do it with user data. Pre-launch tear-downs run on data from inside your head. The two are completely different operations. The data inside your head is contaminated by the sunk-cost circuit. User data is not.

No Ugly v1, No v2

Sunk cost is insurance for your ego. User feedback is insurance for the app. Which one you spend time on is your call.

If you're stuck at month six and not shipping, the code isn't the problem. You've already poured too much in. That's the real reason shipping is blocked. It's hard to admit. But it is. I went through the same thing.

One thing for today. Pin a launch date to the calendar. D+14, D+30, whatever. Ship on that day even if features are short. Put out the ugly v1. That's how v2 happens. Without an ugly v1, there is no v2. Ten lines of user complaints in a week beat six more months of polish. They make the app better, faster.

That sentence — "just one more pass and I can ship." If you've been saying it for three months, the sentence itself is the signal sunk cost is sending. The moment that signal lights up is the moment to ship.

This article reflects information as of April 2026. The cited studies don't change with time, but my interpretation of them might shift with better data.