The fastest MVP we've shipped went live in 38 days because of what we deleted in week one: a mobile app (the demo was on a tablet), a custom design system (shadcn was fine), and a hand-rolled calendar (Cal.com, white-labelled). The founder pushed back on each. The insurer who saw the demo signed a pilot two weeks later.
The playbook
Define demo day, not the product: who's watching, what must work end-to-end in front of them, what can be absent without anyone noticing. That one page is the contract.
Buy the undifferentiated parts: auth, payments, calendars, email — Supabase, Stripe, Cal.com, Resend. Custom infrastructure in an MVP is a confession that the product idea isn't interesting enough.
Cadence over heroics: Friday demos, same-day fixes for anything blocking a user action, everything else waits for Monday. Calm beats crunch across six weeks.
Ship deployed, not 'dev-complete': live infrastructure, real users, analytics on. A repo is not an MVP.
Scope to the demo that earns the next conversation. Everything else is procrastination wearing a feature's clothes.
The four times we said no
We've declined sprints where six weeks would have produced a lie: a marketplace needing both sides seeded to demo truthfully; a medtech build whose regulatory path made 'minimum' meaningless; a founder who wanted nine personas served at once; and a rebuild whose actual problem was distribution, not software. Saying no is the playbook working — a sprint that ships the wrong thing on time is still a failure.
When six weeks is wrong
Deep tech, regulated cores, and hardware don't compress this way. The honest version there is a six-week *prototype* for one risky assumption — labelled as such, never sold as the product.
- Write the demo-day definition before any backlog.
- Buy commodity infrastructure without sentiment.
- Protect a weekly demo cadence ruthlessly.
- Treat 'no' as a deliverable.