An MVP is not a prototype. A prototype tests whether something can be built. An MVP tests whether someone will use it — and specifically, whether the core hypothesis that justifies building the full product is correct.
Every MVP should be testing one specific hypothesis. Define what a positive result looks like before you build. Teams that fail to do this interpret any user engagement as validation and any lack of engagement as an execution problem, rather than as data.
Include the minimum flow that allows a real user to attempt the core action. Cut everything that does not help test the hypothesis. Common mistake: building for edge cases before validating the core case.
A real MVP can be built in 4 to 10 weeks by a team of two to four engineers. The teams that take longer are usually building a V1 product, not an MVP — more features, better UI, more edge case coverage than the hypothesis actually requires.
Use existing tools for everything that is not your hypothesis. Auth, payments, email, storage: buy. The feature that tests your hypothesis: build. Teams that build their own auth for an MVP spent two weeks proving they can replicate existing software rather than testing whether their product idea is worth pursuing.
If the result is negative: figure out which assumption was wrong before building the next version. If the result is positive: the question is not "what should we build next" but "which constraint is now the binding one"? Scale, reliability, team capacity, or product depth — the MVP result will usually make this clear.
Axented builds MVPs for companies that want to test a product hypothesis without over-engineering the first version. → axented.com/custom-software-development
%20(1)-2.svg)
