Developing an MVP: Test Hypotheses Instead of Lengthening Feature Lists

You develop an MVP by formulating a testable hypothesis, building only the scope that tests it and defining a metric with a target value in advance. After two to four weeks with real users you make a deliberate decision: expand, adjust or stop.

Many software projects fail not because of technology but because of an assumption that was never tested. A minimum viable product reverses the sequence: learn first, then build out. This article shows which MVP types exist, how to cut the scope, which metrics work, what an MVP costs and how it stays technically extensible.

What an MVP Is – and What It Is Not

The term MVP is often misunderstood. An MVP is not a “cheap product” but an experiment with a clear question and a measurable result. The distinction at a glance:

Feature	Prototype or demo	MVP	Version 1.0
Purpose	illustrate an idea	test a hypothesis with real users	complete product for the market
Users	stakeholders, test participants	small, real target group	entire target group
Scope	interface, often without logic	core function works reliably	broad feature set
Metric	none	one main metric with a target value	several metrics

An MVP is also not a license for poor quality: what users see must work reliably – otherwise you are testing the bugs instead of the idea.

MVP Types: The Cheapest Answer to Your Question

Not every hypothesis needs software. Choose the simplest type that answers your question reliably:

Type	How it works	Suitable when
Landing page test	describe the offer and measure interest, such as sign-ups, appointment requests or pre-orders	it is unclear whether demand exists and the offer is understood
Concierge MVP	deliver the service manually for real customers at first, for example with spreadsheets and email	process and benefit are still unclear
Wizard of Oz MVP	the interface looks automated while people work behind the scenes	the interaction concept is to be tested before logic is built
Single-feature MVP	one core function as a lean web app	the core benefit is clear but everyday usage behavior is open
Clickable prototype	interactive model for usability tests	comprehensibility is to be tested – it does not show usage behavior

Also check whether standard software can already model the hypothesis – that often saves months. The decision aid is in the article Custom or standard software?.

Problem Before Solution: Formulating the Hypothesis

At the start is not the feature list but a clearly described problem. A good hypothesis fits into one sentence:

“We believe that [target group] has [problem] and will use [solution]. We will know when [metric] reaches [target value] within [time period].”

An example from everyday B2B that will accompany us through this article: a wholesaler suspects that its partners would rather retrieve order status and delivery times themselves than call the inside sales team. The hypothesis is therefore: self-service for partners relieves inside sales. The MVP is a lean partner portal with login and status overview – nothing more.

Cutting the Scope: Learning Value Over Completeness

Scope lists with 80 items are the opposite of an MVP. Judge each requirement with two questions: how much does it contribute to solving the core problem? And what do we learn through it about the hypothesis? Everything else goes on a “later” list – not a graveyard but a store for the next iterations. For the partner portal the result could look like this:

Feature	In the MVP?	Reason
Login for partners	yes	no test without access
Order status and delivery time	yes	core of the hypothesis
Data from the ERP via daily export	yes	enough for the test, the live interface follows later
Special requests	manual	via form, inside sales handles them by hand
Invoice archive, discount logic, own app	later	answers a different question or causes high effort without learning value

The principle “manual instead of automated” saves development time and at the same time shows which special cases actually occur in practice. Automation pays off only once the function is needed.

Defining the Metric and Decision Rule

Before the first line of code is written, stakeholders and team agree on one main metric and a target value. Depending on the product, suitable examples include:

• Activation rate: how many registered users actually perform the core action?
• Time to first value: how quickly do users experience the benefit?
• Qualified leads per week: are relevant inquiries coming in?
• Repeat usage: do users come back on their own?
• Relief effect: does the number of phone status inquiries drop, for example?

Focus on one main metric: anyone watching ten metrics will always find one that looks good. At least as important is a decision rule set in advance. Example for the partner portal: if after four weeks at least seven out of ten invited partners retrieve the order status themselves every week and phone status inquiries drop noticeably, the portal is expanded. If usage is lower, conversations clarify whether operation or benefit is the problem. If hardly anyone uses the portal, it is stopped. Put metric, target value and rule in writing so nobody moves the goalposts afterwards.

Process and Typical Mistakes

Step by step to the MVP

1. Describe the problem and target group, formulate the hypothesis in one sentence.
2. Choose the cheapest suitable MVP type.
3. Set the main metric, target value and decision rule.
4. Cut the scope, put the rest on the “later” list.
5. Test a clickable prototype with real users – this is where good UI/UX design pays off.
6. Build the MVP, include measurement from the start and launch with a manageable user group.
7. Measure and hold conversations for two to four weeks, then decide by the rule defined in advance: expand, adjust or stop.

Metrics show what happens; conversations show why. So plan a few short interviews or observed test sessions in every cycle. Cycles of two to four weeks fit well with agile methods, as described in our article Scrum in software projects.

Technology and Cost: Lean but Extensible

Staying technically extensible

An MVP may be technically simple but must not be a throwaway product. Minimum standards apply to an MVP, too: secure login, clean handling of personal data, regular backups and measurement from day one. We design architecture, data model and interfaces so that a successful test moves seamlessly into the next stage. Record deliberate shortcuts as technical debt so they are paid down later – more in the article Assessing technical debt. A web app or progressive web app is often enough to start with before native apps are decided on.

What an MVP costs: the factors

Cost factor	Effect on effort
User roles and permissions	each additional role increases interface, logic and testing effort
Interfaces	a live connection to ERP, CRM or payment is more work than a manual import
Data migration	quality and volume of legacy data determine the cleanup effort
Depth of design	clickable prototype, design system and usability tests raise effort but lower risk
Platforms	building web, iOS and Android separately multiplies the effort
Security and privacy	sensitive data and requirements call for additional measures

For budget orientation: our packages start at Starter from €2,500 and Professional from €8,000; Enterprise projects are quoted individually. For a clearly defined scope we prefer to offer a fixed price.

Typical mistakes – and how to avoid them

• Too much at once: the scope grows “by just one small thing” – again and again. Keep the “later” list strictly.
• Wrong test group: colleagues and friends are not your customers. Test with people who really have the problem.
• No decision: results are collected but not turned into consequences. Define in advance what happens at which result.
• Measuring too late: analytics is set up only after launch – the revealing first weeks are then missing.
• Technical dead end: the code is so makeshift that a successful test forces a complete rebuild.

How Nano Concepts Supports You

As part of our MVP development we accompany you from the hypothesis through the right scope and the prototype to an extensible MVP; we deliver the design together with our partner agency LOMA DESIGN. In the free initial consultation we sharpen your hypothesis together and clarify which MVP type answers your question fastest – we usually get back to you within 24 hours.