The MVP Checklist: Pre-Build, Build and Launch

A complete MVP checklist has three phases: pre-build (validation and scoping), build (the thinnest working version of the core loop), and launch (the surface that turns visitors into first users and first revenue). Missing any one phase is why most MVPs either never ship or ship to silence — most founders over-invest in the build phase and under-invest in the other two.

Pre-build: scope and validation

Confirm the problem is validated — real interviews, a specific workaround, ideally a pre-sale or waitlist commitment, not just enthusiasm. Write the one-page brief: user, problem, current alternative, wedge, and the single metric that will tell you if the MVP worked.

Draw the single user journey on one page and delete every screen that isn't on it. Decide your AI or technical stack as a product decision, weighing latency and cost against raw capability rather than defaulting to the most powerful option. If the product includes AI output, write your eval set — ten to twenty example inputs and what a good output looks like — before writing a line of application code.

Build: the thinnest working version

Deploy to a real URL by the middle of the build phase, not the end — a localhost demo hides auth issues, latency, cold starts and mobile layout problems that only show up in a live environment. Build the data model, then the single happy path, then any AI or third-party calls, then the empty and error states, in that order.

Explicitly skip settings pages, role management, onboarding tours and a second integration unless one of them is on the critical path of the single user journey you defined pre-build. Seed the product with realistic data so it never looks empty in a demo or to an early user.

Build: quality and instrumentation

Run your eval set against the live build and read every output yourself — LLM-powered features fail silently, producing mediocre rather than broken output, so deterministic tests alone won't catch degradation. Hand the product to someone who has never seen it and watch, without prompting them; every hesitation is a copy or flow problem to fix before launch.

Wire up analytics on the one metric defined pre-build before you launch, not after — you cannot retroactively measure activation you didn't track from day one.

Launch: the surface most founders forget

Build a landing page with one clear statement of what it does, who it's for, and a single call to action — resist adding three CTAs or a feature comparison table at MVP stage. Decide on pricing or a waitlist and commit to one; a half-committed 'coming soon' with no capture mechanism wastes the traffic you do get.

Write a short onboarding sequence — even three manual emails for your first ten users are enough — so early users don't churn from confusion in week one. Identify one warm channel where the people from your validation interviews already spend time, rather than spreading a first launch across five channels thinly.

Launch: first users and first signal

Prioritise ten engaged users from a warm, relevant channel over hundreds of drive-by visitors from a broad announcement — engaged users produce usable signal on your core metric, drive-by traffic mostly produces noise. Read what your metric tells you within the first one to two weeks and be honest about whether it's trending toward validation or not.

Run a short retro against the pre-build brief: did the wedge hold up in front of real users, and does the next two weeks of roadmap reflect what you actually learned, rather than the feature list from before launch.

Using this checklist inside a bigger plan

This checklist maps directly onto the middle stages of the Crossley Method — Prototype and Build MVP sit either side of the build phase above, with Launch and First Revenue picking up where the launch phase leaves off, inside the full seven-stage framework of Discover, Validate, Prototype, Build MVP, Launch, First Revenue and Scale. Treating MVP delivery as one stage among seven, rather than the whole project, is what stops teams from either under-preparing or over-building it.