MVP app development: what to cut, what never to cut
Most MVPs are not minimum. They are the full product with a few features postponed, built in the same amount of time, launched to the same silence.
The point of an MVP is not to build cheaply. It is to learn something specific before spending the real money. If your MVP does not answer a question you genuinely do not know the answer to, it is not an MVP — it is version one with a forgiving name.
Start with the question, not the features#
Before any scope discussion: what is the riskiest assumption in this business?
Usually one of:
- Will anyone pay for this?
- Can we acquire users at a viable cost?
- Will people do the unusual thing our product requires?
- Can this be built at all within our constraints?
Each of those demands a different build — and some do not need a build at all.
If the risk is “will anyone pay”, a landing page with a checkout that emails you is a valid test. If the risk is “will people log their meals daily”, you need the real habit loop and nothing else. If the risk is technical feasibility, build the hard part and skip the interface.
Teams that skip this question build the features they find most interesting and learn nothing decisive.
What to cut, specifically#
When we scope an MVP, these go first — nearly always, nearly always safely:
Admin panels. You can run early operations from the database or a spreadsheet. Admin tooling is often 20% of a build and serves nobody outside your team.
Settings. Almost every setting is a decision you should make on the user’s behalf until someone complains.
Onboarding flows. With early users you can onboard them personally. That is also better research than any analytics funnel.
Social login. Email and password ships in a fraction of the time. Add social when signup friction is a measured problem.
Multiple platforms. Pick the one where your users are. Both platforms doubles QA and release overhead for the same lesson.
Notifications. Real push infrastructure is a project. Email is usually enough to test whether re-engagement works at all.
Anything for scale you do not have. Caching layers, queues, microservices. Build the simple thing. Rewriting at real scale is a good problem.
What not to cut#
The other half, which people get wrong in the opposite direction:
Anything touching money. If you are testing willingness to pay, payment must genuinely work. Fake checkouts test curiosity, not intent.
Basic security. There is no MVP excuse for storing passwords badly or leaving data unprotected. Small user counts do not mean small consequences.
The core loop’s quality. Whatever the product is fundamentally for must work well. Cut breadth, never the depth of the main thing.
The ability to talk to users. Some way to contact the people who sign up. Their feedback is the entire return on this investment.
Analytics on the one question. Not a full dashboard — just enough to answer the thing you set out to learn.
A realistic shape#
A focused MVP is typically 6–10 senior engineering weeks: one platform, one user role, an existing or minimal backend, the core loop and nothing else.
When a quote comes back at twenty-plus weeks, the scope is not minimum. That is fine — but call it version one and plan accordingly, rather than telling yourself you are testing cheaply.
The trap on the other side#
Cutting too far produces something that fails for reasons unrelated to your hypothesis.
An app that crashes, or is confusing enough that people abandon it before reaching the core action, teaches you nothing about your idea. You will conclude “there is no demand” when you have actually measured your own onboarding.
The test: could a stranger reach the core action without help? If not, you have cut into the experiment itself.
After launch, which is where most MVPs fail#
Teams treat launch as the finish line, then spend two months adding features nobody asked for.
The weeks after launch are what you paid for:
- Talk to the first fifty users individually. Not a survey — actual conversations.
- Watch where people stop. The drop-off point is your most valuable data.
- Answer your original question honestly, including when the answer is no.
- Decide deliberately: continue, change direction, or stop.
That last option is the one nobody plans for and some projects need. An MVP that tells you clearly this will not work has done its job and saved you a year.
How we approach it#
When someone sends us an MVP scope, we usually propose something smaller. Not to reduce the invoice — a bigger build pays us more — but because the smaller version reaches real users sooner, and real users change the plan more than any amount of planning does.
If an agency accepts your MVP scope without questioning any of it, they are building what you asked for rather than what you need. Those are different services, and only one of them is worth paying for at this stage.