2026-08-14 · 6 min read
MVP Development Checklist: What to Have Ready Before You Build
"I need an MVP" is a starting point, not a brief. Most of the cost and timeline uncertainty in early MVP conversations comes from the same handful of questions not being answered yet — not because they're hard, but because they haven't been asked. Here's a working checklist, followed by the question worth answering before any of it: whether a full MVP is even the right thing to build right now.
The checklist
Name every distinct user role, not just "users." An MVP with employers and candidates, or admins and members, needs permission logic designed from the start — retrofitting a second role onto a single-role data model later is a real rebuild, not a small patch. If you're not sure yet whether there's one role or two, that's worth resolving before scoping starts, not during the build.
Write down the one core action, and be honest about what's secondary. Every real product has one thing it needs a first-time user to actually do — post a job, submit an application, create a board. Everything else supports that action or it's scope for a later version. An MVP that tries to be complete instead of focused takes longer to build and is harder for an early user to understand.
Decide what "production-ready" needs to mean for this specific project. Real authentication and a real database schema are close to non-negotiable for anything taking on actual users. Payments, real-time updates, and admin tooling are not automatic — they're worth listing explicitly as "in scope" or "deferred to v2," rather than assumed either way.
Know what already exists. A Figma file, a rough sketch, an existing spreadsheet the tool needs to replace, or genuinely nothing yet — each of these changes the starting point of the scoping conversation, and being upfront about it (rather than describing more polish than actually exists) gets to an accurate estimate faster.
Have a real answer for "who's the first user." Not a market size — a specific person or account. An MVP scoped around a real first user tends to ship with a feature set that's actually useful; one scoped around an abstract "target market" tends to accumulate features nobody asked for yet.
Decide the budget shape, not just a ceiling. Fixed price after scoping, or hourly with a cap — either is workable, but going in without having decided is how "we'll figure out cost as we go" becomes the most expensive sentence in the whole project.
Before you build it — the question a checklist can't answer
A checklist assumes the answer to "should I build a full MVP right now" is already yes. That's worth checking first.
Do you already know people want this, or is that still the open question? If the honest answer is "I think so, but I haven't tested it," a full MVP — with real auth, a real schema, and the corresponding cost and timeline — might be answering a question that a much smaller, cheaper validation step (a landing page, a waitlist, a handful of customer conversations) could answer first, for a fraction of the cost. Building the expensive version to answer a cheap question is a common and avoidable way early-stage budget gets spent on the wrong thing.
Is the differentiator technical, or is it distribution and timing? Some products need real technical depth to prove the concept at all (an AI feature, a novel matching algorithm). Others are a reasonably standard product where the actual bet is on getting to a specific market before someone else does — and for that second kind, "production-ready" mostly means "doesn't break the moment it has real users," not "technically novel."
What happens if it works? If the honest plan is "get 50 signups and see," the MVP needs to hold up to 50 real users without falling over — which is exactly what "production-ready" buys, versus a prototype that would need an emergency rebuild the week it actually starts working.
When a full MVP is still the right call
None of this means MVPs are usually the wrong move — for a product where the core mechanic genuinely needs proving with real usage, and the team already has some signal that people want it, building it right the first time is faster and cheaper than the prototype-then-rewrite path most projects default into. The checklist above is exactly what makes that first build fast, because none of it needs to be figured out mid-project.
If the checklist above describes where you actually are, here's what production-ready MVP development looks like at Nordbüro, including a real example of the timeline that kind of scoping makes possible. If you're still validating the idea itself, say that upfront — that's a smaller, different, and entirely legitimate first step.