An MVP is a question, not a small product
Most MVPs are too big because they are scoped as a smaller version of the finished product. A better frame is to treat the MVP as the cheapest way to answer one specific question, such as “will traders pay to have their record verified?” or “will clients use a portal instead of email?”
Write that question down before you list a single feature. Every scope decision after that becomes easier, because each feature either helps answer the question or it does not.
What to keep
Keep the smallest set of things that lets a real user complete the core job from start to finish and lets you learn from it:
- The core loop, end to end. If the product is about booking, someone must be able to find, book and receive confirmation. Half a loop teaches you nothing.
- The moment of trust. Whatever makes a user believe you (a verified badge, a secure payment, a clear privacy promise) has to be real in version one.
- Just enough onboarding for a stranger to succeed without you on a call.
- Measurement tied to your question: a handful of events you will actually look at, not a dashboard of everything.
- The minimum you need to operate it, even if that is a protected page and a spreadsheet.
What to cut, or at least postpone
These are the features that most often creep into first versions without helping answer the question:
- Extra user roles. Start with the one or two that the core loop needs.
- Settings and preferences. Choose sensible defaults and let feedback tell you which ones people want to change.
- Social features beyond the core, like follows, likes and profiles for their own sake.
- Native apps, if a progressive web app can do the job while you learn.
- Automation of rare tasks. Do them by hand behind the scenes until the volume hurts.
- Complex pricing. One plan, or two at most, rather than a matrix of tiers and add-ons.
- Integrations with tools only a few customers use.
The corners you should never cut
Small is fine. Fragile is not. An MVP still carries real users' data and your reputation, so some things belong in version one no matter how tight the budget:
- Security basics: proper authentication, encrypted connections, and access rules checked on the server rather than hidden in the interface.
- Backups and a way to restore them.
- Accessible, readable interfaces. Retrofitting accessibility later costs more than doing it now.
- Clear error messages, so a failure does not look like a dead product.
- Terms, a privacy policy and honest copy about what the product does today.
Choose the first users before the features
Scope depends on who will use the first version. A product for ten hand-picked customers you can talk to every week needs far less polish, onboarding and self-service than one launched to the public from a landing page. Naming those first users, ideally as real people or companies, is one of the most effective ways to shrink an MVP.
It also changes what you measure. With a small group you can learn more from a conversation than from analytics, so you can postpone much of the tracking and reporting work until the audience grows beyond the people you can call.
Scope in phases, not in one list
A single long feature list invites everything in at once. A phased plan forces a sequence. Verus is a useful example from our own work: requirements, brand direction and integrations were agreed in a statement of work before any screens were drawn, and the build then shipped in milestone releases. Each release was something the founders could review and put in front of users, rather than a long wait for a big launch.
Forjwell One, the client portal we built for ourselves, was scoped the other way round: straight from how the agency already worked. We moved every engagement onto it and ran the business on it daily, which is how its gaps were found and closed. Using your own MVP in anger is one of the fastest ways to learn what actually matters.
A simple sorting exercise
Put every feature idea in a list and give each one exactly one label. Now: required to answer the question. Next: useful once the answer is yes. Never: interesting, but not this product. Anything labelled Now should be explainable in one sentence that mentions the question. If it cannot be, it probably belongs in Next.
Then estimate only the Now column. If that is still more than you want to spend, the question is too broad. Narrow it, rather than squeezing the same scope into a smaller budget.
Signs your MVP has grown too big
Watch for these during planning and during the build:
- Launch keeps moving because “one more feature” is needed first.
- You cannot say which metric will tell you whether it worked.
- More time goes into admin tools and edge cases than into the core loop.
- The first users you will show it to are still hypothetical.
Where to go from here
Cutting scope is uncomfortable because every feature on the list felt important when it was added. It helps to have someone outside the idea ask “what question does this answer?” for each one. That is most of what a good product strategy session does. If you would like a second pair of eyes on your list, our strategy call is free and starts with a mutual NDA.
