Web App MVP: Which Features Belong in Version One?

Version one of your web app should contain only what users need to complete one core job from start to finish. Everything else can wait. That smallest useful version is called an MVP, short for minimum viable product: as few features as possible, but genuinely usable by real people.

The test for every feature is simple: can users still complete the core job without it, even with a slightly clumsy workaround? If so, it does not belong in version one. The exceptions are things that are not features at all but have to be right from the first user: secure login, privacy information, backups and basic accessibility.

What an MVP means outside the startup world

Most MVP advice is written for venture-backed startups testing a market or pitching investors. If you run a small business or an early-stage company in Germany, your first version is usually more down to earth: an internal tool or a small client area that handles one workflow reliably from day one.

That changes the definition. Your MVP has to be stable and usable. It can look plain, do little and rely on manual steps in places. It cannot be insecure or lose data.

The core-job test

Start by writing the core job in one sentence, for example: "A café customer places a reorder, our warehouse confirms it and the customer gets a delivery date." Then put each feature on your wish list through three questions:

1. Can the user finish the core job without this feature?
2. Is there a simple workaround for the first few months, such as an email, an export or a phone call?
3. How often is it needed: daily, or once a quarter?

Features without which the job fails are Must. Anything with an acceptable workaround, or that is rarely needed, can wait.

Must, Should, Could, Won't: MoSCoW in plain terms

MoSCoW sorts requirements into four groups. The Agile Business Consortium describes them like this:

Its rule of thumb is short and effective: if everything is a priority, nothing is. Be strict with Must. A first version where almost everything is Must is not a first version; it is the whole project.

The scope worksheet

Worked example: from wish list to version one

Not features, but required in version one

Some requirements never appear on a wish list because they seem obvious. They cannot be postponed.

• Secure login and correct permissions: broken access control is number one in the OWASP Top 10 (2025), the reference list of the most critical web application security risks, and authentication failures are on the list too. Who can see what has to be right from the first user. In the example above, one café must never see another's prices.
• Privacy information: when you collect personal data, the GDPR requires you to inform people at the time of collection, including the purpose, legal basis and recipients (Art. 13).
• Only the data you need: fewer fields in v1 are not just cheaper; they also follow the GDPR principle of data minimisation (Art. 5(1)(c)).
• Backups: the GDPR requires among other things the ability to restore personal data promptly after an incident (Art. 32). Ask how backups are made and whether a restore has been tested.
• Basic accessibility: form fields need labels or instructions, a Level A criterion in WCAG 2.2 (3.3.2). If your app offers e-commerce services to consumers in Germany, the Accessibility Strengthening Act (BFSG) may also apply; micro-enterprises providing services are exempt. Get legal advice if you are unsure.

What can almost always wait

• Analytics and dashboards: you only know which numbers matter once there is data.
• Detailed role models: one or two roles are often enough to start.
• Live integrations: an export you process yourself bridges the first months.
• Native iOS and Android apps: a web app runs in the browser on every device.
• A second language, if all of today's users share one. If your team and your customers speak different languages, as in many international companies in Germany, it may well be a Should.
• Notifications for every edge case: one email for the most important event is usually enough.

The "Not in v1" list protects your budget

The Won't list is not an admission that something is missing. It is an agreement: these items are deliberately excluded. Put it in writing in your brief and in the quote. That keeps it clear what the agreed price covers, and later wishes get planned as an extension instead of being quietly expected.

Deciding on version two

Before launch, agree when you will talk about extensions, for example after eight weeks of use. Until then, collect what users actually miss and where the workarounds really cost time. Then run the worksheet again. Features that seemed urgent at the start often slide down the list.

Where Ichii's entry price fits

Tightly cut first versions are the kind of project Ichii's entry price is meant for: small, clearly defined web apps from €1,999 net (plus VAT), one-time. What your version one costs is only settled in a fixed quote based on the agreed functions, and every row you move to "Later" keeps the scope smaller. Complex role models, ERP connections or many integrations go beyond that range. Hosting, third-party services and technical maintenance from €29 per month are charged separately.

Your next step

Copy the worksheet, write your core job in one sentence and sort every feature. Then carry the result into your web app brief and send it with a web app enquiry. To see how each feature you cut affects the effort, read How much does a custom web app cost in Germany?. For specific cases, see Replacing a spreadsheet with a web app and Customer portal: the first version.