You have an idea for a platform. A new tool, an internal app, or a SaaS product that fills a gap in the market. The question every SMB founder then asks: do I build the whole thing right away, or do I start small? In 9 out of 10 cases the answer is small. An MVP is the smartest way to test your idea without first investing hundreds of thousands. This article explains how we approach MVP projects for SMB companies, which phases you go through, what it costs, and which mistakes you are better off skipping.
What is an MVP exactly?
An MVP is the smallest possible version of your product that real users can use and give useful feedback on. The term comes from Eric Ries’s book The Lean Startup and stands for minimum viable product.
For SMBs an MVP is a way to limit risk. Instead of building for six months and then finding out nobody uses it, you build a working version in three weeks and see if people do anything with it. The win is not in the time, it is in the information.
When do you pick an MVP approach?
- Early validation. You have an idea but no proof that customers want to pay for it.
- Limited budget. You have €10,000 to €20,000 to spend, not €60,000.
- Uncertainty about product-market fit. You do not know exactly which feature makes the difference.
- Quick test alongside existing activities. You already run a business and want to test something new without it distracting from your core.
- Limited time to first delivery. You have a deadline of 2 to 3 weeks.
Torn between MVP and full build? Read our guide on having custom software built.
What does having an MVP built cost?
| Level | Investment | Timeline | What you get |
|---|---|---|---|
| Lite MVP | €8,000 to €10,000 | 1 to 2 weeks | 1 core feature, 1 user role, basic auth, rough UI. |
| Standard MVP | €11,000 to €14,000 | 2 weeks | 2 to 3 core features, 2 user roles, payment or API integration, neat UI. |
| Extended MVP | €15,000 to €18,000 | 2 to 3 weeks | 3 to 5 core features, multiple roles, more complex logic, integrations. |
Which phases do you go through in an MVP project?
| Phase | Duration | What happens | What you get |
|---|---|---|---|
| 1. Discovery | 2 workdays | Interviews with you and 2-3 future users, scope document | Scope document, feature list, fixed price. |
| 2. Design | 2 workdays | User flows, wireframes, basic UI design in Figma | Figma files, clickable prototype. |
| 3. Build | 6 to 9 workdays | Database, backend, frontend, integrations, testing | Working staging, weekly demo, production version. |
| 4. Launch | 1 workday | Production hosting, monitoring, onboarding first users | Live MVP, monitoring, code-ownership handover. |
At the end of Launch you receive the full code as your property. What code ownership really means is explained in code ownership and vendor lock-in.
Which features DO belong in an MVP?
- The one core action the entire platform revolves around. One action, working well.
- Basic auth and user management. Email and password login, optionally Google or Microsoft.
- The minimum data structure. A database that can store and retrieve your core objects.
- A rough UI that works. Not pretty, but clear.
- A feedback mechanism. Email address or in-app button so users can respond.
Examples of platforms we delivered as MVPs sit on our custom platforms page and in the Mastone and Simply cases.
Which features do NOT belong in an MVP?
- Extensive admin panel. In an MVP a simple database view or spreadsheet export is enough.
- Multi-user collaboration and role permissions. Comes later.
- Full analytics dashboard. Use PostHog, Plausible or Google Analytics.
- Own notification engine. Start with simple email via Postmark or Resend.
- White-label or theming. Comes after product-market fit.
- Full integration suite. Start with the one integration that is strictly necessary.
- App instead of or alongside web. Double build cost without double learning.
How do you measure whether your MVP succeeds?
- Adoption: how many people sign up and use the core action?
- Retention: how many people come back? For most MVPs, 30 percent retention after 7 days is already a good sign.
- Feedback: what do users say spontaneously? Do they complain about speed, design, missing features?
What do you do after the MVP?
After 8 to 12 weeks in production you have enough data to make a decision. Steve Blank, one of the founders of Customer Development, calls this the “pivot or persevere” moment.
- Path 1: iterate. You adjust the core function and run another measurement cycle.
- Path 2: expand. Adoption is strong, you build admin panel, extra roles, integrations.
- Path 3: stop. The market does not respond. You lost €10,000 instead of €80,000. Y Combinator calls this one of the most valuable lessons.
In our experience 60 percent picks path 2, 30 percent path 1, and 10 percent path 3. Better a well-founded no in week 12 than an expensive yes in month 12.
Concrete example: MVP for a fictional SMB
A Dutch interior installer wants a platform where subcontractors share their availability and planning. We propose: a Standard MVP of €12,000, 2 weeks lead time. After 6 weeks: 8 companies signed up, 6 add planning weekly, retention at 65 percent. Decision: path 2, expand. Phase 2 budget: €18,000. Total after 6 months: €30,000 for a validated platform, instead of €80,000 for a Full Build.
What deliverables do you get per phase?
Many MVP projects get stuck because it is unclear what you actually receive at each phase. We tie every phase to a fixed set of documents and assets. That way you know in week 1 what you will have in hand by week 3, and you can sign off each phase before the next one starts.
| Phase | Deliverables | Where it lives |
|---|---|---|
| Discovery | scope.md, prioritised feature list, fixed-price quote, risk list | Shared Notion or Google Drive, your property. |
| Design | Figma with wireframes, clickable prototype, flow.md with user flows and edge cases | Figma file on your account, flow doc in repo. |
| Build | GitHub repo, staging environment, weekly 5-minute demo video, release notes | GitHub under your organisation, video in Drive. |
| Launch | production environment, handover.md, monitoring dashboard, admin video walkthrough | Repo, hosting account and docs in your control. |
How do you prioritise features for an MVP?
Founders almost always want more features than fit in an MVP. We use two simple frameworks side by side during discovery: MoSCoW for the rough sort, and ICE for the finer call within “Must” and “Should”.
- MoSCoW. Every feature idea gets a label: Must, Should, Could or Won’t. A Lite MVP only contains Must items. A Standard MVP adds a few Should items.
- ICE score (Impact, Confidence, Ease). Per feature you score three numbers from 1 to 10, multiply them, and sort high to low. The top 3 to 5 features ship.
- Three-question test per feature. Does this solve a real customer problem, can we build it in 5 days, and can we measure it after launch? Three yeses: in scope. Doubt: on the phase-2 list.
- Make the trade-off visible. Every “yes” to a new feature is a “no” to something else. In our scope table we always show which feature gives way for a new wish.
For a deeper look at scope choices see the Mastone case study, where we narrowed the first version from 11 down to 4 core functions.
Which scope mistakes do we see most often?
Across 4 years of MVP projects with SMB companies the same traps keep returning. Most are preventable by asking sharper questions in discovery. Below are the five patterns we encounter most, with the simple counter-move.
- Mistake 1: building for “everyone”. The founder names three different audiences in one sentence. Counter-move: pick one user, one problem, one core action for the MVP.
- Mistake 2: bundling an admin panel. “We need a management screen too.” Counter-move: in the MVP, direct database access via a tool like Retool or a simple export is enough.
- Mistake 3: integration roadmap of 6 connectors. Counter-move: pick the one connector without which the product does not work. The rest goes to phase 2.
- Mistake 4: design perfectionism. Three design rounds before any code exists. Counter-move: design to 80 percent and test with real users, not with colleagues.
- Mistake 5: roles and permissions from day 1. “Our clients need 4 different roles.” Counter-move: start with 1 or 2 roles and add more only when users explicitly ask.
How do you keep learning after launch?
An MVP does not end at launch. The value sits in what you learn during the first 12 weeks in production. We work with 2-week iteration cycles in which we measure, decide and adjust. Without those rhythms most MVPs go quiet within 3 months.
- Week 1 to 2 after launch: stabilisation. Fix bugs, tune performance, support first users via WhatsApp or email.
- Week 3 to 6: measurement cycle 1. Track adoption and retention via PostHog or Plausible, interview 5 users about their experience.
- Week 7 to 10: measurement cycle 2. Ship first small improvements (copy, forms, email flows), run a second measurement round.
- Week 11 to 12: decision moment. Pivot, persevere or stop. Backed by data and interviews, not by gut feeling.
Our packages include an ongoing plan from €750 per month for small iterations after the MVP. No annual contract, monthly cancellation.
How do you start concretely?
- Step 1: describe in 5 sentences what your MVP should do. Who is the user, what is the one core action, how do you make money, what is your deadline.
- Step 2: plan a free intake. In 30 minutes we look at your description and give an honest estimate.
- Step 3: start discovery. At the end there is a fixed contract with scope, price and planning.
Plan a free intake call. Our way of working and correction guarantee sit in our terms and conditions. For inspiration: cases Mastone, Simply and Planit Consulting.
