The Startup MVP Scope Checklist: What to Build First

The most expensive mistake in early product development is not picking the wrong framework or the wrong cloud. It is building six months of software before finding out whether anyone wants the one thing at the centre of it.

An MVP is not a cheap version of your product. It is the smallest thing that puts your core assumption in front of real users and gives you an unambiguous answer. This is the framework we use in discovery calls to get there — the same questions we ask before quoting a build.

Step 1: Write down the assumption you are testing

Before any feature list, finish this sentence: “We believe that [a specific group of people] will [do a specific thing] because [reason].”

If you cannot name the group, the action and the reason, the scope conversation has nowhere to anchor and every feature will sound equally important. A marketplace assumption might be: local sellers will list an item within a day of signing up, because listing takes under two minutes. That is testable. “People want a better marketplace” is not.

Step 2: Define the core loop

Every product has one loop that has to work before anything else matters. For a marketplace: list, discover, transact. For ride-hailing: request, match, ride. For messaging: find someone, send, get a reply.

Write yours as three to five steps. Everything that is not part of completing that loop is a candidate for v2 — including things that feel obligatory. Profile editing, notification preferences, onboarding tours and settings screens are where MVP budgets quietly disappear.

Step 3: Sort every feature into three lists

• Must-have — the loop cannot complete without it. Auth if the product is personalised, the create step, the consume step, the transaction step.
• Should-have — the product is worse without it, but the loop still runs. Push notifications, search filters, richer profiles.
• Later — anything that assumes success you have not measured yet. Admin analytics dashboards, referral schemes, gamification, AI recommendations, multi-language support.

The useful discipline: the must-have list should be uncomfortably short. If it takes more than about a dozen screens, the loop is probably too wide.

Step 4: Decide what done looks like before you start

Agree the launch bar in advance, because the temptation to keep polishing is strongest right before release. A workable standard is: the core loop is complete and reliable, the top three error states are handled, it works on a poor connection, and it passes store review. Everything else can ship next week.

Write down the number that tells you whether the assumption held — activation rate, repeat use within seven days, completed transactions. Decide it now, while you can still be honest about it.

Step 5: Fix a timeline and cut to fit

Set the window first and shape scope to it, rather than estimating features and accepting whatever date appears. Eight to twelve weeks is a realistic target for most MVPs we scope, and a scope that cannot fit a quarter is usually several products wearing one name.

When something has to give, cut scope rather than quality. A smaller product that works is evidence. A wider product held together with known bugs teaches you nothing, because you cannot tell whether users rejected the idea or the experience.

Step 6: Choose a stack you can live with

Two decisions matter at this stage: the client and the backend.

For mobile, that is usually Flutter or React Native, and the deciding factor is who maintains the app after launch rather than any benchmark. For the backend, managed infrastructure like Firebase gets an MVP live fastest; a custom API in NestJS, Node.js or Laravel is the right call when you need bespoke logic, complex permissions or full control of your data.

You are allowed to pick the fast option now and migrate later — as long as you make that choice deliberately and keep your data model clean enough to move.

Step 7: Plan the parts that are not code

These take longer than founders expect and cannot be compressed at the end:

• Apple and Google developer accounts, which need verification before you can submit anything
• Store listings: screenshots, description, keywords, privacy declarations and a support URL
• A privacy policy and terms that reflect what your app actually collects
• Payment or subscription configuration in each store console
• Analytics, so launch produces data rather than opinions

Step 8: Decide who owns what

Before signing with any development partner, get clear answers on IP ownership, where the code lives, what handover includes and how changes are priced. Our answers are on how we work; the point is that you should ask every partner the same questions and compare the replies.

The uncomfortable questions worth asking

• What happens if the assumption is wrong? If you have no plan for that outcome, you are building on faith rather than testing anything.
• Which feature would you cut if the timeline halved? Cut it now.
• Who is the first user, by name? If you cannot name ten, distribution is the real risk, not development.
• What have you already validated without code — interviews, a landing page, or a manual version run over email?

Where this leads

A good discovery produces four things: a scope everyone agrees on, an architecture that fits it, a realistic timeline, and a fixed price for the build. That is what our two-week MVP Discovery delivers, and the fee is credited toward the build if you go ahead.

If you would rather work through it yourself first, the free MVP scoping checklist is the same worksheet we use on those calls.