# How long does it take to build an MVP? A week-by-week plan

> A focused MVP usually takes roughly two to three months from discovery to launch. Here is the week-by-week plan, what delays it and how to keep it moving.

Source: https://hidook.tech/insights/how-long-does-it-take-to-build-an-mvp/ · Published by Hidook (https://hidook.tech) · 2026-10-20

A focused MVP (minimum viable product) usually takes somewhere between eight and fourteen weeks from the first workshop to a public launch, if one clear question is being tested and the team is small and senior. Simpler prototypes can be faster. Products with several user roles, integrations, a mobile app or compliance work take longer. The calendar is rarely set by typing speed; it is set by how many decisions are still open when building starts.

## Key takeaways

- A single-purpose MVP with one main user type commonly takes about two to three months end to end, while multi-role products with integrations or mobile apps take longer.
- The schedule is driven by open decisions, integrations and approvals far more than by raw coding capacity.
- A sensible plan has four phases: discovery, blueprint, build and launch, with a working demo every week from the first build week.
- Many tasks can run in parallel, such as design and infrastructure setup, but adding more people to a late project rarely makes it earlier.
- Mobile apps add store review and device testing, so plan for review time and a possible rejection before the launch date is announced.
- When time runs short, cut scope rather than testing, monitoring or the launch checklist, because a date that keeps moving costs more than any single feature.
- Launching the MVP is the start of learning, so plan the weeks after launch for fixes, measurement and the next decision.

## What is the short answer?

For a typical web-based MVP built by a small senior team, plan on roughly two to three months. That includes a short discovery, a design and architecture phase, a handful of build weeks and a launch period.

The range is wide because "MVP" covers very different things. A booking page with payments and one admin view is a different project from a two-sided marketplace with identity checks and a mobile app. The cost follows the same logic; if you are budgeting at the same time, read [how much an MVP costs](/insights/how-much-does-an-mvp-cost/) and [how much custom software development costs](/insights/custom-software-development-cost/).

The table below gives rough orientation. These are planning ranges, not promises, and your scope decides where you land.

| MVP type | Typical shape | Rough calendar |
|---|---|---|
| Prototype or experiment | One flow, one user type, minimal admin | A few weeks |
| Focused web MVP | One main role, a few core flows, one or two simple integrations | About eight to twelve weeks |
| Fuller first product | Several roles, several integrations, proper admin, stronger security | About three to five months |
| Web plus mobile apps | The above, plus iOS and Android releases | Add weeks for store review and device testing |

## What does a week-by-week plan look like?

Here is a plan for a focused web MVP, written as a model you can adapt. It assumes a team of two or three senior people, one clear question to answer, and decisions made at the pace the plan needs.

| Week | Phase | What happens | What you have at the end |
|---|---|---|---|
| 0 | Discovery | Workshops, constraints, the one metric that matters, user interviews, risk list | A written scope, a price and a list of risks |
| 1 | Blueprint | Architecture, data model, clickable prototype, key decisions written down | A tested prototype and recorded decisions |
| 2 | Build 1 | Repository, deployment pipeline, authentication, first core flow | A live URL with the first slice working |
| 3 | Build 2 | Core flow completed, second flow started | A demo of the main path end to end |
| 4 | Build 3 | Second flow, payments or key integration, first admin screens | A demo with money or data moving through |
| 5 | Build 4 | Remaining flows, notifications, edge cases | A feature-complete candidate on staging |
| 6 | Build 5 | Polishing, accessibility, error states, performance, test coverage on critical paths | A release candidate |
| 7 | Launch prep | Load tests, security review, monitoring, runbook, data seeding | A launch checklist with items ticked |
| 8 | Launch | Go live to the first users, with the team on call | A live product and a measurement plan |

Some products fit this in eight weeks. Others stretch each phase. The shape stays the same.

### Week 0: discovery

Discovery turns an idea into a decision. You define the question the MVP must answer, the single metric that proves it, the users, the constraints and the main risks. The output is a written scope, not a slide deck. If you are going to invite proposals before this phase, a clear [project brief](/insights/how-to-write-a-software-project-brief/) shortens it.

### Week 1: blueprint

The team decides how the product is built before it is built. That means the architecture, the data model, the main flows as a clickable prototype and an agreed list of what is out of scope. Testing the prototype with a few real users here is the cheapest quality check in the whole project. Decisions are recorded briefly so that nobody has to guess later why something was done a certain way.

