MVP development for startups and new products

Start with the hypothesis

Before any design, we write down what the product must prove. For example: "small clinics in Baku will pay monthly for online booking with reminders", or "our wholesale clients will reorder through a portal instead of calling a manager". Each hypothesis implies a user, an action and a measurable result.

From there, the question for every proposed feature is simple: does the MVP fail to test the hypothesis without it? If not, it waits. The method is described in defining MVP scope.

What an MVP usually includes

• The core scenario from start to finish — sign-up, the main action, the result.
• Accounts and access, if the product is used repeatedly.
• Payment, if willingness to pay is part of the hypothesis. A manual invoice can sometimes replace an automated subscription at this stage.
• An admin panel for the team to see users and data, even if it is basic.
• Analytics of key events: where users drop off, what they repeat, what they ignore.
• A way to talk to users — an in-app message, a messenger link — because early feedback is worth more than any dashboard.

What it usually does not include

• Several user roles when one would do.
• Settings and customisation.
• Integrations that can be replaced by a manual step for the first users.
• Native mobile apps, when a responsive web app or a PWA can test the same idea.
• Perfect edge-case handling for situations the first users will not reach.

Postponed features go into a list with the reason for postponing, so the conversation is "not yet" rather than "no".

MVP vs prototype vs full product

A prototype shows how the product would work, usually without real data — it tests understanding and usability. An MVP is a working product that real users rely on — it tests demand. A full product covers the long tail of cases and scale. The differences, and when to go straight to a fuller version, are in MVP vs full product.

How the work goes

1. Hypothesis and metrics. What must be true, and what number will tell us.
2. Scope. The core scenario, the cut list, the foundation decisions.
3. Design of the core flow — clickable prototype first, then visual design.
4. Development in short iterations with a working version you can try each time.
5. Launch to first users, often a limited group.
6. Measurement and next steps: what to strengthen, what to change, what to drop.

Building for the next version

Speed at the MVP stage should not create a product that has to be rewritten from scratch. We take shortcuts in scope, not in the foundation: the data model, authentication, payments and the separation between client and server are designed to grow. If the product becomes a subscription service for many companies, multi-tenancy is decided at the start, because retrofitting it later is expensive.

What we need from you

• The problem, the target users and why you believe they need a solution.
• What you already know: interviews, pre-orders, a waiting list, a competitor that users complain about.
• One person with the authority to cut features.