A Second MVP Faster Than the First — Leveraging Compounding Assets

The real strength of the second MVP is the "leftovers" from Season 1's work.

14 days → 9 days, where the difference comes from

Park shipped her first MVP in 14 days with Lovable. Marketing column auto-classifier, 100 signups, 30 active, 5 paid. 6 months later, she started the second MVP. Same domain — a marketing SNS content analytics tool.

She retraced the work needed last time:

• Login screen? She integrated Supabase auth before — one snippet, done
• API build? She used Claude API before — same pattern
• DB schema? Open the first retro doc and "this column wasn't needed, drop it"
• Design system? Pulled the first Figma components in — prototype in 2 hours

Result: 9 days. Nearly halved.

The important part: she didn't type faster. She decided smarter. She already knew what to skip and what to reuse.

The second MVP isn't faster — it's smarter. That smartness comes from the leftover assets from the first.

4 assets left over from the first MVP

1. Code: a map of patterns that worked

First-MVP code is legacy. 6 months in you can't even read your own code. Yet code is still an asset because "a pattern that worked once" remains.

What Park reused was, more precisely, the pattern "Supabase auth works like this", "Claude API calls are structured this way." Cursor and Claude Code recognize these patterns and auto-apply them to the next MVP.

The first project's code becomes the context for the second's prompts. It becomes the hint "before building this feature, check this structure."

2. Relationships: trusted-person list

After the first MVP launch, 30 of 100 signups DMed Park. The core was 5. When she started the second MVP, she sent those 5 the idea first. 3 responded, 2 self-volunteered for beta test.

Activity rate (≥3 visits/month) of 100 cold-acquired customers vs 40 warm-introduced ones is 37% vs 68%.

3. Know-how: map of traps and detours

On the first MVP, Park over-designed the schema. Adjusted columns 3 times, lost 2 days to migration. Retro note: "Next time, at MVP stage include only essentials and add after user feedback."

Second MVP didn't repeat it. From the start she separated "add after feedback" from "must-have now." Initial schema was 50% simpler and migration cost minimal.

"Just follow first-MVP know-how" gets you killed. What matters is pattern recognition. When a trap reappears in another situation, that's when you convert it into a rule.

4. Tools: configured workflow

Tools Park used in first MVP: Cursor, Figma, Supabase, Vercel, Linear, Notion. Same tools for the second. But this time setup was already done. Cursor auto-loaded extensions and custom settings from the previous project. Figma library sorted. Supabase analytics dashboard set in 5 min.

Park also learned which tools "don't fit my workflow." She ditched a project-management tool she'd planned, going straight to Linear-only for the second. Fewer options, more focus.

Compounding deliberately: the power of notes during work

The 4 assets don't accumulate automatically. Deliberate logging is essential.

During her first MVP, Park logged 10 minutes every evening on three things:

1. What I did today: "Login integration done," "DB migration #2"
2. What was slow: "Schema redesign cost 2 hours," "Figma feedback 1 hour"
3. What to do differently next time: "Add schema after user feedback," "Get a colleague to check design before prototype"

3 sentences in a Notion page, but at the end of 14 days she had a retro frame. She converted these notes into a "second-MVP checklist."

Checklist for the fast second MVP:
- Schema: only must-haves before feedback (4 → 2 columns)
- Design: copy component library first
- Relationships: pre-ask the 5 early users
- Tools: only validated combos (no new tools)

That checklist made the 9 days.

14 days vs 9 days, broken down

Biggest savings:

1. Planning: 8h saved via schema simplification
2. UI: 4h saved via component library
3. Design: 8h saved via familiar design system

Asset reuse workflow

Step 1. Right after MVP (1–2 days)

Don't: dive into marketing / add features without feedback.

Do:

• Skim the code once (30 min): "what patterns worked"
• Screenshot tool settings (30 min)
• List the 5 early users (30 min): name, contact, problem solved
• Pull "things not to do in v2" from your dev log (1h)

Step 2. While operating (over a month)

• Features no one used: "nobody touched it" → drop for next time
• Most-edited parts: "I changed this 3 times" → next time ask users first
• Time-heavy parts: "lots of time, no revenue" → deprioritize

Step 3. Just before the next MVP (1 day prior)

1. Code: open first project repo, "extract patterns only" into Cursor prompts
2. Relationships: message the 5 early users "want to see the next idea?"
3. Know-how: re-read the checklist, decide "skip this step"
4. Tools: set up validated combo first

9-day course timeline

Wrapping up

The second MVP is faster not just because of time management. It's because you're already smarter. 14 days of assets from the first make the 9 days of the second.

But beware. Faster is good, but if you make the same mistake again, you fall into the same trap faster. Next post: with the principle "a mistake seen twice is a pattern," learn to prevent your own mistakes in advance.

Previous: The Persevere Trap
Next: Don't Repeat the Same Mistake — The Craft of Pattern Recognition

About Seoyeon Park
Seoyeon Park is a fictional persona created by Fail School. GitHub Copilot productivity reports, Pieter Levels series-builder cases are real.

Minchul Kim, CEO of Freeive, Fail School