The MVP Scoping Questions We Ask Before Any Project Starts

Most MVP projects don't fail because of bad code. They fail because the scope was never actually defined before development started, and every week of building surfaces a new decision that should have been made on day one. Here are the questions we ask before we agree on a price for any project, not to slow things down, but because answering them upfront is what makes a 2-3 week build possible instead of a 2-3 month one.

1. What is the one thing this MVP has to prove?

An MVP isn't a smaller version of your full product. It's the smallest thing that answers your riskiest open question. If the risk is "will anyone pay for this," the MVP needs a checkout flow more than it needs a polished dashboard. If the risk is "can we actually deliver the service reliably," it needs the operational backend more than a marketing site. Naming the actual risk changes what gets built first.

2. Who are the first 10 real users, specifically?

Not a persona, actual people or a specific, findable segment. "Small business owners" is not specific enough to design an onboarding flow around. "Restaurant owners in Islamabad who currently take orders over WhatsApp" is.

3. What happens manually on day one, and what has to be automated?

Almost every early-stage product runs partly on manual process behind the scenes, a founder manually confirming orders, a spreadsheet standing in for a real database. That's fine, and often correct. The scoping question is deciding, explicitly, which parts stay manual for now and which parts genuinely can't, rather than defaulting to "automate everything" and tripling the build.

4. What's the smallest data model that supports this?

Before any UI gets designed, we map out the actual data: what a "user," "order," "listing," or "booking" needs to contain at minimum. This single exercise usually cuts 30-40% of imagined scope, because half of the "must-have" fields turn out to be nice-to-haves once you write down what the MVP actually needs to function.

5. What's genuinely out of scope for version one?

This is the question people are most tempted to skip, and the one that matters most. Every feature you explicitly rule out now is a feature you don't have to defend cutting later, mid-build, under time pressure. We write this list down alongside the in-scope list, not as a wishlist for "phase two," but as a real boundary.

What this looks like in practice

This is the same process behind builds like Grill Bucket's ordering platform, where a customer-facing site plus a full admin dashboard shipped in under two weeks because the scope was locked before development started, not renegotiated during it. Once these five questions are answered, we agree on a price together and put the scope in writing. See how we price projects for the full process, and our web app development page for what a typical build includes.

If you're earlier than this, you don't yet know the answers to questions 1-3, that's a legitimate stage to be at. It just means the next step is customer conversations, not a development kickoff call.