What to cut from your MVP: scoping the first version of a web app

A minimum viable product is the smallest version of a product that can prove one specific thing, usually that a particular customer will pay for a particular outcome. Most first versions fail that definition by being too big. They take twice as long, cost twice as much, and prove nothing sooner.

Scoping an MVP is mostly deciding what to leave out. This is the list we work from.

What should you cut from a first version?

Admin panels. In version one, you are the admin. Edit the database directly or use a tool like Retool. Build the panel when doing it by hand becomes a weekly chore.

Roles and permissions beyond two. "Owner" and "member" covers most early products. Fine-grained permissions can wait for the customer who asks for them and is paying.

Settings pages. Every setting is a decision you avoided. Pick a sensible default and ship it.

Multiple payment options. One provider, one or two plans. Annual billing, coupons and invoicing by bank transfer are for later.

Native mobile apps. A responsive web app tests the idea on every device. Build the app once people are using the product daily. We cover that choice in React Native vs native.

Integrations nobody has asked for. Build the one integration your first customers need. The integrations page can list the rest as "on request."

Custom reporting. A CSV export answers most early reporting requests in an afternoon.

Scale you do not have. Queues, caching layers and multi-region hosting solve problems that arrive with thousands of users. Boring, simple architecture carries a product much further than people expect.

What should you never cut?

Some things are expensive to add later or dangerous to skip:

• Authentication done properly. Use an established provider. Do not write your own.
• Backups. Automatic, and tested by restoring one.
• Error tracking. You need to hear about a failure before the customer emails.
• The core flow, polished. The one thing the product does should feel finished, even if nothing around it is.
• A way to get paid. If the test is "will they pay," they have to be able to.
• Basic security and privacy. Encrypted connections, hashed passwords, and access checks on the server, not just hidden buttons.

How do you decide what is in and what is out?

Write the test the product has to pass as one sentence:

"A clinic manager can set up their schedule and take a real patient booking within ten minutes."

Then go through the feature list and ask of each item: can that sentence come true without this? If yes, it is version two.

A useful second filter is cost of delay. Authentication is hard to retrofit, so it stays. A dark mode is easy to add later, so it goes.

How long should an MVP take?

For most web products, four to ten weeks from an agreed scope. If the estimate is six months, the scope is not an MVP yet. Cut again.

There is more detail on budgets in SaaS MVP cost and timeline: a realistic breakdown.

What does a good MVP scope look like on paper?

One page. The outcome sentence, the core flow as five to eight steps, a short list of what is deliberately excluded, and a fixed price. The excluded list matters as much as the included one, because it is what stops the scope growing quietly in week four.

That page is what our discovery week produces. If you want help getting there, see our web app and SaaS MVP development service.