MVP for startups: what to build first, what to skip

A common mistake when launching a first product is building too much: months of work and an MVP that does many things well, except the one it was meant to do, which is to prove that someone really wants it.

Here's what an MVP should contain and what can wait. It's the approach we follow for MVP development: one stage at a time.

What an MVP really is

An MVP is the smallest version of the product that lets you test the riskiest assumption in your project.

It doesn't say "beautiful", "scalable" or "complete". The riskiest assumption is usually one of these:

• Is anyone willing to pay for this?
• Is the problem painful enough for people to look for a solution?
• Does my solution work better than what people do today, even if today they do nothing?

If your MVP answers none of these questions, it's a demo, not an MVP.

Four ways to build an MVP

1. A landing page

A page that explains the product in plain words and asks people to leave their details to try it. It tells you whether the problem interests anyone. It's the smallest and quickest version.

2. The service done by hand

The final product will be automated, but at first you do the work behind the scenes. The customer fills in a form, you prepare the result and send it to them. If it works, you know what to automate. If it doesn't, you've saved months of development.

3. One feature, done well

Build only the feature the customer would pay for. No polished dashboards, no statistics, no social login: just the thing that matters. It's the right choice when the problem is confirmed and you need to check that the solution really works.

4. A closed version for a few users

The full product, but open to a few users chosen one by one and closely supported, with a direct channel for feedback (for example WhatsApp, at agreed times). The goal isn't to grow: it's to learn fast.

What can wait

Features that often end up in a first MVP "because otherwise it doesn't look serious":

• automatic payments, before you know whether anyone wants to pay: a payment link is enough at first
• a polished admin panel
• several languages
• an app to download, when a website that works well on a phone is enough
• complicated roles and permissions
• notifications and internal statistics

Every item on this list means extra weeks before you talk to your first customer.

The technology

For an MVP it pays to use widely used, well-documented tools that let you start fast and grow without rebuilding everything: a modern web framework, a managed database, ready-made services for login, payments and email. The exact choice depends on the product and goes in the quote, together with the cost of external services.

The questions I start with

When someone tells me about an MVP, I ask four questions:

1. What's the riskiest thing you still don't know?
2. What's the smallest thing you can build to find out?
3. How many people do you need to trust the answer?
4. How much time do you have before you need to prove it?

The answers usually show which of the four MVPs makes sense. The written quote then sets out features, exclusions, costs and timing.