You build an MVP in eight weeks by spending week one not writing code, using a stack your team has shipped ten times before, and cutting scope every time a new idea shows up rather than adding it. The 56-day timeline isn't about raw speed — it's about the decisions you make before anyone opens a code editor. Most teams that miss the window miss it for the same three reasons: they start building before the scope is signed, they pick a stack they haven't shipped to production before, and they let "just one more thing" accumulate until week six looks like week two.
The methodology below is the one we run at CodeLamda on every eight-week engagement — 50+ products launched against it, and the cadence is the same whether we're building a consumer mobile app, a B2B SaaS dashboard, or an AI-first product. The week-by-week structure is deliberate: weeks 1–2 are discovery and scoping, weeks 3–7 are the build, and week 8 is launch + monitor. Every phase has a single exit criterion, and if we miss the criterion we don't move on — we re-scope.
This post walks through each week in detail: what happens, what the founder needs to do, what the engineering team ships, and what the "done" signal is. It also covers the three things we don't build in eight weeks (and why we'll push back if you ask for them), and the specific stack choices that make this cadence possible. If you want to talk through your specific scope, our MVP service page has the commercials and you can book a discovery call to walk through the doc you already have.
Why eight weeks — why not four, why not twelve?
Four weeks is enough time to ship a prototype, not a product — there's no room for user testing, production hardening, or the inevitable scope-correction conversation that happens around week three. Twelve weeks is where founder momentum starts to leak: investors lose patience, the team forgets what the original problem was, and the scope creeps by 10–15% per week. Eight weeks is the narrowest window that still accommodates a real discovery phase plus production launch, and it's short enough that scope discipline is easy to enforce — there just isn't room for "one more thing."
Week 1–2: what happens in scoping and why we don't write code yet?
Two weeks of discovery sound expensive. They're the cheapest thing on the timeline, because a week of discovery saves roughly three weeks of re-work. We run four parallel tracks: stakeholder interviews, user interviews, competitive teardown, and a technical spec. The founder is in half of those sessions; the rest of the team handles the research.
What does the founder actually do in discovery?
Shows up. Answers hard questions ("what would make us cut this feature?", "who's our second choice if this user doesn't exist?"). Signs off on a scope document at end of week 2 that explicitly lists what's not in the MVP. The last one is the most important — scope creep almost always enters through features that were never formally excluded.
What's the exit criterion for week 2?
A signed scope document, a clickable Figma prototype of every critical user flow, and a technical spec naming every service, database, and third-party dependency. If any of those three are missing, we don't start week 3. We'll burn a week re-scoping instead — it's always cheaper than building against a vague spec.
Week 3–7: how do you ship working software every week?
Friday demos. Not status updates — a working build, on staging, that the founder clicks through. Every engineer writes code expecting it to be demoed by Friday, which changes what they pick up on Monday. Three things we do differently from most teams:
- Every feature lands behind a feature flag. The staging URL always works, even mid-implementation, because incomplete features are flagged off.
- Daily Slack updates from the engineering lead — yesterday, today, blockers. Three lines, no templates. Founders get visibility without meetings.
- Weekly scope check. Every Friday after the demo, we revisit the scope doc from week 2. Anything that's crept in gets an explicit "defer/accept" decision from the founder. No silent adds.
What stack do you use in weeks 3–7 to move this fast?
Next.js (App Router), TypeScript, PostgreSQL on Supabase or RDS, Clerk or WorkOS for auth, Tailwind + shadcn/ui for UI, and Vercel or AWS for deploys. Mobile is Expo + React Native. This stack is deliberate — we've shipped it 50 times, which means there are no surprise rabbit holes in week 5. Teams that pick a "new" stack for MVP #1 usually add three weeks to the timeline without realising.
What do you not do in weeks 3–7?
Pixel-perfect polish on screens the user hasn't tested yet. Admin panels (defer to v1.1; Metabase over Postgres gets you to 1,000 users). Extensive test coverage — we write tests for billing, auth, and anything that touches money; the rest gets smoke tests plus real-user feedback in week 8. Over-engineering for scale — if the MVP doesn't survive being popular, that's a good problem, not a scope problem.
Week 8: how do you launch without breaking production?
Week 8 is the first week the app sees real users. We don't cut over on a Friday — we launch Monday morning, watch the logs for 48 hours, then ramp traffic over the next three days. Three specific things go into every launch:
- Sentry for crash reporting, tuned to filter expected noise before go-live.
- PostHog (or Mixpanel) for product analytics, wired to the real KPIs the founder committed to in week 2. No vanity metrics.
- A 30-day post-launch retainer where we fix the things real users surface. This is non-negotiable — MVPs that ship and then go silent are how startups fail their first investor update.
What's the first thing that usually breaks?
Email deliverability. Transactional mail through a new SES / SendGrid setup almost always hits someone's spam folder for the first 72 hours while reputation builds. We pre-warm wherever possible and always have a manual "send via my Gmail" fallback wired for the first week. Second most common: the onboarding flow working fine for the seed users we tested with and breaking for everyone else — this is why real-user monitoring in the first 48 hours matters more than any pre-launch test.
How do you handle scope changes the founder requests in week 8?
The same way we handle them in week 3: explicit accept or defer decision, in writing. Week 8 changes mostly get deferred to the 30-day retainer window. Founders push back; we hold the line because the biggest risk at launch isn't "we missed a feature," it's "we shipped a feature and something else broke."
What does this actually cost?
A focused eight-week MVP with our studio runs $40k–$120k depending on scope — mobile + web is the upper end, web-only is the lower. That includes discovery, design, build, deploy, and the 30-day retainer. Agencies that quote $20k for an MVP are either scoping the discovery out (bad) or staffing the build with juniors (worse). Shops that quote $300k+ are building an over-sized v1 instead of an MVP. The ceiling and floor are both a signal.
Can you do this with a freelancer or small team?
Yes, if they've shipped the same stack before and if you can be strict about scope. The methodology isn't proprietary — it's a collection of discipline patterns. What a studio like CodeLamda brings is the boringness: we've made the week-one scoping mistakes already, so you don't have to. If you want a second opinion on a scope you've already written, we'll do a one-hour review free — book the slot and bring the doc.
What's the real predictor of a successful MVP launch?
Not the stack. Not the team size. Not even the quality of the designer. It's the founder's ability to say no to scope creep — and to say it early, in writing, before it's been prototyped. Every failed eight-week engagement we've had, without exception, had a founder who couldn't cut a feature after week three. Every successful one had a founder who cut at least two features they originally asked for.
If you have a spec you're about to hand to a studio, a freelance team, or your own in-house builders, run it through this filter first: can you explicitly name three features that are not in v1? If you can, your odds of hitting eight weeks are good. If you can't, the timeline isn't your problem — the scope is. We'll walk you through it on a 30-minute discovery call if it helps.