What I ask before writing a single line of your MVP

The common instinct with an MVP is to build everything the product will eventually need, because who wants to launch something incomplete? That instinct, followed literally, is how three-month MVPs become nine-month MVPs that still haven't found a single paying customer. Before writing anything, there are a few questions worth answering first — not because process is fun, but because skipping them is the single biggest predictor of a project going over budget.

"What are you actually trying to learn?"

An MVP isn't a small version of the final product. It's the smallest thing that answers a specific, currently-unanswered question — usually "will anyone pay for this?" or "does this workflow actually work the way I think it does?" If you can't name the question, you can't know what to leave out, and everything starts to feel essential. Naming the question up front is usually enough, on its own, to cut a feature list roughly in half.

"What happens if this fails?"

Not the product — the test. If ten users try it and hate it, what do you do next? Founders who've thought this through tend to scope tighter, because they're building something they're prepared to throw away. Founders who haven't tend to over-invest in an MVP as if it were the final product, because emotionally, walking away from six months of work is harder than walking away from three weeks.

"Who is the first user, specifically?"

Not "small businesses" — a specific person, in a specific situation, who you can picture using this next week. Vague users produce vague scope. A specific first user makes half the feature debates disappear on their own, because you can just ask "would they need this to get value on day one?"

"What's the cost of being wrong about the tech choice?"

MVPs get built on stacks chosen for speed, and that's usually correct — but it's worth being honest about which decisions are cheap to reverse later (a UI framework) and which aren't (a database schema, a payment provider, an auth model). I'll spend real time on the second category and move fast through the first, on purpose.

What this looks like in practice

Before writing code, I want a one-paragraph answer to "what does this MVP need to prove, to whom, by when." Everything that doesn't serve that paragraph gets a note for phase two, not a slot in the build. It's a less exciting kickoff meeting than diving straight into features — but it's the difference between an MVP that ships and one that quietly grows into a full product nobody's tested yet.

Have an idea and a rough shape of an MVP, but want a second pair of eyes on the scope before committing budget? Let's talk it through — that conversation is free.