How we ship an MVP in three weeks (and why you should)
A play-by-play of our 21-day MVP process: what we cut, what we keep, and how we keep quality from collapsing.
Three weeks sounds like marketing. It's not. It's our median MVP project, and we track it. Here's how the three weeks actually go — and what we cut to make it fit.
Week 1: discovery & design
Monday morning we sit down with the founder and do scope triage. We write the feature list on a whiteboard, then cross things out until only the one feature that makes the product valuable remains. Everything else goes in the “v2” file.
By Wednesday we have a clickable Figma prototype. By Friday we've walked five target users through it and patched the parts that confused them.
What ships end of week 1:
- A scope doc the founder has signed off on, in plain English.
- A Figma prototype that feels like a real product.
- A repo, a Vercel project, a Postgres database, and a staging URL.
Week 2: build
We build the core flow end-to-end, vertically. Auth first, then the one killer feature, then billing if the product needs it. Every day ends with something new visible on the staging URL.
Our rule: if the founder can't use it on staging by Friday of week 2, we haven't earned week 3. In practice this almost never trips, because we've been aggressive in week 1 about what's in scope.
“If you can't use the product on staging by end of week 2, you didn't cut enough scope in week 1.”
Week 3: harden, instrument, ship
Week 3 is where most MVPs die — the long tail of small fixes, polish, and real-world testing that quietly eats a month. We short-circuit that by starting week 3 with a bug bash and a list of the twenty most important polish items. The rest go to v2.
- Analytics wired up (PostHog or similar).
- Error tracking wired up (Sentry).
- A basic admin dashboard so the founder can actually operate the product.
- Ship to ten real users by Wednesday. Iterate from their feedback Thursday and Friday.
What we cut
The things that feel essential and aren't:
- 1Settings pages. Default everything. If someone needs to change it, they'll email you — that's a feature, not a bug.
- 2Mobile app. Start responsive-web. Ship a mobile app in v2 if retention justifies it.
- 3Admin UI. A read-only metabase dashboard is 100× cheaper than a full admin SPA.
- 4Role-based access control. One user = admin. Add roles when you have a second user.
What we refuse to cut
Some things are non-negotiable, no matter how tight the timeline. We've learned — painfully — that cutting these creates more work than you save.
- Tests on the payment path. Ever.
- Backups. Turn on Postgres PITR day one.
- Error tracking. You cannot debug what you can't see.
- Basic accessibility. Keyboard nav and semantic HTML. It's cheap if you do it as you go.
Why three weeks is the right number
Faster than three weeks and you haven't talked to enough users. Slower than three weeks and scope creep wins — the founder has time to add features instead of waiting to see what users actually do. The magic of three weeks is that it's uncomfortable for everyone, including us, which keeps the pressure on making the right tradeoffs.
Got a project like this?
Tell us in one paragraph. A real engineer replies within a day.
Keep reading
What we actually mean by “vibe coding”
It's not vibes instead of rigor. It's vibes plus AI plus senior taste, so the boring 80% of work gets compressed into a morning.
RAG that survives production
Most RAG demos melt the second a real user touches them. Here's the minimum viable eval + guardrail setup we use on every project.