How to Launch a Viable MVP: Nail One Thing Before Trying to Do Ten

The term MVP has been overused. Today, people call anything from a half-finished prototype to a landing page with a "waitlist" button—or worse, a complete but ugly product—an MVP. Let’s set the record straight.

What an MVP Actually Is

Minimum Viable Product. All three words matter. Minimum: as small as it gets. Viable: it must actually work for someone. Product: not a mockup, not an idea, but a real product.

The question isn’t, “Which features should I include?” It’s, “What’s the one thing my product must do for a user to pay (or use, if you’re not monetizing yet)?” Everything else goes in Version 2.

The Case of Mi Seguro de Auto

When we built Mi Seguro de Auto, the temptation was to solve the entire insurance market: cars, motorcycles, home, life, workers’ comp. Instead, we did the opposite. We started with one vertical (motorcycles) and one core flow (a 5-step online quote without a phone call).

That single decision shaped everything else. There’s no life insurance calculator in the menu. No option to quote your brother-in-law’s car. Just a button that says “Quote a motorcycle”, leading users through five screens to land on a number. Period.

The result? People get it in three seconds. The insurance company can track conversion. And the dev team iterates on something concrete—not a theoretical platform.

The 3 Common Mistakes That Kill an MVP

Mistake 1: Confusing MVP with a “cheap version.” An MVP isn’t your full product with fewer features. It’s a completely different, smaller, hyper-focused product—better polished in what it does do. If your MVP embarrasses you, it’s not because it’s missing features. It’s because the ones it has are poorly executed.

Mistake 2: The Trello Board Syndrome. The team compiles a list of 80 features, prioritizes them, and ends up with a 40-feature MVP. Still too much. The right question isn’t, “What can we cut?” It’s, “If I had to ship something tomorrow, what single feature would I keep?” Start there.

Mistake 3: Launching in stealth mode. An MVP that isn’t measured is just a demo. Before writing a line of code, define: What metric tells me this works or fails? If it’s a quoting platform, the metric is completed quotes, not visits. If it’s a CRM, it’s leads that progress through stages, not registered users.

The Go/No-Go Checklist

Before you start building, write this down on one page:

1. One sentence: What problem does it solve, and for whom?
2. One metric: How will you measure success? (Must be a concrete number, not “engagement.”)
3. One flow: A step-by-step user journey—no optional branches.
4. One deadline: When it goes live for real users (not your mom).
5. One exit plan: What happens if the metric doesn’t hit in 60 days?

If you can’t answer all five, you don’t have an MVP yet. You have an idea. And ideas are the easy part—the execution is where it gets real.

How Long Should a Real MVP Take?

It depends on the domain. For reference:

• A standalone quoting tool like Mi Seguro de Auto, built from scratch: 4–8 weeks (when scope is tight).
• A CRM like La Carolina with pipeline stages and proposals: 8–12 weeks.
• A platform with AI like Tontin, where retention and cross-session memory are critical: 12–20 weeks.

If someone promises a “complete MVP” in two weeks, what you’ll get is a ThemeForest template with your logo slapped on top. That’s not an MVP—it’s a placeholder.

Bottom Line

An MVP is a bet. You’re betting on one specific hypothesis (these people will pay for this) and testing it with the smallest possible product that can validate it. The sooner it reaches real users, the sooner you know if the bet was right. And if it wasn’t? You lost eight weeks—not eight months.

If you have an idea but aren’t sure where to start with scope, let’s talk in 30 minutes. We’ll help you define the real minimum viable scope for your product.

---

By Esteban Aleart, Founder & Lead Engineer at Pair Programming.