A minimum viable product is the smallest version of your idea that real users can rely on, built to test the assumption your business depends on most. Twelve weeks is enough time to build one properly, if you are strict about what goes in. This plan shows how we structure those weeks, and which features should wait for version two.
Pick the one job it must do
Every successful first version does one job well. A booking app lets a customer book and pay. A logistics tool lets a dispatcher assign a job and see it completed. A B2B platform lets a client submit a request and track it.
Write that job as a single sentence, starting with the user: "A clinic receptionist can book, move and cancel appointments in under a minute." Everything in the first release either serves that sentence or waits.
Then name your riskiest assumption. Perhaps customers will not pay upfront, or dispatchers will not trust automatic assignment. Your MVP should put that assumption in front of real users as early as possible, because that is the lesson you cannot learn any other way.
What waits for version two
These features feel essential during planning and almost never are in the first release.
- A polished admin panel. Early on, your team can manage edge cases through a simple internal screen or directly in the database, with safeguards.
- Several user roles. Start with the two roles the core job needs. Managers, auditors and partners can wait.
- Multiple languages and currencies. Launch in the market you will test first, but build with translation in mind so adding a language later is straightforward.
- Custom analytics dashboards. Product analytics tools give you most of the insight on day one.
- Both native mobile apps and a web app. Choose the platform your first users need. If you need both mobile platforms, a cross-platform framework keeps it to one codebase.
- Complex permissions and automation rules. Hard-code sensible defaults and learn which settings people ask for.
Cutting these keeps quality where it counts: the first twelve weeks go into the part that proves the business, built well.
The twelve-week plan
| Weeks | Focus | What you get |
|---|---|---|
| 1–2 | Discovery and design | User journeys, clickable prototype, architecture, a fixed scope |
| 3–4 | Foundations | Accounts and sign-in, data model, environments, automated deployments |
| 5–9 | Core features in two-week sprints | A working demo at the end of each sprint |
| 10–11 | Hardening | Testing, security review, performance work, analytics events |
| 12 | Launch | Release to a first group of users, monitoring switched on |
Weeks 1 and 2 decide whether the rest goes smoothly. We map the core journey with the people who will use it, test a clickable prototype with a handful of them, and settle the architecture. The output is a scope you can sign off and a fixed price you can budget for.
Weeks 3 and 4 build the parts nobody sees: sign-in, the data model, separate environments for testing and production, and a pipeline that deploys every change automatically. Skipping this work saves a week now and costs a month later.
Weeks 5 to 9 deliver the core job in two-week sprints. At the end of each sprint you use the working software, not a slide about it. Your feedback shapes the next sprint, which is how the product stays close to what users need.
Weeks 10 and 11 turn a working product into a dependable one. We test on real devices, check the security of every input and permission, tune performance, and make sure the analytics answer the questions you set in week one.
Week 12 is a controlled launch. Release to a small group first, watch what they do, fix what you find, then widen the circle.
Fake it where you can
Some features can run manually behind the scenes while you learn whether anyone wants them. A recommendation engine can start as a person picking three options each morning. Automatic invoicing can start as a weekly export your finance team reviews.
This approach, sometimes called a concierge MVP, lets you test demand before you invest in automation. Once the manual version becomes a bottleneck, you know the feature is worth building properly.
Measure what matters
Decide before launch which numbers will tell you whether the MVP works. Keep the list short:
- Activation: the share of new users who complete the core job for the first time.
- Retention: the share who come back and do it again the following week.
- Your riskiest assumption: a direct measure of the thing you most needed to learn, such as the share of customers who pay upfront.
Vanity numbers such as downloads and page views feel good and teach you little. A small group of users who return every week is worth more than a large group who never come back.
Traps that stretch twelve weeks into twenty
- Gold-plating. Polishing screens nobody has tested yet. Make the core journey clear and fast, and leave the flourishes for later.
- Launching to everyone at once. A small first cohort gives you room to fix problems before they reach your whole audience.
- Launching without measurement. If analytics go in after launch, you lose the most informative weeks of data.
- Too many decision-makers. Name one person who can approve scope and answer questions within a day.
After week twelve
Launch is the start of the learning, not the end of the project. The weeks after release are when you find out which assumptions held. Plan for them: keep the team available for at least a few sprints of improvements, and put a support plan in place so monitoring, fixes and updates continue. Our guide to what happens after launch covers what that should include.
The usual mistake at this stage is to rush on to the next big feature before the first one works. Fix the friction your first users report, then expand.
If you have an idea you want in front of users this quarter, tell us about it. We build first versions of mobile apps and web platforms on exactly this plan, with a fixed price agreed after discovery.
Written by the engineering team at Aventra Global LLC, Dubai.