MVP - what to cut and what to keep

An MVP is the smallest version of a product that lets you test an important hypothesis with a real user and gather a reliable signal for the next decision. It may be a working application with narrow scope, but it must not be confused with a randomly unfinished version of a larger system.

The difficulty is that “what to cut” is a business decision that is often made technically. Use the following test.

The three-question test

Ask these questions about every feature:

1. Can the main flow be completed end to end without it? If not, it stays. If yes, it is a candidate to cut.
2. Would its absence block rollout for the first real user? Not an ideal future customer — the first one. They may be different people.
3. Would postponing the decision create disproportionate cost or risk? If it concerns data boundaries, permissions, or compliance, design the necessary minimum now. The fact that a future change will cost a little more does not justify building the whole future feature.

The third question prevents false savings. Not everything can be added later without cost, but that does not mean designing the entire future architecture in the first version.

What can often wait

• An admin panel for everything. Start with only the secure operations needed to support the first version. Direct database access must not replace permission control, an audit trail, and backups.
• Multilingual support without a current audience for it. It adds work to screens, messages, content, and tests. Do not defer it if the first version genuinely serves several languages or law or contract requires it.
• Extensive reports. At first, use the smallest indicator set needed for the decision under test. Add diagnostic views from user questions and issues revealed in data.
• Notifications in every channel. Begin with channels required by the key flow and risk; add variants after verifying use.
• Configurability without a confirmed need. A settings panel is justified when users really need to change a parameter often or the solution must support distinct variants. Otherwise, explicit team-maintained configuration is enough.
• An AI layer when it is not the product’s core. Adding an assistant to an application with no users yet is unmeasured cost.
• Integrations “for the future”. Connect only the systems without which the process cannot close.

What not to cut without assessing risk

These are often treated as features for later even though their absence can raise the cost of failure, rebuilding, or supporting first users:

• A data model with sound boundaries. This does not mean anticipating every future feature. It means identifying core concepts, data ownership, and relationships required by current scope. An overbuilt model raises MVP cost too.
• Authentication and permissions appropriate to current scope. Adding access control late requires reviewing screens, operations, and data. Permissions will evolve, but secure first-version boundaries must be agreed before users enter.
• Backups with a tested restore. Creating a backup alone does not prove it can be restored in the required time. Match test scope and frequency to data value and acceptable downtime.
• Basic monitoring and logs. Without them, the team cannot reconstruct an error and is often left only with a vague user report.
• Error handling visible to the user. An application that shows an empty window on failure appears broken, even if its core logic is flawless.
• A test on real data. An application that works on three sample records can fall apart on ten thousand.

Rule: cut features, not requirements needed for the safe operation of current scope. Every “foundation” must arise from the MVP’s risk and use, not from a hypothetical version years away.

How to recognise that an MVP is too large

Four warning signs:

Signal	What it means
No deadline or budget limit	scope has no real boundary
You cannot describe it in one sentence	scope is not settled yet
Every new role needs its own flow and permissions	check whether it is necessary for the hypothesis under test
The answer to “what if we do not build this?” is “it would look nicer”	it should go

How to recognise that an MVP is too small

An overly narrow scope may not deliver a reliable test either:

• The promised outcome cannot be tested. A manual step or spreadsheet may be a deliberate MVP part if the user still receives value and the team measures the right hypothesis.
• There is no way to measure whether it helped. Without a baseline and indicators aligned to the hypothesis, you cannot tell whether to continue.
• The version is so narrow that users cannot see value. Then you get indifference rather than feedback.

How much does it cost?

Our August 2026 range for an entry product is 15,000–35,000 PLN net, approximately 4–6 weeks, and a fixed price for defined scope. The timeframe assumes one key journey, available data, and a limited number of integrations; a larger scope is a separate project. A fixed price requires acceptance criteria, client-side assumptions, and change-handling rules.

If scope is not clear yet, the first stage can be discovery for 3,000–8,000 PLN net, which organises assumptions needed for estimation. See how much a web application costs for more ranges.

What to do after MVP delivery

An MVP is not the goal; it is a tool for the next decision. Set the measurement window by use frequency and the behaviour being tested:

1. Compare use with the expected task. No use can mean a redundant feature, but also a discoverability, access, or audience-selection problem.
2. Collect questions, not requests. “Where do I find X?” points to an interface issue; “I want Y” is one person’s idea.
3. Choose the next phase from data. That is why scope discipline matters.

Frequently asked questions

Can an MVP be expanded later, or must it be rewritten?

It can usually be expanded if scope has clear boundaries and the data model and permissions fit the current process. No one can promise that rebuilding will never be needed: a business-model, scale, or regulatory change can require different architecture.

Does an MVP have to look good?

It must be understandable, accessible, and coherent enough that visual design does not distort the test result. Brand refinement matters more in a customer-facing product, but an internal tool still needs a clear hierarchy, error states, and feedback.

Who should decide what features are cut?

The person accountable for the business result should decide together with the technical team, security, and, where needed, legal counsel. Cost is one criterion, but it must not obscure a feature’s impact on the hypothesis and safe operation.

---

We offer an MVP in 4–6 weeks at a fixed price for agreed scope because phasing reduces risk for both sides. If you have an idea and do not know what belongs in version one, contact us.