### Weeks 2 to 6: build

Each build week should end with something you can click on a real URL. The first build week usually looks unimpressive because it is about foundations: a repository you own, a deployment pipeline, authentication, a database and error tracking. These pay back every week afterwards.

A healthy weekly rhythm is simple. Plan the week and decide what is cut. Review architecture and code midweek. Demo and deploy midweek, so there are working days left to watch the release. If a week passes without a demo, ask why.

### Weeks 7 to 8: launch

Launch is not a switch you flip. It includes load testing, a security review, monitoring and alerts, a runbook for launch day and someone available if something breaks. A checklist for this is further down.

## What makes an MVP take longer?

Almost every delay comes from the same short list, and most are visible before the project starts.

- **Scope growth.** Each "small addition" adds design, build, tests and edge cases. Ten small additions are not small.
- **Several user roles.** A customer and a supplier, or a patient and a clinic, roughly doubles flows, permissions and notifications.
- **Integrations.** Payments, ERP, CRM, identity verification and partner APIs depend on systems you do not control. Waiting for credentials, sandboxes or documentation is a common source of lost weeks.
- **Slow decisions.** If answers to questions take a week, the build slows to that week. Name one person who can decide.
- **Content and data.** Real copy, images, product catalogues and legacy data often arrive late and in poor shape.
- **Approvals.** Legal, security, procurement and brand reviews in larger organisations add calendar time without adding effort.
- **Compliance.** Health, financial and children's data bring controls and reviews that cannot be bolted on at the end.
- **Mobile platforms.** App store review, device matrix testing and platform-specific behaviour add time.
- **Changing the question.** If the thing you are validating changes mid-build, you restart part of the design.

Notice that none of these says "the developers were slow". The practical response is to settle them in discovery, not to hope they go away.

## What can run in parallel?

Several workstreams can move at the same time, and arranging them well is the cheapest way to shorten a calendar.

| Run together | Why it works |
|---|---|
| Visual design and infrastructure setup | Neither depends on the other once the prototype flows are agreed |
| Front-end build and back-end endpoints | With an agreed interface contract, both sides can progress independently |
| Content preparation and development | Copy, images and sample data can be written while the screens are built |
| Third-party account setup and feature work | Payment, e-mail and analytics accounts often take days to verify; start them in week 0 |
| Test writing and feature code | Tests for critical paths are written alongside, not at the end |
| Documentation and build | Written as the work happens, it is accurate at handover |

What does not parallelise well is decision-making. Architecture decisions, data model choices and scope calls sit on the critical path. Adding more engineers to a project that is waiting on a decision just adds more people waiting. It also adds coordination overhead, which is why small senior teams often beat larger ones on MVP timelines.

## How do you keep weekly demos going?

Weekly demos work when each week's work is cut into a slice small enough to finish and show, and when the product is deployed continuously.

1. **Cut vertically, not horizontally.** Build a thin end-to-end slice (screen, logic, data, deployment) rather than "all the database first". A slice can be demonstrated.
2. **Deploy from week one.** A pipeline that publishes to a live URL, with a preview link for every change, means the demo is always the real thing.
3. **Plan on Monday and say what is out.** Write down what will not be done this week. Saying it out loud prevents surprise on demo day.
4. **Review before you ship.** A short architecture and code review before the weekly demo catches problems while they are small.
5. **Demo every week, not on a slide.** Show the working product. Record the demo for stakeholders who cannot attend.
6. **Collect feedback in one place.** One list, one owner, ranked. Not ten e-mail threads.
7. **Keep a visible scope ledger.** Track what was added and what was removed so the date stays honest.

If the demo shows less than planned, adjust the next week's plan. Do not quietly extend the deadline.

## How long does mobile app store review take?

Plan for review time as a variable of days, not hours, and leave margin in case of rejection.

Apple's App Store and Google Play both review new apps and updates. Typical review times are often a day or two, but they vary, and a first submission is scrutinised more than an update. Rejections for missing privacy information, incomplete login credentials for reviewers, unclear permissions or placeholder content are common and avoidable.

Practical advice:

- Submit a first build for review well before the launch date, not on it.
- Prepare privacy policy, data-use declarations, screenshots, test accounts and descriptions in advance.
- Use TestFlight for iOS and internal or closed testing tracks for Android to gather feedback during the build.
- Consider whether a web version or an installable web app can be the first launch, with the store apps following. With React Native and Expo you can ship web, iOS and Android from one codebase, but each store still has its own process.

