Every founder we talk to already knows they should build an MVP. Almost none of them can tell us, precisely, what question their MVP is supposed to answer. That gap is where most first products go wrong — not in the code, but before anyone writes any.
Too minimal isn't the same as viable
"Minimum viable product" gets read as an instruction to cut things. In practice, cutting the wrong things produces something that's minimal but not viable — a shell that doesn't actually let anyone experience the thing you're trying to prove. We've seen MVPs that skip authentication, skip payment, skip the one workflow the product exists to support, and keep the parts that were easy to build instead.
The test we use: if a stranger used this for five minutes, would they understand what you're claiming to offer — and could they actually do it, not just look at a description of it?
Start from the question, not the feature list
Before we scope anything, we write down one sentence: what does this build need to prove, to whom, by when. Everything else gets measured against that sentence. A feature that doesn't help answer it gets cut, no matter how easy it would be to add.
An MVP isn't a smaller version of your product. It's the smallest thing that could be wrong in a way that teaches you something.
Architecture still matters, even here
The instinct to move fast on an MVP often becomes an excuse to skip basic structure. That's the wrong trade. Skipping tests on your payment path, or hardcoding values you'll need to change in week three, doesn't make you faster — it just moves the cost to a worse time to pay it. We still separate concerns properly and still write the two or three tests that actually matter. What we skip is the abstraction you don't need yet.
// what we build first
function canUserCompleteTheOneWorkflow(user) {
return auth.isValid(user) && core.canSubmit(user);
}
// what we defer
// - admin dashboards, roles/permissions, edge-case settingsHow this shows up in our 30-day trial
This is exactly what the trial period is built around. Rather than reviewing a proposal, you get thirty days with a working version of the thing on a dedicated domain — built specifically to answer the question you told us mattered. If it doesn't, we've both learned that early, cheaply, and without a long-term contract attached to the wrong bet.
The short version
Write the one-sentence question first. Build only what's needed to answer it honestly. Don't skip the ten percent of engineering discipline that's cheap now and expensive later. That's most of what separates an MVP that teaches you something from one that just delays finding out.