What an MVP is, and what it is not
An MVP is not a rough draft of the full product, and it is not a demo. It is a complete, working solution to one problem for one kind of user. It should be small, but what it does it should do properly.
Its purpose is to answer a question: will people use this, and will they pay for it or come back? Everything that does not help answer that question waits for a later version.
Start by choosing the one problem
Most first versions run late because they try to serve everyone. Before any design or code, write down:
- The user: one specific type of person, not "businesses".
- The problem: what they struggle with today, in their words.
- The core action: the single thing they will do in your product to solve it.
- The proof: what you will measure to know it is working.
Then sort every feature idea into three lists: needed for the core action, useful later, and not now. Be strict. The first list is the MVP.
The 12 weeks, in outline
| Weeks | Stage | What you have at the end |
|---|---|---|
| 1 to 2 | Discovery and scope | Agreed feature list, user flows, technical plan, a clear definition of "done" |
| 3 to 4 | Design and prototype | A clickable prototype tested with a few real users |
| 5 to 10 | Build, in two-week cycles | Working software you can use, growing every two weeks |
| 11 | Testing and fixes | A stable version, tested on real devices |
| 12 | Launch | Live product, analytics running, first users invited |
Weeks 1 to 2: discovery and scope
The team learns your business, challenges your assumptions and turns the idea into a short list of features with a plan to build them. This is the cheapest point at which to change your mind, so take the questions seriously.
Weeks 3 to 4: design and prototype
Screens are designed and linked into a prototype you can click through. Put it in front of five people from your target group. Watching them struggle with a prototype saves weeks of building the wrong thing.
Weeks 5 to 10: build
Development runs in short cycles. At the end of each one you see working software, not a status report, and you decide what comes next. The most important feature is built first, so that if anything has to be dropped it is the least important.
Week 11: testing and fixes
Testing happens throughout, but this week is reserved for it: real devices, slow connections, wrong inputs, and the paths users take that nobody planned for.
Week 12: launch
The product goes live to a first group of users. For a mobile app, allow for app store review, which is outside anyone's control. Analytics should be working from the first day.
What to cut
- Extra user types. Serve one kind of user well. Admin tasks can often be done by hand behind the scenes at first.
- Settings and customization. Pick sensible defaults.
- Second platforms. Launch on web, or on one mobile platform, before both.
- Automation of rare events. If something happens twice a month, a person can handle it for now.
- Polish on secondary screens. Spend the design effort on the core action.
What never to cut
- Security basics. Proper login, encrypted connections, protected user data. A breach in an early product can end it.
- Backups. From the first day there is real data.
- Analytics. The MVP exists to teach you something. Without measurement it cannot.
- Reasonable code quality. "Quick" should not mean "has to be rewritten". A sound foundation is what lets version two build on version one.
- The core experience. The one thing the product does must work smoothly.
Why first versions run late
- Scope grows during the build. Every "small addition" pushes the date. Write new ideas down for the next version.
- Slow decisions. If feedback takes a week, a twelve-week plan becomes twenty.
- Unclear ownership. One person on your side must be able to say yes or no.
- Outside dependencies. Payment providers, app stores and third-party APIs have their own timelines. Start those early.
- Testing left to the end. Problems found in week eleven cost far more than problems found in week six.
An honest note on the number: twelve weeks suits a focused product with a narrow scope and a client who decides quickly. Products that need complex integrations, regulatory approval or hardware take longer. A good team will tell you which kind you have during discovery.
Three ways to make an MVP smaller
If your feature list does not fit the time you have, cutting quality is the wrong lever. These three work better.
Do it by hand behind the scenes
Users need the result, not the automation. If matching a customer to a provider takes complex logic, have a person do the matching for the first hundred users. You learn what the rules should be before you pay to build them.
Serve one group, one place, one case
A product for "restaurants" is large. A product for independent cafes in one city, handling only pre-orders, is small, and it is still a real test of the idea.
Use existing services for everything that is not your idea
Payments, login, email, maps and notifications are all available as services. Building your own version of any of them adds weeks and teaches you nothing about whether people want your product.
Common questions
Should we build for web or mobile first?
Go where your users already are when they have the problem. If they are at a desk, start with web. If they are on the move, start with the mobile platform most of them use. A web app that works well on phones is often the fastest way to reach both.
Will we have to rebuild it later?
Parts of it, probably, and that is normal: you will learn things that change the product. What you should not have to do is throw everything away. A sound foundation and readable code let version two grow out of version one.
What do we need to prepare before week one?
The four points from the scoping section, any existing designs or data, and a person on your side with the time and authority to answer questions within a day.
After launch
Launch is the start of the useful part. In the first weeks:
- Watch what users actually do, and where they stop.
- Talk to the first users directly. Ten conversations will tell you more than a dashboard.
- Fix what blocks the core action before adding anything new.
- Plan the next version from evidence, not from the original wish list.
Next step
If you are not sure whether your idea needs a custom build at all, read custom software vs off-the-shelf. If you are considering an overseas team to build it, see why companies outsource software development to Pakistan.
Qorica takes products from first prototype to launch, in stages, with progress shown every week. See our software development and mobile app development services, or tell us about the one problem you want to solve.
