How to build an MVP in 8 weeks.

What an MVP actually is

An MVP is not a smaller, worse version of your product. It is the smallest thing that can prove your riskiest assumption with real users. That definition sounds academic until you watch it save someone $50,000.

Three misreadings kill more startups than bad code ever will:

• “MVP means cheap.” No — it means focused. A focused product still needs real design, real engineering, and a real launch. Cheap and unfocused is the worst combination: you spend less and learn nothing.
• “MVP means prototype.” A prototype answers can we build it? An MVP answers should we? — with strangers using it, not friends nodding at it.
• “MVP means v1 of everything.” One job done end-to-end beats ten jobs started. Users forgive missing features; they never forgive a broken core.

Week 0 — validate before you build

The cheapest week of the whole project happens before any contract is signed. Every hour here saves a day later. Five tests, none of which need code:

• Ten problem interviews. Not pitches — ask about the last time they hit the problem. What did it cost them? What did they try? If nobody describes the pain unprompted, stop.
• A one-page landing with a waitlist. A headline, the promise, an email field. Fifty visitors and zero signups is a verdict — accept it gratefully; it was almost free.
• Pre-sell it (B2B). A letter of intent or a discounted pre-order is worth a hundred “sounds interesting” conversations.
• Competitor teardown. Existing competitors with revenue are good news — demand is proven. Your wedge is the segment they serve badly.
• Search demand. If people already google the problem, distribution gets dramatically cheaper. If nobody searches for it, plan how you’ll reach people before you build.

A studio worth hiring will ask you about all five before quoting. That’s why every engagement here starts with a discovery conversation, not a spec sheet — a good builder refuses to build an unvalidated idea at full scope.

The scope cut

Take your feature list. Your v1 keeps roughly 40% of it. That’s not pessimism — it’s the consistent pattern across every successful build we’ve shipped. The knife has three edges:

• Must — the one job, end-to-end. Auth only if the job needs identity. Payments only if you’re charging on day one.
• Should — real, valuable, and comfortably a week-9 problem. Write these down so they stop haunting the build.
• Later — most of your list. Roles & permissions. The admin dashboard (use the database console for month one). The second platform. Dark mode.

What the cuts buy you — honest ranges from real builds:

The 8-week timeline

Across 279+ delivered projects our average build goes live in about six weeks. This plan budgets eight — margin for feedback rounds and integration surprises is part of professionalism, not padding. Here is what each week looks like from the founder’s side of the table:

What it really costs

Real numbers, because “it depends” is how founders end up surprised. These are our published figures — use them as the sanity range even if you build elsewhere:

And the question behind the question — who should build it? The honest comparison:

What moves the number: integration count, native vs web, auth complexity, regulated data (health, finance), AI features, and design depth. What should worry you in a cheap quote: no milestones, no staging link, no code ownership, and “unlimited revisions” — which really means nothing is ever finished.

The 2026 stack

The stack that ships fastest without borrowing trouble later — it’s what our own builds run on:

• Web: Next.js + React, TypeScript, Tailwind. Server-rendered, fast by default, hireable-for later.
• Backend & data: Postgres (Supabase) — auth, storage, and realtime included; no infrastructure team required.
• Mobile: React Native when the product is truly mobile-first. Otherwise: responsive web now, native at week 9+.
• Payments: Stripe. Don’t be creative here.
• AI features: GPT / Claude APIs behind your own endpoints — never called from the browser, always with a graceful fallback.

And the honest part most agencies skip: sometimes custom is the wrong answer. A content site belongs on WordPress or Webflow. A standard storefront belongs on Shopify. Paying custom prices for a solved problem is scope creep of a different kind.

The seven MVP killers

• 1 · Scope creep without re-costing. The smell: “while you’re in there…”. The fix: every addition gets a price and a date, even when the answer is “free, +3 days.”
• 2 · Pixel-perfection before product-market fit. The smell: week 5 spent on hover states. The fix: the design system is week 2; after that, ship flows.
• 3 · The auth rabbit hole. The smell: roles, teams, and SSO before ten users exist. The fix: one user type at launch.
• 4 · Launching blind. The smell: no analytics events on day one. The fix: instrument the one metric before launch, not after.
• 5 · “Content later.” The smell: lorem ipsum in staging at week 7. The fix: founder writes the core copy in week 6 — nobody else can.
• 6 · The bus factor of one. The smell: a single developer, no docs, no handoff plan. The fix: code in your repo, docs as a deliverable, staging you control.
• 7 · Lock-in. The smell: platform subscriptions you can’t leave or an agency that owns your code. The fix: the ownership rule from chapter 6.

Launch-week checklist

The actual list we run before anything goes live. Print it, use it anywhere:

• Domain pointed 48h early; SSL verified on every subdomain
• Environment variables & secrets set on production — nothing hardcoded
• Analytics live, with events on the one metric that matters
• Error tracking wired and alerting to a real inbox
• Backups scheduled — and restore tested once, for real
• Privacy policy & terms published; cookie handling honest
• OG cards + favicon + sitemap submitted to Search Console
• Uptime monitor watching the two URLs that matter
• Support channel (even just an inbox) answered by a human
• Rollback plan written down — one paragraph is enough

The first 30 days after launch

Launch is the starting line. The first month has exactly three jobs:

• Watch one metric. Signups, activations, or revenue — pick the one that proves the assumption from chapter 1, and ignore vanity numbers.
• Talk to every early user. All of them. The pattern in their words is your roadmap; the features they pull from you are the ones worth building.
• Iterate weekly. Small releases every week beat a big v2 in three months. (This is also why our builds include 30 days of free post-launch support — the month after launch is where the compounding starts.)

Add features only when users pull them out of you. Push nothing. The startups that die in month two usually died of feature ambition, not feature lack.