From idea to MVP in 8 weeks — a realistic guide for founders
You have a great idea, but how do you go from concept to working product without exhausting your budget? Here's a step-by-step guide based on our experience building MVPs for Norwegian businesses.
An MVP (Minimum Viable Product) is the smallest version of a product that provides enough value for real users to adopt it. With the right process, you can go from idea to working MVP in 8 weeks without exhausting your budget.
"We just need a simple app." That's the sentence we hear most often in first meetings with founders and product owners. And it's almost always wrong — not because the idea is bad, but because "simple" is relative, and the most critical decisions are made before the first line of code is written.
This article is a practical guide for those with a business idea who want to build a minimum viable product (MVP) — the smallest version of the product that provides enough value for real users to adopt it.
What is an MVP — and what is it not?
The term MVP was popularized by Eric Ries in The Lean Startup (2011). The core is simple: build the minimum needed to test your hypothesis with real users.
An MVP is not:
- A prototype or mockup (that's a precursor)
- An incomplete version of the final product
- A tool for saving money by cutting corners
An MVP is:
- A working product that solves one core challenge well
- A tool for learning — what works, what doesn't?
- The foundation for data-driven decisions about further development
When we built the first version of Splice, the MVP was limited to booking and student registration. Payments, instructor calendars, and reporting came later — based on what pilot schools actually requested after using the first version.
Phase 1: Define the problem (week 1)
Before you think about technology, answer these questions:
The four fundamental questions
Who is the user? — Not "everyone" or "Norwegian businesses." Be specific. "Office staff at driving schools with 5–20 instructors" is a good answer.
What is the concrete problem? — Describe the problem as a narrative: "Today, office staff spend 3 hours per week moving data between the booking system and spreadsheets because the systems don't talk to each other."
How do they solve the problem today? — Understand the current solution (manual, competitor, Excel). This gives you a baseline to measure improvement against.
What is the smallest solution that provides value? — Not "everything," but the one thing that removes the most friction.
The prioritization method: MoSCoW
We use the MoSCoW method to sort features:
| Category | Definition | Example (Splice) |
|---|---|---|
| Must have | Without this, the product doesn't work | Booking driving lessons |
| Should have | Important, but can wait until v2 | Automatic payments |
| Could have | Nice to have, low priority | Statistics dashboard |
| Won't have | Deliberately excluded from MVP | Mobile app |
The outcome of this phase is a short document (max 2 pages) describing the problem, user, MVP scope, and success criteria.
Phase 2: Design and prototype (weeks 2–3)
Now it's time to visualize the solution — but not in code yet.
Wireframes first, design later
We always start with wireframes — simple sketches of pages and flows. Tools like Figma or even paper work well. The point is to validate user flow and information architecture before investing in visual design.
Test with users early
Show wireframes to 3–5 potential users. Ask open questions: "What do you think this button does?" and "What do you miss?" This kind of early user insight is invaluable — and free compared to changing code.
Read more about how we approach UX and design in our projects.
Phase 3: Technology choices (week 3)
Choose technology for maintainability, not hype
For MVPs, we recommend technology that enables rapid development without compromising quality:
| Choice | Recommendation | Rationale |
|---|---|---|
| Language | TypeScript | Type safety from day one, avoid an entire class of bugs |
| Frontend | Next.js (React) | SSR/SSG, built-in routing, large community |
| Backend | Next.js API routes or Node.js | Same language for frontend and backend |
| Database | PostgreSQL | Robust, battle-tested, free |
| Hosting | Azure App Service | PaaS, simple scaling, data center in Norway |
| Authentication | NextAuth / Entra ID | Established, secure, avoids building from scratch |
We've written in more detail about our technology choices in the article Our technology choices in 2026.
Don't build what you can buy
For an MVP, avoid building:
- Authentication — use NextAuth, Auth0, or Entra ID
- Payment processing — use Vipps, Dintero, or Stripe
- Email — use Postmark, Resend, or SendGrid
- File storage — use Azure Blob Storage or S3
Focus development time on what's unique to your business.
Phase 4: Build (weeks 4–7)
Four weeks of development sounds short — and it is short. But with solid groundwork (phases 1–3) and disciplined prioritization, it's sufficient for a focused MVP.
Weekly rhythm
| Week | Focus |
|---|---|
| 4 | Foundation, authentication, database schema |
| 5 | Core flow (the one thing the MVP does) |
| 6 | Secondary flows, error handling, edge cases |
| 7 | Testing, polish, deployment to staging |
Principles for MVP development
Deliver working software weekly. Every Friday there should be a deployable version. Don't accumulate two weeks of unfinished code.
Distinguish between "good enough" and "technical debt." An MVP can have simple design, but should have clean code architecture. Shortcuts in architecture cost more than shortcuts in visual design.
Write tests for core flows. You don't need 100% test coverage, but the critical paths — registration, booking, payment — should have automated tests.
Phase 5: Launch and learn (week 8)
Soft launch first
Don't launch to everyone on day one. Start with 5–10 users you can talk to directly. Give them personal follow-up and ask for honest feedback.
Measure what matters
| Metric | What it tells you |
|---|---|
| Daily active users (DAU) | Does the product have "sticking power"? |
| Task completion rate | Do the user flows work? |
| Time to value | How quickly do new users get value? |
| NPS / qualitative feedback | What do users actually think? |
Iterate based on data
After 2–4 weeks with real users, you have enough data to make informed decisions about what to build next. Often, what users ask for is something entirely different from what you had planned for v2.
What does an MVP cost?
This is the question everyone asks, and the answer depends on complexity. Here are realistic ranges for Norwegian development projects:
| Complexity | Description | Estimate |
|---|---|---|
| Simple | CRUD app, 3–5 pages, authentication | NOK 200,000 – 400,000 |
| Moderate | Integrations, payments, role management | NOK 400,000 – 800,000 |
| Complex | Real-time, advanced logic, multiple user types | NOK 800,000 – 1,500,000 |
Prices are indicative and based on Norwegian market rates for experienced developers in 2026.
In the article Why custom software beats off-the-shelf, we go deeper into total cost of ownership and long-term value.
The five most common mistakes
Building too much. The most common mistake. Cut 50% of what you think you need — it's still probably too much.
Skipping user research. Building what you think users want, instead of asking them, is the most expensive mistake you can make.
Choosing the wrong partner. A development partner who doesn't understand MVP philosophy will build a miniature version of an enterprise system. Read our guide on how to choose the right development partner.
Ignoring technical foundation. An MVP can be simple, but it should have a solid technical foundation. Poor architecture in the MVP becomes expensive technical debt in v2.
Not defining success criteria. If you don't know what success looks like, you won't know whether the MVP succeeded.
Ready to build?
We help founders and product owners go from idea to working MVP — focused on what actually matters to your users. Read more about our approach to software development, or get in touch for a free consultation about your project.
Sources and further reading
- Ries, E. (2011). The Lean Startup. Crown Business.
- Cagan, M. (2017). Inspired: How to Create Tech Products Customers Love. Wiley.
- Innovation Norway (2025). "Funding schemes for technology development." innovasjonnorge.no
- Gothelf, J. & Seiden, J. (2021). Lean UX: Applying Lean Principles to Improve User Experience. O'Reilly.
- CB Insights (2024). "The Top 12 Reasons Startups Fail." cbinsights.com