Most founders think they know what an MVP is. Then they build the wrong thing anyway. They ship a stripped-down version of their full product vision, slap "MVP" on it, and spend six weeks building features nobody asked to use yet. That's not what a minimum viable product is for.
An MVP isn't a prototype — a prototype just proves an idea can technically work. An MVP proves people will actually use it, and ideally pay for it. It's not a beta either, which implies a near-finished product with a few bugs left to shake out. And forget "version 1 with fewer features." A real MVP gets built around one question: does this specific job, done this specific way, create enough value that a real user comes back?
That framing changes how you plan the work. You're not building a smaller company. You're running a structured experiment, and the working product is just the instrument. The old 80/20 rule applies here harder than anywhere else in the business — 20% of your product idea creates 80% of the value for your first users. Your only job for six weeks is finding that 20% and shipping it.
This guide walks through a realistic 6-week process for building an MVP, from scoping to launch. It's the same process we run with founders inside our MVP development work, adapted so you can use it yourself or brief a team on it.
Week 1: Define the MVP scope
Week one isn't about building anything. It's about deciding, in writing, what you're not going to build.
Start with jobs-to-be-done thinking. Instead of listing features, describe the one job a user hires your product to do. Not "manage tasks" — "know exactly what to do next without opening five tools." Not "connect with people" — "find a compatible roommate before my lease starts." The sharper that job description gets, the easier every later decision becomes. You can hold any feature up against it and ask: does this help finish the job, or is it scope creep wearing an ambition costume?
Once the job is defined, map the critical user workflow — the single path a user takes from "I have this problem" to "I got the value." People call this the happy path. Draw it as a literal sequence of screens or steps: sign up, input X, see output Y, take action Z. Everything on that path is v1. Everything off it, no matter how compelling, waits for v2.
This is where most MVP scopes go sideways. Founders build the happy path, sure, but also the settings page, the admin dashboard, the referral system, and three login methods — because each one seems small on its own. Apply a ruthless filter here: if a user can still complete the core job without a feature, that feature doesn't belong in week one. Write your v1 and v2 lists side by side. Treat the v2 list as a promise you'll revisit later, not an excuse to sneak in "just one more thing" now.
By the end of week 1 you want a one-page scope document: the job, the happy path, the v1 feature list, and an explicit v2 parking lot.
Week 2: Design the fastest path to value
Scope is locked. Now week 2 is about designing the shortest route from "user arrives" to "user experiences the core value" — without touching code yet.
Start with low-fidelity wireframes: boxes and labels, not polished mockups. High-fidelity design this early creates a false sense of completion, and it makes people emotionally attached to details that should still be up for grabs. Sketch the happy path screen by screen. Focus on the sequence of decisions a user makes, not how pretty it looks.
Before any of that goes into a design tool permanently, test it with five target users. Show them the wireframes, walk through the flow, watch where they hesitate or ask a question you didn't expect. Five isn't arbitrary — usability research keeps showing that the first five users surface most of the obvious friction points, and past that you hit diminishing returns until your sample gets much bigger. Nothing has been built yet, so this is the cheapest feedback loop you'll ever get.
Once the flow holds up, lock in basic design system foundations: a small set of color tokens, a spacing scale, reusable components like buttons, inputs, cards. Skip the full design system. What you actually need is enough consistency that the interface reads as one product, not five screens stitched together. This pays for itself the moment development starts — engineers stop guessing at spacing and states.
Weeks 3 and 4: Build the core product
Most of the calendar time goes here. It's also where scope discipline matters most, because once things are visibly working, the urge to add "just one more thing" gets strong.
For most MVPs we default to Next.js, Supabase, and Vercel. Next.js gives you one codebase for frontend and API routes. Supabase handles auth, database, and storage without you standing up your own backend infrastructure. Vercel handles deployment and preview environments with zero DevOps overhead. It's not the only valid stack, but it clears an enormous amount of infrastructure decision-making that has nothing to do with testing your actual product hypothesis. Our services page covers the broader stack options we reach for depending on the product.
On sequencing: build frontend-first for most consumer and B2B SaaS products. Wire up real UI against a lightweight backend as you go, rather than building a complete API layer before a single screen exists. Frontend-first keeps you honest about what the user actually sees, and it forces backend decisions to follow real interface needs instead of speculative data modeling. API-first makes more sense when multiple clients — web, mobile, partner integrations — need the same backend from day one, or when the core value is the data processing itself rather than the interface.
A few integrations are non-negotiable even in an MVP. Authentication, so you have identifiable users to learn from. A payment provider, if you're planning to charge anyone during the test. Analytics on the handful of events that actually define success. Skipping analytics to save a day of work is the single most common regret we hear from founders after launch — without it, week 5 turns into guesswork instead of measurement.
What you shouldn't build in weeks 3 and 4: admin tooling beyond what you personally need to run the product, edge-case error handling for scenarios unlikely in a small beta, internationalization, anything that only matters at a scale you don't have yet. All of that is legitimate work eventually. None of it teaches you anything in week 5.
Week 5: Test with real users
Recruit your first 10 beta users on purpose, not whoever's around. Friends and family are convenient, but they tend toward polite instead of honest. Look for people who actually have the problem your product solves — communities, waitlists, your own network of people who fit the target profile. Ten is plenty to spot patterns without drowning in noise.
Collect both qualitative and quantitative feedback. Quantitative signals — completion rates, drop-off points, time to first value — tell you where the friction sits. Qualitative feedback, a 15-minute call or a short survey or an in-app prompt, tells you why. Neither works alone. Numbers without context turn into guessing. Opinions without numbers turn into building for whoever complains loudest.
A few signals tell you it's time to ship: users complete the core workflow without you explaining anything, several ask when they can keep using it or pay for it, and the feedback shifts toward refinement — make X faster, add a bit more to Y — instead of confusion about what the product even does.
The opposite signals tell you to pivot the scope: users get stuck at the same step every time, people describe the product back to you incorrectly (the value proposition isn't landing), or everyone's polite but nobody asks to keep using it. That last one is the quiet killer. Enthusiasm expressed as feedback isn't the same thing as a person opening your product again on their own.
Week 6: Launch and measure
Launch mechanics shouldn't be a surprise in week 6. Nail down your deployment checklist early: production environment on Vercel, a custom domain pointed correctly, SSL on by default, and a staging environment where you can still push test changes without touching production.
Analytics setup deserves more care than most founders give it. Decide on the 5 to 10 events that actually indicate product usage — sign-up completed, core action taken, return visit within 7 days — and instrument those before launch day, not after. A tool like PostHog, wired to specific named events instead of generic page views, gives you something to build funnels and retention charts on later.
On day one, watch three numbers closely. Activation rate: the percentage of sign-ups who complete the core workflow once. Early retention: who comes back within a few days without being prompted. And any error or support signal suggesting something's broken rather than just imperfect. Don't overreact to a slow first day. Do react fast to a broken core flow.
The hardest discipline in week 6 and after is resisting scope creep dressed up as iteration. Every piece of user feedback will tempt you to add something. Run every request through the same filter you used in week 1: does this help more users finish the core job, or is it an entirely new job? If it's a new job, it goes on a future roadmap — not this week's sprint. Founders who ran through our founder launch checklist before going live tend to catch these operational gaps — analytics, mobile behavior, basic SEO hygiene — before they turn into week-7 fire drills.
Our take
Most MVP advice treats speed as the only variable that matters. We'd argue that's wrong. Speed matters, sure, but only in service of a sharper question: what's the fastest way to find out you're wrong?
The founders who get the most out of an MVP aren't the ones shipping the most features in six weeks. They're the ones who ship the smallest thing that can prove or disprove their core assumption, treating every week as a chance to cut scope instead of pile it on. We've watched a team burn eight weeks perfecting an onboarding flow for a product that, once tested, needed a completely different core workflow. All that onboarding polish, wasted. The six-week timeline isn't magic either — it's a forcing function, tight enough to make the ruthless scoping calls unavoidable instead of optional.
If there's one habit worth taking from this guide, treat your MVP roadmap as a list of assumptions ranked by risk, not a list of features ranked by how exciting they sound. Build to test the riskiest assumption first. Everything else waits.
An MVP is a learning tool, not a finished product. Its job is answering a question quickly and honestly — not impressing anyone with how complete it looks. Build it small, test it with real people, and let what you learn in week 5 decide what week 7 looks like. That beats any amount of upfront planning.