Software
Building an MVP that's actually worth building
A minimum viable product should answer a question, not just ship features. How to scope one that teaches you something.
“MVP” has become shorthand for “a smaller version of the full product.” That’s not quite right. A minimum viable product is the smallest thing you can build that answers your most important unanswered question.
Get the question right and the scope usually follows.
Start with the riskiest assumption
Every product idea rests on a stack of assumptions. For a ride-hailing app, for example:
- Riders want this service in this area.
- They’ll trust the app enough to sign up.
- They can set a pickup point quickly and accurately.
- Drivers will be available when riders need them.
Some of these you can test without code. Others only show up once real people use real software. Your MVP should focus on the assumptions you can’t test any other way.
Build the core moments well
Users judge a product on a few key moments. In a ride-hailing app, those are signing in and choosing where to go. In a recommendation app, it’s the first suggestion that feels personal.
Those moments deserve real investment, even in an MVP. A clunky sign-in or a wrong pickup location will sink the test before you learn anything useful. Everything around them, such as settings, profiles and admin dashboards, can be basic.
Cut scope, not quality
There are two ways to make an MVP smaller:
- Cut scope: fewer features, fewer screens, one user type, one city, one use case.
- Cut quality: skip security, ignore errors, hard-code everything.
The first is how good MVPs get built. The second creates a product you’ll have to throw away, often after users have already formed a bad impression.
A useful rule: anything that touches user data, authentication or payments should be built properly from day one.
Use what already exists
An MVP is not the place to reinvent solved problems. Mapping, one-time passcode sign-in, cloud databases, push notifications and hosting all have mature services and SDKs behind them. Using them means more of your budget goes into the part that’s actually new.
Plan the second version before you ship the first
The point of an MVP is what happens next. Before launch, decide:
- What will you measure, and how?
- What result would make you double down? What would make you change direction?
- Who on your side will talk to early users?
Then make sure the codebase can grow. A clean structure and sensible choices of framework and database make the second version an extension rather than a rewrite.
Where we fit
We help founders shape MVP scope, build the first version and keep building after launch. If you have an idea and want an honest read on what the first version should include, let’s talk.