Short answer: a custom-built MVP from a professional team typically takes 8 to 18 weeks from kickoff to launch. A single-role web product sits at the short end. A mobile app with a backend and admin panel is usually 12 to 16 weeks. A two-sided marketplace on web and mobile is 16 weeks or more unless you cut one side down to almost nothing.
About these numbers. The durations below are planning estimates for a small experienced team (roughly two to four people) working from a written scope. They are not survey data and not a BBR delivery promise. Your schedule depends on your scope and on how quickly decisions get made.
Timeline by product type
Calendar time follows the same drivers as cost: number of user roles, number of platforms, and number of integrations. The table assumes discovery and design are included and that the team is not waiting on you for long.
| Product type | Typical calendar time | What sets the length |
|---|---|---|
| No-code or low-code MVP | 2–6 weeks | How far the workflow bends the platform's built-in patterns |
| Single-role web app or simple SaaS | 8–12 weeks | Complexity of the core workflow; billing model |
| B2B SaaS with teams, roles and subscription billing | 10–16 weeks | Permissions, invitations, plan logic, admin tooling |
| Mobile app (iOS and Android from one codebase) with backend and admin | 12–16 weeks | Device testing, push notifications, store billing, store review |
| Two-sided marketplace or booking platform | 16–24 weeks | Two interfaces, payouts, messaging, dispute and edge-case handling |
| AI-assisted product on hosted models | 8–14 weeks | Evaluation: getting output quality to an acceptable level is open-ended work |
| Anything with regulated data or hardware | Add 4+ weeks | Compliance review, vendor agreements, device certification or supply |
If the product you have in mind is mostly a mobile app, the app development timeline guide goes deeper on store and device specifics. For subscription software, the SaaS build guide covers the path from first release to paying customers.
Where the weeks go, phase by phase
Discovery and scoping: 1–2 weeks
Calls and written questions that turn an idea into a ranked feature list, a scope document with acceptance criteria, a technical approach and a quote. This phase is short, and skipping it is the most common cause of a long build. Every ambiguity left in the scope becomes a mid-build conversation that stops work.
Design: 1–3 weeks
User flows and screens for the core journey, reviewed as a clickable prototype. One week covers a narrow product with a standard interface. Three weeks covers two user roles or a product where the interaction itself is the differentiator. Backend setup can overlap with the second half of design, which is how well-run projects recover a week.
Build: 4–12 weeks
The widest range, because it contains the product. A useful way to read a build estimate is to ask what is demonstrable at the end of each two-week block. If the answer for the first six weeks is "nothing yet", the plan is structured around a big reveal and carries the risk that comes with one.
Testing and hardening: 1–2 weeks
Testing happens throughout, but a dedicated period before launch is still needed: real devices, slow networks, empty states, failed payments, password resets, the admin doing something unexpected. Teams that drop this phase to hit a date get the same work back as production bugs, at a worse time.
Launch: 1–2 weeks
Production environment, domain and email configuration, analytics, store listings, screenshots, privacy policy, store submission and handover. Most of this is small. It is also sequential and partly outside your control, so it takes longer on the calendar than its effort suggests.
What stretches an MVP timeline
Decision latency
The largest hidden factor. A team of three that waits two days for an answer has lost six person-days. Across a project, a founder who replies within a few hours and one who replies within a few days can be a month apart on the same scope. Agree up front who decides, and how quickly.
Scope changes during the build
Some change is healthy: you see the working product and learn something. The cost is rarely just the new feature. It is the rework of what was built around the old assumption, plus retesting. A good team prices and schedules each change before doing it, so you can choose between the change and the date with real numbers in front of you.
Third-party approvals
These run on someone else's clock and cannot be compressed by working harder:
- Apple Developer Program enrollment. Enrolling as a company requires a D-U-N-S number and identity checks. This can take from a few days to a few weeks.
- Google Play developer account. Identity verification applies to everyone. New personal accounts must also run a closed test with a group of testers for 14 consecutive days before they can publish to production. Organization accounts are not subject to that testing rule.
- Payment provider verification. Business details, bank account and sometimes a review of the business model. Marketplaces and anything near financial services get more scrutiny.
- API access programs. Some messaging, banking, health and social platforms require an application and review before they grant production access.
- SMS sender registration. In the US, business text messaging requires brand and campaign registration with carriers before messages are reliably delivered.
Store review
Review on either store is normally a matter of days. First submissions are rejected often enough that you should plan for it: a missing account-deletion option, unclear subscription terms, a login the reviewer cannot get past, permission requests without an explanation. Each rejection costs a fix plus another review cycle.
Content and legal material
Product copy, onboarding text, email templates, terms, privacy policy, seed data for a marketplace. These usually sit with the founder and are usually late. None of it is difficult. All of it blocks launch.
Integrations with poor documentation
A well-documented API takes days. A partner's undocumented system with a sandbox that behaves differently from production can take weeks, and nobody can tell you which one you have until work starts. Test the riskiest integration in the first fortnight, not the last.
How to shorten the timeline responsibly
There are ways to be faster that you will not regret, and ways you will.
| Shortens the schedule safely | Looks faster, costs more later |
|---|---|
| Launch on one platform first | Skipping the written scope |
| Cut a user role to a manual process run by you | Skipping the testing period |
| Use managed services for login, payments, email and file storage | Adding engineers in the final month |
| Use a standard component library instead of a custom design system | No staging environment; testing on production |
| Open developer, payment and API accounts in week one | Hard-coding what should be configuration, such as prices and plan limits |
| Hold one fixed weekly decision session and answer questions within a day | Building on a platform you already know you will leave in six months |
| Release to a small invited group before a public launch | Launching publicly with no analytics, so the learning period is wasted |
The first two rows do most of the work. The method for deciding which features survive is covered in our guide to building an MVP step by step.
A sample 12-week plan
This is an illustrative plan for a mobile app with accounts, one core workflow, in-app subscription, push notifications and a small web admin panel, built by a designer and two engineers. It is an example of sequencing, not a template to hold a vendor to.
| Week | Team is doing | Founder is doing | Reviewable at end of week |
|---|---|---|---|
| 1 | Discovery calls, feature ranking, technical approach | Answering questions; starting Apple, Google and payment account enrollment | Ranked feature list |
| 2 | Scope document, acceptance criteria, user flows | Reviewing and signing off the scope | Signed scope and schedule |
| 3 | Screen designs for the core journey; repository, environments and CI set up | Design feedback in one consolidated round | Clickable prototype, first pass |
| 4 | Design revisions, remaining screens; data model, authentication | Final design approval; drafting product copy | Approved prototype; login working on staging |
| 5–6 | Core workflow, first half; riskiest integration tested end to end | Testing builds on your own phone; weekly decision session | Installable test build with the main flow partly working |
| 7–8 | Core workflow complete; admin panel; subscription purchase flow | Terms and privacy policy with your lawyer; store listing text | Main flow complete end to end on staging |
| 9 | Push notifications, emails, settings, account deletion | Recruiting 10–20 first testers | Feature-complete build |
| 10 | Testing on a range of devices, bug fixing, empty and error states | Structured testing against the acceptance criteria | Release candidate |
| 11 | Production environment, analytics, store submission, invited-tester release | Onboarding the first testers personally | App in review; testers using it |
| 12 | Fixes from tester feedback and any store rejection; handover documentation | Launch communication | Public release; repository and accounts handed over |
Two things in that plan are easy to miss. The founder column is never empty: a 12-week build needs several hours of your time every week, and more in weeks 1–4 and 10–12. And store accounts start in week one, because they are the item most likely to hold a finished app hostage.
How to read a timeline in a proposal
- It lists phases with durations, not a single end date
- Every two to three weeks there is something you can open and test
- Testing and release have their own line
- It states what the team needs from you, and by when
- It says what happens to the date when scope changes
- Third-party approvals are named as external dependencies
A timeline that is much shorter than the others you received is usually a smaller scope or a missing phase. Compare the phases, the same way you would compare quotes line by line. The MVP cost guide explains how effort converts into price, and the MVP development service page describes how BBR structures these stages.