If your users sit at a desk, starting on the web and moving to the stores after you have traction removes a whole risk from the first date.

## What belongs on a launch checklist?

A launch checklist makes sure the product survives its first real users.

- [ ] Production environment separate from staging, and owned by you.
- [ ] Automated tests passing on the critical flows: sign-up, payment, the core action.
- [ ] Error tracking and alerts configured, with a named person who receives them.
- [ ] Uptime check and basic metrics on a dashboard.
- [ ] Backups taken and a restore actually tested.
- [ ] Load test at the traffic level you expect, plus a margin.
- [ ] Security review: dependencies, secrets, access control, input validation.
- [ ] Privacy policy, terms and cookie handling in place; data handling matches the policy.
- [ ] Payment flow tested end to end with real small transactions.
- [ ] Analytics tracking the one metric that decides whether the MVP worked.
- [ ] A launch-day runbook: who does what, how to roll back, who to call.
- [ ] Support channel ready: where users write and who answers.
- [ ] Documentation and access handed to the owner.

Do not skip error tracking, backups and rollback. They cost little and save the most when something goes wrong.

## What happens after the MVP launches?

The MVP is the start of the learning, not the end of the project.

In the first weeks you watch the metric you defined, talk to users and fix what breaks. Expect a stream of small bugs and usability issues. Reserve time for them rather than assuming the first release is finished.

Then comes the real decision: continue, change direction or stop. If the numbers support continuing, you decide what to build next based on evidence, not the original wish list. This may mean performance work, new features, a second platform, or a cleaner architecture where shortcuts were taken. Some teams keep a small product team on a monthly basis; others hand over to an in-house group. Either way, the code and accounts should already belong to you.

If you are not sure whether to build at all or to start with something off the shelf, the comparison in [build versus buy software](/insights/build-vs-buy-software/) is a useful first step. If the product will use language models, evaluation and cost per answer should start early; see [AI in your business: from demo to production](/insights/ai-in-your-business-demo-to-production/).

## How Hidook approaches this

Hidook is a remote-first product engineering studio. Our process follows the shape above: discovery in week 0, where you leave with a written scope and a price; a blueprint in week 1 with the architecture, data model and a clickable prototype, with decisions recorded; weekly build with a demo and a deploy to a live URL every Wednesday; then launch with load tests, a security review, monitoring, a runbook and on-call cover; and finally scale, which can mean new features or a clean handover.

Each build week follows the same cadence: plan on Monday and cut scope out loud, demo and deploy on Wednesday, code review and a production check on Wednesday. If something new appears, we cut scope to keep the date rather than moving the date. You own the repository and cloud accounts from day one, tests run on every pull request and error tracking is in place before the first user.

For mobile we use React Native and Expo, which lets web, iOS and Android come from one codebase. See [MVP development](/services/mvp-development/) for more.

## Frequently asked questions

### Can an MVP be built in four weeks?

A very narrow prototype can, if it has one flow, one user type and no complex integrations. For a product people will pay for and depend on, four weeks usually leaves no room for proper testing, monitoring and launch preparation. Be honest about which one you are building.

### Does a faster timeline mean a worse product?

Not necessarily. A short timeline with a narrow scope produces a smaller product, not a worse one. A short timeline with a large scope forces shortcuts on testing and reliability, which is when quality drops. Cut scope, not the foundations.

### Should discovery really take a week?

For many products, a focused discovery of about a week is enough to write down the scope, the metric and the main risks. Larger or more regulated products may need longer. Skipping it usually costs more later in rework than it saves up front.

### How much can I speed things up by hiring more developers?

Less than you would expect. Most MVP delays come from open decisions, integrations and approvals, which more developers do not fix. A small senior team with quick decisions often beats a larger one.

### When should I submit my mobile app for review?

As early as you have a build that meets the store rules, and well before your public launch date. A first submission can be rejected for fixable reasons, and each round costs days. Use TestFlight or Android testing tracks while you build.

### What happens if we run out of time before everything is done?

Cut scope, not quality. Agree early on which features are essential and which can follow in a second release. A launch with fewer features and solid foundations is better than a late launch with everything half-finished.

If you have a launch date in mind and want to check whether it is realistic, write to no.bs@hidook.tech or book a call at https://hidook.tech/contact/.