You have an idea for a software product. Maybe an internal tool, a client portal or a full SaaS platform. You know what it should do — eventually. The question is: what do you build first?
This is where most projects go wrong. Not because the idea is bad, but because the first version tries to do too much. The result: months of building, a bloated budget and a product that still doesn't feel finished.
The alternative is an MVP — a Minimum Viable Product. But "minimum" is harder to define than it sounds.
What is an MVP, really?
An MVP is the smallest version of your product that solves the core problem well enough to get real feedback from real users. It's not a prototype, not a demo and not a half-broken version of the full product.
A good MVP has three properties:
- It works — Users can complete the core workflow without hitting dead ends
- It solves one problem well — Not five problems poorly
- It generates feedback — You learn something you didn't know before launching
What an MVP is not: a throwaway experiment. The code should be solid enough to build on. Cutting corners on architecture to save two weeks costs you two months later.
The cost difference is bigger than you think
Here's where the numbers matter. For a mid-sized business application:
- MVP (core workflow, 6–10 weeks): €15,000 – €35,000
- Full product (all features, 4–8 months): €50,000 – €120,000
That's a 3–4x difference. And here's the part nobody talks about: roughly 60% of features built into a full product are rarely or never used. You're paying €30,000–€70,000 for functionality that collects dust.
An MVP lets you spend €20,000 to find out which features actually matter — then invest the remaining budget where it counts.
How to decide what goes into v1
This is the hardest conversation in any project. Everyone has opinions about what's essential. Here's the framework I use with clients:
Step 1: Define the core job
Complete this sentence: "A user comes to this product to _____." If you can't finish it in one sentence, the scope is too broad. Split it up.
Step 2: Map the critical path
What are the absolute minimum steps a user takes to complete that job? Every screen, every click, every decision point. This is your MVP scope.
Step 3: Apply the "would they leave?" test
For every feature someone wants to add, ask: "If this feature is missing, will users abandon the product?" If the answer is no, it's not v1.
Step 4: Separate infrastructure from features
Authentication, error handling, security and performance aren't features — they're requirements. These don't get cut. What gets cut is the admin dashboard with 12 filter options when 3 will do.
Common mistakes when scoping an MVP
1. Building for every edge case
Your system handles 95% of orders automatically? Ship it. Handle the other 5% manually until you know which edge cases actually occur often enough to justify the engineering time.
2. Designing for 10,000 users when you have 10
Scaling problems are good problems. Don't spend weeks building infrastructure for traffic you don't have. A well-architected MVP can handle your first 500 users without breaking a sweat.
3. Adding "nice-to-have" features because they seem easy
"It's just a small feature" is the most expensive sentence in software development. Every feature adds testing, maintenance, documentation and cognitive load. Ten small features add up to two extra months.
4. Skipping the discovery phase
You save €3,000 by not doing a proper discovery — and spend €15,000 building the wrong thing. A two-week discovery phase with user interviews and workflow mapping is the highest-ROI investment in any project.
When to go beyond MVP
An MVP isn't the end. It's the starting point for informed decisions. Expand when:
- Users are actively using it — Real usage data beats assumptions every time
- You have specific feedback — "I need feature X to do my job" is actionable. "It would be nice if..." is not v2 material
- The business case is proven — The MVP generates revenue, saves measurable time or reduces errors you can quantify
- You've identified the 20% of features that deliver 80% of value — Now you know where to invest
The best products aren't built in one big release. They're built in cycles: ship, measure, learn, build. Each cycle makes the product better because you're making decisions based on evidence, not guesses.
A real example
For ProAspect — an invoicing automation tool for an accounting firm — the MVP was intentionally narrow: upload a CSV of timesheets, automatically generate invoices with the correct rates, export as PDF. No client portal, no email integration, no dashboard.
That MVP replaced 4+ hours of manual work per week on day one. The client portal and email integration came in v2, after we confirmed the core process worked flawlessly. Total v1 cost was under €10,000. If we'd built everything at once, the budget would have tripled — and half of the original feature ideas turned out to be unnecessary after seeing real usage patterns.
Ready to define your v1?
Send me a description of what you want to build, and I'll help you separate the must-haves from the nice-to-haves. No cost, no commitment — just a clear picture of what your MVP should look like and what it will realistically cost.