"We'll have an MVP in six weeks" is a sentence almost every founder says, and almost none ship on time. The gap is rarely engineering speed — it's scope. Here's the playbook we use to compress the timeline honestly.
Step 1: Define the smallest valuable thing
The most common MVP mistake is conflating "minimum" with "first complete version." They are not the same. The minimum is whatever lets you test the riskiest assumption.
Three sharp questions:
- What's the one thing that, if it didn't work, would kill the business?
- What's the smallest experiment that tests it?
- What can be faked, manual, or skipped entirely in v1?
If your "MVP" includes admin dashboards, multi-tier permissions, and email digest scheduling — you're not building an MVP. You're building v2.
Step 2: Validate before you write code
The cheapest experiment is rarely software. Before committing to a build, run cheaper tests:
- Conversation tests. 20 calls with target users beats any landing page
- Concierge MVPs. Manually do the thing for 5 customers. If it doesn't deliver value manually, software won't fix it
- Smoke tests. A landing page with a clear pitch and a "buy" button (even one that says "thank you, we'll be in touch") gives you real signal
None of this is sexy. All of it saves months.
Step 3: Pick the tech you'll move fastest with
The right tech stack for an MVP is the one your team ships fastest with. Not the most scalable. Not the trendiest. The fastest. Performance and scale are problems for paying customers, which you don't have yet.
Practical defaults that work for most MVPs:
- One framework end-to-end (Next.js, Rails, Django, Laravel) over hand-assembled stacks
- Postgres unless you have a specific reason not to
- Managed hosting (Vercel, Render, Fly.io) over hand-rolled infrastructure
- Boring auth (Auth0, Clerk, or framework-native)
Step 4: A realistic 6-week timeline
If you've done validation properly and scoped honestly, here's what 6 weeks actually looks like:
- Week 1: Information architecture, data model, sketches. No code yet
- Weeks 2-3: Core flows wired end-to-end. Ugly UI is fine. Real data, real auth, real database
- Weeks 4-5: Polish the 2-3 screens users will actually see. Cut everything else
- Week 6: Onboard 5-10 real users. Watch them use it. Fix what breaks
Notice what's missing: marketing site, blog, admin dashboard, analytics dashboard, multi-language support, mobile app, integrations beyond the one you need most. All of those are post-MVP.
The pitfalls that derail every first build
- Designing the v3. Building flexibility for features you don't have yet — every "we might want X someday" adds 2 weeks
- Premature optimization. Performance work before you have load is wasted
- Custom design systems. Use a component library. You're not Apple yet
- Internal tools first. The user-facing product is what matters; admin can be a Notion doc for now
- Stakeholder polishing. Adding features so the MVP "looks ready to demo to investors" is a fast path to shipping nothing
After the MVP
An MVP that ships is a starting line, not a finish line. The next 90 days matter more than the build. Watch real users, listen for what's painful, and resist the urge to scale prematurely. Most products die in the gap between "MVP shipped" and "first 100 paying customers" — that's where the real product gets shaped.
Building an MVP and want a partner who'll fight you on scope before they fight you on architecture? That's what we do. Get in touch.