Freeive

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:

  1. Would launch have been impossible without this?
  2. Would users have noticed if I'd skipped it?
  3. 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

Task1st (14d)2nd (9d)Why dropped
Customer interviews5 × 1.5h2 × 1h70% already known
Tech-stack decision2 days0.5 dayRule: same as before
Dashboard design3 reviews1 reviewFirst draft + one feedback
Documentation1 day2 hoursReplaced by inline comments
Performance opt3 days0 daysPost-launch
Edge cases1.5 days0.5 dayTop 3 scenarios only
Marketing prep1 day0 daysSmall beta
Bug fixes1.5 days (open)1 day (triage)Rule: only severity fixed
Total14 days9 days35% cut

5 steps to a rule-card

  1. From the first MVP, write down 5 moments of "did I really need this?"
  2. For each moment, set a rule for "what I'll do next time"
  3. Write each rule on a card, one sentence each
  4. The day before development starts, re-read the cards
  5. 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

#failschool#season2#compression#time-management#decision-automation#perfectionism#rule-cards

Comments

Comments 0

Checking sign-in status…

Loading comments…

Recent

More notes.