The most expensive mistake at the start is spending months building a product that nobody turns out to need. A minimum viable product lets you test the idea on real customers faster and for less money than a full version would. But only if it is genuinely minimal and has a clear goal.
In short
- An MVP is the smallest product that tests your main business assumption with real users.
- Three mistakes eat an MVP budget: too many features, no success metric and building what you could buy ready-made.
- After launch, downloads matter less than whether people reach the value, come back and pay.
What an MVP really is
A minimum viable product (MVP) is the smallest version of a product that tests your main business assumption with real people. The idea became widely known through Eric Ries's book The Lean Startup.
The key word is "tests". An MVP is not a cheap copy of everything you might one day build. It's an experiment that answers one question: do people need this enough to use it and pay for it.
So an MVP can be very narrow, but whatever is in it has to work well. A rough version of ten features tests nothing: users leave, and you never find out why.
Three mistakes that eat the budget
These are the mistakes that make an MVP slow and expensive:
- Too many features. Every "one more small thing" adds weeks of development, testing and support, but brings you no closer to answering the main question.
- No success metric. If you haven't decided before launch which result means "the idea works", any numbers afterwards are easy to read in your favour.
- Building what you could buy. Your own payments, sign-in or email system means weeks of work on something that already exists as a reliable ready-made service.
All three share a root cause: the wish to launch the "real" product straight away. The full version is better built once the MVP has shown what is actually worth building.
One core scenario instead of a feature list
The simplest way to cut scope is to describe one user journey, from first contact to the moment the user gets value. For a booking service, for example, that's "the customer finds a free slot and books it", not a catalogue, reviews, loyalty points and chat all at once.
- Write your main assumption in one sentence: who has the problem and why your solution will solve it.
- Describe the core scenario step by step.
- Cross out everything the scenario still works without.
- Handle rare or complex steps by hand at the start.
Manual work behind the scenes is a normal part of an MVP. The customer doesn't care whether their booking was confirmed by an algorithm or by a manager, and you save weeks of development.
Don't build what you can buy
Payments, sign-in, email and analytics are infrastructure, not your competitive advantage. For each of these jobs there are ready-made services that specialist teams have spent years refining.
A payment provider accepts cards and takes on a large part of the security requirements, because card data usually doesn't pass through your server. An authentication service gives you sign-in with Google or Apple and password recovery. A transactional email service sends confirmations and reminders and looks after their delivery.
Ready-made services come with monthly fees and tie you to a provider. At the MVP stage, that's a sensible price for speed. When the product grows, any component can be replaced with your own solution if there's a business reason to do so.
What to measure after launch, and what comes next
Downloads, page views and sign-ups are nice to see, but they say little about value. They're known as vanity metrics.
Look at three numbers instead. Activation: what share of new users completes the core scenario. Retention: whether they come back after a week and after a month. Willingness to pay: whether people reach payment, or at least a pre-order.
Alongside the numbers, talk to your first users: the data shows what is happening, and conversations explain why. Then run a short loop: change one thing, measure it, draw a conclusion.
After a few loops, you'll reach one of three decisions: grow the product, change direction (a pivot) or stop with a clear conscience. Any of them is better than another six months of building blind.
Checklist
- Write down your main assumption in one sentence.
- Set a success metric and a threshold before development starts.
- Keep a single core scenario in your MVP.
- Use ready-made services for payments, sign-in and email.
- Set up analytics for the key steps of the scenario before launch.
- Talk to your first users straight after launch.
- Plan the next iteration on data and feedback, not guesses.
How we do it at IANKO
We start an MVP at the "find the purpose" stage: our Business Analyst works with you to define the main assumption, the core scenario and the success metric, and our Project Manager keeps the scope within that scenario. At the "make it work" stage, design and development go hand in hand, so anything unnecessary is cut while it is still a mock-up. We then launch the product on the web, the App Store or Google Play, and at the "make it better" stage we learn from real use and plan the next iterations on data.
The bottom line
A good MVP is not a cheap product but a fast, honest answer to your main business question. Stick to one scenario, use ready-made services for everything that isn't your advantage, and decide in advance which number will mean success. Then every further investment goes into something that has already proved it's needed.