Prototype Sprint vs MVP: What to Build First (and why it matters)

The “prototype sprint vs MVP” question looks like a product question. It’s usually a cash and time question.

Build the wrong thing first and you either:

spend weeks polishing something you can’t ship, or
ship something brittle that you can’t iterate on without fear.

Here’s how I separate the two, and how I help founders choose the right first move.

The difference in one line

A prototype proves the idea is worth building.
An MVP proves users will actually use it (and that you can ship it safely).

If you try to do both at once, you usually get the worst of each: too slow to learn, too shaky to launch.

What a prototype sprint is (in practice)

A prototype sprint is a time-boxed build meant to produce a demo people can click.

I like the 3–5 day shape because it forces discipline:

one “hero” flow
one user type (or minimal roles)
fake data where real data isn’t required to learn
the least backend needed to make it feel real

If you’re raising or selling, this is the fastest way to get out of abstract conversations.

If you’re curious, the closest current offering on my site for this stage is: Codebase audit + fixes shipped

What an MVP is (in practice)

An MVP is the smallest launchable product.

That word matters: launchable means it survives real users, not just a demo.

A launchable MVP usually includes:

real auth and permissions
real data persistence (with migrations that won’t wreck you later)
production deploy + monitoring
basic admin tooling so you can unstick yourself
a clear “v1 is done” definition

This is the shape I build in production hardening work: Production readiness

The decision guide (use this, not vibes)

Here’s the simplest rule that holds up in real work:

Start with a prototype sprint if…

You’re still validating the pitch and positioning.
You need something to fundraise with.
Your biggest risk is “nobody wants this.”
You can’t describe the data model yet, because the workflow is still fuzzy.
You want to test a behavior (not build infrastructure).

Start with an MVP build if…

You already have demand (waitlist, LOIs, paying users, or a clear channel).
Your biggest risk is execution: shipping, onboarding, retention.
You need real integrations (payments, auth providers, internal systems).
You know the core flow and you’re ready to commit to it.

If you’re not sure, ask this one question

What is the next decision this build must unlock?

If the next decision is “is this worth building?” → prototype sprint.
If the next decision is “will users stick?” → MVP.

Example scopes (so you don’t build a half-MVP)

Most teams mess this up by trying to “just make it real enough.” That phrase is a trap.

Here are concrete example scopes.

Example prototype scope (fundraising demo)

Landing page + onboarding flow
One core workflow end-to-end (with seeded/fake data)
Light admin “reset demo data” button
Basic analytics (what did they click?)
A short technical plan for the MVP

What it intentionally avoids:

perfect roles/permissions
billing
full error handling for every edge case
scaling work

Example MVP scope (paid pilot launch)

Auth + roles (even if it’s just “owner” and “member”)
One core workflow end-to-end with real data
Emails/notifications only where necessary
Deploy + monitoring + backups
Stripe (if you’re charging)
Export (if your users need it)

What it intentionally avoids:

team features before you have single-user retention
five dashboards you won’t look at
“settings” pages no one touches

The common failure modes (and how to avoid them)

Failure mode 1: The beautiful prototype nobody can use

It demos well, but it’s not built for real data or real accounts.

Avoid it by defining one post-sprint deliverable:

An MVP scope cut you’re willing to commit to next.

Failure mode 2: The MVP that’s secretly a prototype

This is the “we launched” product where:

permissions are hand-wavy
billing is manual
data is fragile
every new feature breaks something else

Avoid it by making a small list of non-negotiables:

auth boundary is correct
data model is intentional (even if it’s small)
deploy is repeatable
monitoring exists

Failure mode 3: The half-build (prototype + MVP at once)

This happens when you refuse to cut.

The fix is simple and hard: pick one win condition for the next two weeks.

My default recommendation for founders

If you’re early and moving fast, this sequence wins more often than it loses:

Prototype sprint (3–5 days) to validate behavior and story
MVP scope cut (same week) to lock the first launch shape
MVP build (2–6 weeks) to ship something you can keep
Retainer/ongoing shipping if the product is live and growing

Want help choosing the right first build?

If you send me your idea, your timeline, and what you need the build to prove, I’ll tell you:

whether I’d start with a prototype sprint or an MVP
what I’d cut first
what “done” should mean for v1

Use the call template: /call/ or email [email protected].