'MVP' gets used as a synonym for 'cheap version of the real thing.' That's not what it's for. A minimum viable product exists to answer a specific question as fast as possible with as little built as possible — and most MVPs fail not because the engineering was bad, but because nobody agreed on the question before the building started. Here's the framework we run with founders before any code gets written.
Write the question down before the feature list
'Will people use this' isn't a question you can test — it's too vague to fail or pass. 'Will a property manager pay to automate rent reminders instead of doing it manually' is a question. The first conversation in every MVP engagement is narrowing the founder's vision down to the one or two assumptions that, if wrong, sink the business — and building only enough to test those.
One feature, built properly, beats five features built halfway
The instinct under time pressure is to widen scope to look more impressive to investors or early users. We push the opposite direction. A single workflow that works end-to-end, handles real edge cases, and doesn't fall over under actual use will get you better signal than five half-finished features that all need a caveat. Investors and early adopters can tell the difference between 'rough but real' and 'broken.'
Architecture decisions you make now, you live with for years
'It's just an MVP' is the most expensive sentence in software. The MVP is rarely thrown away — it's the foundation the real product gets built on, because the alternative (a full rewrite) is slower and riskier than most founders expect. We make the same core architecture decisions for an MVP that we'd make for a funded Series A product: a real data model, real auth, a deployment pipeline that doesn't require a human to babysit it. We just scope the feature surface ruthlessly, not the engineering discipline.
Ship to real users in weeks, not quarters
Every week an MVP isn't in front of real users is a week of assumptions compounding. Our typical MVP cycle: a one-week discovery and architecture brief, then 2–4 week build increments, each one ending in something a real user can actually touch — not a staging environment only the founder has seen.
What 'done' looks like
An MVP is done when it has answered the question it was built to answer — not when the feature list is exhausted. Sometimes that means the founder has the validated signal to raise a round and expand the build. Sometimes it means the assumption was wrong, and the right move is to pivot before sinking another two quarters into the wrong product. Both are a successful MVP. The expensive failure mode is the one that never gets a clear verdict because the build dragged on long enough that nobody can remember what question it was supposed to answer.
If you've got an idea and need it scoped down to something you can actually test in market, start a brief → — that scoping conversation is where every MVP engagement begins.