Pivot, Persevere, Kill — The Courage to Kill Makes the Next MVP

Killing is also courage. The next MVP's resources come from this decision.

An indie maker who held a zombie project for 5 years

I know an indie maker who held onto a zombie project for over 5 years. Users were stuck around 100, monthly revenue ~50,000 KRW. He thought it could "somehow turn around." The problem is the 2,000 hours invested in it kept stealing chances from the next MVP.

When he finally took the service down, he could finally allocate time to a new project. What he said still lingers. "The moment I had the courage to Kill, I finally had room for a Pivot."

What data is signaling: 3 forks

If you read data in the previous post, now you must decide the next move. The decision is one of Pivot, Persevere, Kill.

Pivot: when a fundamental assumption is wrong

"This product is good but might fit a different segment." Slack pivoting from internal messenger inside an online game (Glitch) to a workplace communication platform is one such case. In Korea, the early days of Market Kurly. They started with the idea of fresh-food delivery, but as "Saebyeok Delivery" (dawn delivery) emerged as the real differentiator, they reset direction. From 2.9B KRW year-1 revenue (2015) to 150B+ in 3 years — thanks to an accurate pivot.

Persevere: signal is clear but growth is early

"Data is good but small in scale." "High satisfaction but not many people yet." This is worth pushing further. Many success stories chose Persevere and then surged 6–12 months later.

Kill: hardest, but wisest

When the signal is objectively bad. Users don't come, those who come don't return, those who return don't pay. But you've already spent time, and that's the sunk-cost fallacy.

Pivot: keep the core, change only the direction

Pivot isn't simply "changing direction." It means preserving the core assets. You don't rip out the whole tech stack — you reinterpret the customer needs you've learned, the team capability you've built, and the data you've accumulated.

Toss is a great example. Starting with peer-to-peer transfers in 2015. C2C was the tech core. But as data came in, what users really wanted wasn't "transfer" but a broader sense of "financial convenience." Toss set its direction. Expansion to banking, securities, payments, telecom. Core tech and team stayed the same; the value offered was redefined. Result: 24.8M monthly active users as of 2024.

Pivot decision checklist

• Did current customers solve a real problem?
• Do other customer segments have the same problem, even more acutely?
• Can the tech stack be reused?
• Does the team understand the basics of the new market?

All YES means you're ready to Pivot. But wandering pivots are forbidden. "Users aren't coming → try something else" is escape. Pivot only on a clear data signal.

Persevere: tell "zombie" from "pre-growth"

The trickiest part. "Push further, or fold?"

Zombie project characteristics

• Users plateaued for 2+ months
• Revenue per active user is zero or negative
• Monthly churn 30%+
• Team energy is down

Pre-growth MVP characteristics

• Few users but active
• High customer satisfaction (NPS 30+)
• Low churn (≤10% monthly)
• Team has a clear next action

See the difference? Zombie = "nothing works"; pre-growth = "only scale doesn't yet."

If you chose Persevere, concentrate resources. "I'll maintain 2 hours a week" makes nothing happen. Persevere is not half-effort — it's a declaration of focus.

Kill: courage to kill, a resource-recovery strategy

The hardest but wisest choice is Kill. It's striking how rarely anyone in the Korean indie-maker community talks about it. We say "failure is noble" but stay silent about admitting failure and folding.

Signals to Kill

• 0 new customers for 3 months, or stagnant
• Monthly active users on a declining trend
• Customer feedback ends with "it's nice, but"
• The team's tone is awkward when speaking of the project

Kill is not "defeat" — it's "resource recovery"

1. Harvest data: organize feedback, interviews, root causes of failure. Asset for the next MVP.
2. Reuse tech: UI components, payment logic, auth — anything reusable.
3. Team learning retro: 30 minutes is enough to write "what did we learn?" Without it, repeat failures.
4. Public retro: write "why we folded" honestly in the community. That makes the next attempt trustworthy.

A Korean indie maker wrote in a 3-year retrospective on Disquiet: "Compared to the point I jumped in knowing nothing, organizing what I learned became the biggest asset." Kill-through-learning fuels the next success.

3-fork diagnostic workbook

Step 1. Gather data (5 min)

• New users last 4 weeks: ___
• Active user trend: up / flat / down
• NPS (Net Promoter Score): ___
• Monthly churn rate: ___%

Step 2. Read the signal (5 min)

Step 3. Kill decision checklist

• Did this project really fail to find customers, or did you under-market?
• Do you really have the energy to push 3 more months?
• Are you continuing because of sunk cost?
• Do you have a next-MVP idea?

All YES → proceed with Kill. And publish the retro. The Korean maker community still has too many success stories. Failure retros are rarer and more valuable.

Wrapping up

The data gave an answer. Whatever form it takes, now is the time for a brave choice. Pivot, Persevere, Kill — all can be right. Only ignoring the data is wrong.

You came through 16 posts, validating, building, launching. You learned from the first 100 customers. The next post (series wrap-up) explores why "someone who's built once" is fundamentally different from "someone who hasn't," and how your next MVP will be different.

References

1. Slack's Pivot — from Glitch game messenger to workplace communication (2011–2013)
2. Market Kurly & Saebyeok Delivery — AWS case study (2015 onwards)
3. Toss's expansion from transfers to fintech
4. Sunk Cost Fallacy — Wikipedia
5. 3-year retrospective on Disquiet — Doeon Kwon

Previous: Signal, Not Gut (North Star Metric)
Next: [Fail School S1 Wrap-Up] The intuition of "someone who's built once" beats the tools

Minchul Kim, CEO of Freeive, Fail School