What Is an MVP and What Not to Build in Your First Version
2 min read
What is an MVP (minimum viable product), why building everything first sinks projects, and which layers to add as you grow, explained through scale tiers.
An MVP (Minimum Viable Product) is the first version you build to test your idea with real users. The goal is not a perfect product but a fast answer: do people want this, do they use it, do they come back? The sooner and more cheaply you get that answer, the less money you spend going in the wrong direction.
The most common mistake
Many projects get bogged down by the urge to build everything in the first version: a complex architecture, every feature, thorough infrastructure. One of two things then happens:
- The budget goes into infrastructure, and there is no money left for the product itself.
- Or the opposite: a system meant for serious traffic is written like a "simple website" and is rewritten from scratch six months later.
In both cases the cause is the same: the real size of the project was never discussed up front.
Three tiers: what to build and when
We divide projects into three scale tiers. What gets built, and what is deliberately left out, differs at each tier.
S1 — Validation
You test the idea in the market in the cheapest way possible. One application, one server, basic analytics, a domain and SSL are enough. Deliberately left out here: a CI/CD pipeline, a separate test environment, load testing, a multi-region setup. At this size they are a cost, not a benefit.
S2 — Growth
The product has caught on: you have your first paying customers, the team is growing, releases are getting more frequent. Now it is time for resilience: automated releases, a staging environment, automated tests, monitoring and backups.
S3 — Scale
High traffic, SLA commitments and teams working in parallel. Queue systems, horizontal scaling, full observability, load testing and security audits belong to this tier.
Staying ready: growing without a rewrite
Moving between tiers should not mean a rewrite. For that, we lay foundations from day one that are invisible but cheap: a modular code structure, separated environment variables, database migrations and a ready Docker configuration. They don't increase the budget, but when the product takes off they turn the move to S2 into a week or two of configuration work.
Questions to ask yourself when planning your MVP
- What is my riskiest assumption, and what is the minimum I need to test it?
- What one problem does the first user come to solve?
- Which features are "nice to have" and which are "the product doesn't work without them"?
- How will I measure the result? (sign-ups, payments, return visits)
- How many people are in the first user group?
If the answers are clear, the first version can usually be built in a few weeks.
Next step
To work out which tier your project should start at, come for a scale conversation. You can find more about our infrastructure approach on our DevOps service page and on the web platforms page.
