If you're reading this, you're probably wondering what an MVP is and whether it's really worth building one before you develop your full product. Here's the short answer: an MVP (minimum viable product) is the smallest possible version of your product that lets you validate whether your idea has a market, without spending the next two years' budget on something nobody may want.
I've spent more than a decade watching startups get off the ground in Spain. The ones that survive their first year usually have something in common: they launched early, they launched ugly and they launched while listening to users. The ones that sink are almost always those that took 14 months to release the "final version" and discovered, with the money already gone, that customers wanted something else.
In this article I'll explain what an MVP really is (not the textbook version), why skipping it is an expensive mistake, how to approach it if you're launching your startup MVP this year and which signals tell you you're ready to scale. No fluff.
What exactly is an MVP (and what isn't it)?
Let's clear this up, because there's a lot of confusion. A minimum viable product is the simplest version of your product that can deliver real value to a user and, above all, generate validated learning. The original definition comes from Eric Ries in The Lean Startup, and although the book is a few years old now, the core idea still holds: build only what you need to answer the riskiest questions in your business model.
Pay attention here, because almost everyone gets this wrong: an MVP is not a demo, a landing page with a form or a wireframe in Figma. Nor is it "version 1.0 with fewer features." An MVP has to be usable by a real person, in real conditions, and it has to let you measure specific things: Do they use it? Do they recommend it? Do they pay for it? Do they abandon it on day three?
MVP vs prototype vs proof of concept (PoC)
People mix them up all the time. A prototype is a visual or interactive mockup used to validate the design or the flow, usually with no working code behind it. A proof of concept (PoC) shows that something is technically possible ("yes, we can connect Holded with this logistics API"). An MVP is already a product a customer can actually use, even if it has only the bare-minimum features and the design could be better.
If all you want is to validate a purchase flow, a Figma prototype may be enough. If you want to know whether people will pay, you need an MVP. The difference is huge, and it translates directly into budget.
Why skipping the MVP is a startup's most expensive mistake
Here's the important part. When founders skip the MVP, it's usually for one of two reasons: either they're in love with their idea ("I already know what the customer wants") or they have an impatient investor asking for "something professional, now." Neither is a good advisor.
Several industry studies on startup failure (CB Insights, Failory) agree that between 35% and 42% of projects fail for the same reason: there's no market for what they built. Not lack of funding, not a bad team, not competition. They built something nobody wanted to buy. And that, notice, is exactly what an MVP is designed to prevent.
Launching without an MVP is like opening a 200-cover restaurant without ever having cooked for more than 10 people. It might work out. Statistically, it doesn't.
A route-planning platform might include a driver app, an admin back office, ERP integration and analytics. Building all of it before validating demand is risky: an MVP lets you first check what users need and whether they're willing to pay for it.
How to define the scope of your minimum viable product
This is where most people get stuck. The question isn't "what do I put in?" but "what do I take out?" And it hurts, because every feature always seems essential. It almost never is.
In my experience, the method that works best is starting from your riskiest assumption. Sit down with your team and answer: what has to be true for this business to work? If your biggest fear is that people won't pay, your MVP needs a real payment gateway (Stripe, Redsys, whatever fits) from day one. If your biggest fear is adoption, a landing page with a waiting list and LinkedIn Ads campaigns may be enough.
The three-question test
Run every feature you want to include in the MVP through these three questions:
- Is it essential for the user to get the core value? If not, cut it.
- Is the assumption it validates the riskiest one we have? If not, cut it (at least for now).
- Can we launch without it and add it in iteration 2? If so, cut it.
Applied strictly, a typical B2B SaaS MVP in Spain can get by with sign-up, login, the core feature (just one), a payment gateway and a basic admin panel. Forget roles, advanced permissions, multiple languages, dark mode and PDF export. Those are for version 1.5.
How much it costs to launch a startup MVP in Spain
The budget for an MVP depends on the assumption you want to validate, the essential features and the integrations. Ask for a fixed-scope proposal that separates the initial validation from later development.
The price depends mainly on three things: whether you need a native app (iOS + Android costs about 1.8 times as much as a PWA), the complexity of the integrations (connecting to the Spanish Tax Agency for Veri*Factu, Spain's new invoicing compliance system, to banking gateways or to ERPs such as Sage 50 or Odoo adds hours) and the level of UX design you need.
The time factor almost nobody mentions
A well-planned MVP takes about 6 weeks to build. If someone promises you one in 3 weeks, be wary: either they already have the code and are recycling it for you, or you'll get something unusable. If they say 7 months, that's no longer an MVP; it's a product.
For founders on a tight budget: consider starting with custom web applications instead of a native app. It works on mobile, you don't have to go through the app stores and you cut costs and timelines in half. Once you've validated, you can scale.
How to validate a business idea: what to measure before and after launch
Launching an MVP without clear metrics is like weighing yourself without scales and saying "I think I'm doing better." The goal of validating your business idea isn't "let's see if it sells"; it's answering, with data, specific questions you wrote down before writing a single line of code.
The metrics that really matter in an MVP, in order of importance:
- Activation: the percentage of registered users who reach the "aha moment" (the first time they understand the value). Below 25–30%, you have an onboarding or value proposition problem.
- Week 1 and week 4 retention: of the users who activated, how many come back. This is the king of metrics. If W4 retention is below 15–20% in B2B SaaS, something is wrong.
- Willingness to pay: validate an actual purchase on clear terms, not just interest expressed in an interview.
- NPS and qualitative feedback: 10 calls with real users tell you more than 500 surveys.
If your MVP doesn't answer the question "would these people pay for the full version?" with data, then it isn't an MVP; it's an aesthetic experiment.
The funny thing is that many founders obsess over vanity metrics (visits, downloads, followers) and avoid the ones that matter, because those are the ones that hurt when results are bad. My advice: set up your metrics dashboard before you launch. If you leave it for later, you won't do it.
Common mistakes when launching an MVP (and how to avoid them)
Of the mistakes I see again and again in projects from founders who come to us after trying on their own, here are the five most expensive:
1. Adding features "just in case"
The classic. "While we're at it, let's add the invoicing module too, because the customer will ask for it." No, the customer won't ask for it for another three months, by which time you'll know whether they're buying or not. Every extra feature means extra weeks and money burned.
2. Confusing an MVP with a pretty prototype
Spending three months polishing the design in Figma without writing any code. You end up with a beautiful idea and zero market validation. Design matters, but in an MVP it matters more that it works and that someone uses it.
3. Not talking to users before building
Interviewing potential customers beforehand helps you define the MVP. Set aside time to ask about their problems, the tools they use today and how they make purchasing decisions.
4. Forgetting the Spanish legal framework
Legal notice, privacy policy under the GDPR and the Spanish Data Protection Act (LOPDGDD), cookies, terms and conditions if you charge customers. If you're going to invoice in Spain, your MVP also has to comply with Veri*Factu when it becomes mandatory for your case. It isn't optional, and it isn't "for later."
5. Trying to scale before you have traction
If your MVP starts to work (congratulations, you're in the minority), the temptation to rewrite everything as microservices is strong. Resist it. First confirm with numbers that growth is sustained, then think about developing a scalable SaaS. Doing it the other way round is the fastest way to die of success without ever having succeeded.
From MVP to product: when and how to make the leap
Now for the phase almost nobody explains well. Your MVP is up and running, your first 30–100 users are paying and your retention metrics are decent. Now what?
The move from MVP to a real product doesn't happen on a specific day. It's a transition phase that usually lasts 3 to 9 months. My recommendation is to work on three fronts at once, without speeding any of them up until you see clear signals:
- Refactor what breaks: MVP code usually has shortcuts. That's normal. As you scale, you identify the technical bottlenecks and fix them one by one. Don't rewrite everything at once.
- Add the most-requested features, not the flashiest: rank user feedback by frequency and by impact on retention. Both metrics. If it's not on that list, it doesn't get built.
- Get operations ready: support, recurring billing with Stripe or GoCardless (more widely used in Spain than you might think), semi-automated onboarding, documentation. This tends to get neglected, and it shows in your churn.
One signal I really like as a sign you're ready to scale: if you've had 3 months of organic growth (with no spending on acquisition) and monthly retention is above 80%, you have product-market fit. If you're not there yet, you're still in the MVP phase, even if a year has gone by. And that's fine: better to admit it than to force the scaling.
If you remember only one thing, make it this: an MVP isn't a shoddy version of your product. It's the cheapest, fastest way to find out whether what's in your head interests someone who's willing to pay for it. Period. Everything else (the perfect app, the premium design, the 40 features) comes later, once you know you're not building on sand.
My advice after quite a few projects: spend more time defining the assumptions and metrics you'll measure than arguing about whether the button goes at the top or the bottom. Launch something ugly but functional in 6 weeks, put it in front of real users, listen (above all, listen) and iterate again. If you're about to build your first startup, working this way will save you headaches, money and, most valuable of all, months of your life.
And if you'd like to talk through your specific case before rolling up your sleeves, at Interconecta we help founders define their MVP without selling them smoke: sometimes the most useful thing we can tell you is that you don't need to build anything yet.