Fail School·Published 2026.05.22·Views 18
How to Make It in 5 Days — The Craft of Compression
The second MVP isn't "the same things 30% faster" — it's "not doing other things." Park's 14→9-day case, classifying 70% of first-MVP work as skippable, 3
The second MVP isn't doing the same things 30% faster — it's not doing other things at all.
How 14 days became 9
A year ago Park's first MVP took 14 days. A marketing-column classifier SaaS — but in practice she did 5 deep customer interviews, redesigned the dashboard UI 3 times, and spent 3 days on performance optimization. Then Junho Lee asked: "How many days for the second?"
Thinking about it, only 70% of what she did on the first was actually needed. Half the interviews surfaced problems she already knew. The third dashboard design was nearly identical to the first. Two months after launch, no one had mentioned performance optimization.
So the second MVP took 9 days. Not because she developed faster — because she didn't do the things she didn't need to do.
"Faster" vs "skip" — same look, different strategies
Two ways to make the second faster:
- Speed-up: do the same things faster (5 interviews more efficiently, design dashboards faster). "Optimization."
- Eliminate: don't do those things at all (2 interviews, 1 UI review, post-launch optimization). "Choice."
On the surface both look similar — 14 → 10 days vs 14 → 9 days. Internally they're totally different. A solo maker's time is finite. Speed-up has many degrees of freedom, but elimination produces a much bigger effect.
A Korean startup case: the early dev team planned 6 months for a "perfect" first version. Switching to sprint mode and cutting unnecessary features got them a first version in 2 months. Not 2x faster — they didn't do 60% of the work in the first place.
Reducing 10-things-to-do to 9 carries more psychological power than reducing 9 to 8. The former is "choice"; the latter is "acceleration."
The 70% rule: classifying first-MVP work
What counts as skippable? Open a month's worth of first-MVP records and ask:
- Would launch have been impossible without this?
- Would users have noticed if I'd skipped it?
- Would it have been a problem if I'd pushed it 2 weeks?
If 2+ answers are "no," it's in the 70% (skip pile).
Must-do (30%)
- Core feature implementation
- Minimal user testing
- Deploy and monitoring
- Critical bug fixes
Optional (70%)
- 3+ design re-reviews
- Perfect documentation
- Handling every edge case
- Full pre-launch performance optimization
- Responding to all user feedback
- Marketing collateral
Lee spent 2 days perfecting onboarding tutorials in his first AI prompt-management tool. Analysis: 80% of users skipped the tutorial. In the second, he replaced the tutorial with 3 inline hints — 2 hours of implementation.
The moment "since I did it once, do it better this time" enters your head — watch out. It's the start of perfectionism.
3 time thieves
1. Postponed decisions
When planning the second MVP, Park considered "should I change tech stack?" That one consideration burned 3 days of meetings and tests. She ended up keeping it. Daily small decisions compound into "decision fatigue."
2. Excess meetings and reports
For a solo maker, meetings are encounters with self. With a team, meetings are time sinks. There's also the "status report" temptation. Checking and writing up progress daily is itself a time thief.
3. Small perfectionism
"5 interviews — too few?" → up to 7 → analysis gets complex → +1 day. Most dangerous moment: "a week before launch." The instinct "I can fix this small bug quickly" — touching it opens unexpected ones.
Decision automation: from pattern to rule
Knowing what to drop is different from actually dropping it. The bridge is automating decisions.
Lee's rules:
- Rule 1: First version has the top 3 most-used features only. The rest in v1.1.
- Rule 2: Classify bugs by severity. Anything below medium gets pushed past launch.
- Rule 3: No decision pondering > 24 hours. Past that, default applies.
These rules take courage at first. "Really, without this feature?" But the moment you set rules, you stop re-deliberating.
Decision automation looks "rigid," but in practice it frees you from the small repeating worries.
Time savings matrix: 9 days vs 14 days
| Task | 1st (14d) | 2nd (9d) | Why dropped |
| Customer interviews | 5 × 1.5h | 2 × 1h | 70% already known |
| Tech-stack decision | 2 days | 0.5 day | Rule: same as before |
| Dashboard design | 3 reviews | 1 review | First draft + one feedback |
| Documentation | 1 day | 2 hours | Replaced by inline comments |
| Performance opt | 3 days | 0 days | Post-launch |
| Edge cases | 1.5 days | 0.5 day | Top 3 scenarios only |
| Marketing prep | 1 day | 0 days | Small beta |
| Bug fixes | 1.5 days (open) | 1 day (triage) | Rule: only severity fixed |
| Total | 14 days | 9 days | 35% cut |
5 steps to a rule-card
- From the first MVP, write down 5 moments of "did I really need this?"
- For each moment, set a rule for "what I'll do next time"
- Write each rule on a card, one sentence each
- The day before development starts, re-read the cards
- At decision moments, set "follow the rule, or re-decide" criteria
Wrapping up
The core of "5-day compression" isn't speed — it's choice. Many try to be faster; few decide not to do things at all. That difference makes 14 vs 9 days.
But getting one MVP fast isn't the end. The question is can you keep building at this pace? Next post: how a series builder runs multiple MVPs.
Previous: Don't Repeat the Same Mistake
Next: Series-Builder Ops — One Person, Many MVPs
About the characters (Seoyeon Park, Junho Lee)
Characters are fictional personas created by Fail School.
Minchul Kim, CEO of Freeive, Fail School
Comments
Comments 0
Checking sign-in status…
Loading comments…