Most founders who ask us how to scope an MVP arrive with the answer already written: a list of 30 or 40 features, each one reasonable on its own. Our job is usually to make that list shorter, not longer. NoRobots recently interviewed our founder, Vladeta Radovanović, about exactly this, and the full conversation is worth your six minutes: Build Less, Learn Sooner: Vladeta Radovanovic of Presta. Below are the ideas from that interview we use most often with founders, plus a bit of context on why they work.
Why MVP scope decides whether you learn anything
Every feature you add before launch is a guess. Every guess pushes back the day real users touch the product and tell you, through their behaviour, whether you are right. That delay is the real cost of a bloated first release, far more than the development budget.
This is not a new idea. The build, measure, learn loop at the heart of the Lean Startup principles only works if the “build” step is short enough to repeat. And when analysts look at why startups fail, CB Insights’ review of startup post-mortems keeps finding the same pattern near the top of the list: teams built something the market did not need. A tight MVP scope is the cheapest insurance against that outcome.
How to scope an MVP: start with one action
Before we discuss features, we ask one question: what is the single thing a user must be able to do for this product to prove its point?
Not the vision. Not the pitch deck version. The one action that tells you whether people care. For a booking product, it might be “a customer books a real appointment.” For a B2B tool, it might be “a team uploads their data and gets one useful answer back.”
Everything that directly supports that action goes into the first release. Everything else goes onto a list we call “after we learn something.”
The three buckets we sort every feature into
Once the core action is clear, we sort the founder’s feature list into three buckets:
- The core flow. Things the main action cannot work without.
- Trust essentials. Things that make the product feel safe and credible: login, payments, basic security, a clean onboarding.
- Assumptions. Nice ideas based on guesses about how people will use the product.
The first two buckets ship. The third waits.
A quick test helps with the borderline cases: if a feature only makes sense once you have 1,000 users, it does not belong in a product that has zero. Admin dashboards, advanced analytics, referral programs, multi-language support and complex permission systems are all real needs eventually. They are almost never day-one needs.
Do it by hand before you automate it
One of the most effective ways to shrink MVP scope is to replace features with founder effort. If an AI recommendation engine can be replaced by the founder personally sending recommendations to the first 50 users, that is weeks of development saved and a lot of learning gained.
Paul Graham made this case years ago in Do Things That Don’t Scale, and it still holds. Manual work is slow, but it shows you exactly what is worth automating. You build the machine once you know what the machine should do.
When a founder is not ready to build yet
Knowing how to scope an MVP also means knowing when not to scope one at all. In the interview, Vladeta describes the signals that come up in the very first conversation:
- The answer to “who is your customer?” is “everyone.”
- There is a long pause after “how will you reach your first 100 users?”
- The founder has talked to friends and family, but not to people who would actually pay.
- Nobody can say what customers use today to solve the problem, or why it falls short.
When those answers are vague, building the product just turns a cheap mistake into an expensive one. This matters even more now that AI tools let almost anyone ship a working MVP in a few weeks. Building is no longer the hard part or the advantage. Distribution, positioning and understanding the customer are.
That is why, when an idea is promising but unclear, we suggest our Discovery Workshop before any build. It is a short, paid phase, one to two weeks, where we map the users, the core problem, the riskiest assumptions and the smallest version worth building. It ends with a written scope and a fixed price, a clickable prototype to test with customers, or occasionally the honest conclusion that the idea needs more validation first. All three are good outcomes.
A smaller MVP scope in practice: six weeks instead of six months
The story from the interview that founders find most useful is a two-sided marketplace connecting service providers with customers. The original scope had everything: a customer app, a provider app, in-app chat, calendar-synced booking, split payouts, ratings, a loyalty program and an admin panel. Roughly six months of work before a single real booking.
During discovery we asked which side of the marketplace was harder to win. Clearly the providers, and the founder already knew about 20 of them personally. So we flipped the approach:
- A simple web booking flow for customers instead of a native app.
- A lightweight dashboard for providers instead of a second app.
- No chat, because phone and email worked fine.
- No loyalty program and no split payouts at first. The founder handled payments manually for the first few weeks.
The first version went live in about six weeks. Because real bookings started early, the founder learned things no spec could have revealed: customers cared far more about seeing availability instantly than about ratings, and providers wanted reminders much more than a fancy calendar. The features added later were the ones users asked for. Several of the features we cut never came back, because nobody missed them.
We have seen the same effect on our own delivery side. On Trinigence, a disciplined scope helped the MVP ship three months earlier than planned.
What to take away about how to scope an MVP
If you remember one thing, make it this: cutting features does not make the product weaker. It makes it sharper, because every remaining feature has to earn its place.
In short:
- Find the one action that proves the idea.
- Ship only the core flow and the trust essentials.
- Do the rest by hand until you know it is worth building.
- If you cannot name your customer or your first 100 users, validate before you build.
For the full conversation, including how we spot founders who are not ready to hire a development team yet, the NoRobots interview linked at the top of this article is worth a read.
Planning your first release?
If you have a feature list that keeps growing and a launch date that keeps slipping, we can help you cut it down to the version worth building first. Start with a Discovery Workshop and leave with a lean MVP scope and a fixed price.
