MVP: cutting the scope without sabotaging the product
4 min read
Key takeaways
- Allow 4 to 8 weeks for a mobile MVP on one platform, 3 to 4 months for a full iOS + Android app, and 5 to 8 months for a business platform or a marketplace.
- Delays rarely come from the code: stores, third-party integrations, content, sign-offs and compliance weigh more.
- You shorten a schedule by reducing the scope and deciding quickly, not by trimming the testing.
- A good schedule in a quote shows milestones, an acceptance testing phase, a buffer for the stores and a list of what you need to provide.
"How long does it take to develop an app?" It is often the second question, right after the budget. The short answer: 4 to 8 weeks for an MVP on one platform, 3 to 4 months for a full iOS + Android app, 5 to 8 months for a business platform or a marketplace.
The useful answer lies elsewhere. On projects that slip, the code is rarely to blame. It is the stores, the integrations, the content, the decisions and compliance that push the dates back. Here are our benchmarks, what stretches a schedule, how to shorten it without sacrificing quality, and how to read the one presented to you in a quote.
Realistic timelines by project type
These are the durations we see on our projects, from scoping to going live.
| Project type | Timeline | What it covers |
|---|---|---|
| Mobile MVP | 4 to 8 weeks | One platform, one main journey, the essentials done well |
| Marketplace MVP | 2 to 3 months | Two types of user, payment, matching |
| Full iOS + Android app | 3 to 4 months | Both stores, back office, notifications, accounts |
| SaaS platform | 4 to 6 months | Subscriptions, roles, administration area |
| Business platform or marketplace | 5 to 8 months | Several user profiles, integrations, business rules |
If your app includes an artificial intelligence feature, add its own track: 1 to 2 weeks for a scoping workshop, 3 to 5 weeks for a proof of concept, then 3 to 4 months for a production-grade assistant. These phases can run in parallel with the app, provided they are planned from the start.
4–8 weeksMobile MVP on one platform
3–4 monthsFull iOS + Android app
5–8 monthsBusiness platform or marketplace
Effort and timeline are not the same thing
A quote often talks in person-days. An MVP typically represents 30 to 60 person-days, a full app 120 to 200, a platform 250 to 450. That figure measures the work, not the calendar.
A full app of 150 person-days does not take 150 days: several people work in parallel (design, mobile, back end, testing) and the project fits into 3 to 4 months. The reverse is also true. Doubling the team does not halve the timeline. Every person added has to be onboarded, coordinated and reviewed. Beyond a certain size, you lose time on synchronisation instead of gaining it.
So keep two separate figures in mind: the effort sets the budget, the way the team is organised sets the date.
What really stretches a schedule
Publishing on the stores
This is the step most often forgotten in optimistic schedules. A finished app is not a published app.
On Apple's side, review is quick under normal conditions: Apple states that it handles at least 50% of submissions in under 24 hours and 90% in under 48 hours. The risk is not the wait, it is rejection. Each rejection means a fix, a new submission and a new review. We have detailed the most frequent rejection reasons: most of them can be anticipated at the design stage.
On Google Play, two points can cost weeks:
- Personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers opted in continuously for 14 days, then apply for production access. Google states that this review usually takes seven days or less, occasionally longer.
- For certain accounts, Google warns that an app review can take up to seven days, or longer in exceptional cases.
The remedy is administrative. Publish under an organisation account in your company's name, and create it as soon as the contract is signed. For organisations, Apple requires a legal entity and a D-U-N-S Number: if your company does not have one, the request should go out as early as possible.
Start these in week one, not the last week: Apple Developer and Google Play accounts in the company's name, D-U-N-S Number, access to third-party APIs, and the list of content to provide. None of these tasks requires code, and any of them can block the launch.
Integrations with third-party systems
Payment, ERP, CRM, point-of-sale software, a partner's API: every integration depends on someone else. You need access, a test environment, up-to-date documentation and a contact who replies.
Building the integration itself is rarely long. It is the waiting that costs: an API key that arrives after three reminders, a test environment that does not reflect production, a vendor who discovers mid-project that its API does not do what was planned. Ask for access before development starts and test it in the first week.
Content
Screen copy, photos, product sheets, translations, terms and conditions, privacy policy, store visuals and descriptions. All of this must exist before launch, and it is almost always the client who has to provide it.
Content delivered at the end of the project means reworking screens that were already approved: a title that is too long breaks a layout, a photo in the wrong format distorts a list. Set a content delivery date in the schedule, like any other milestone.
Decisions on the client side
A mock-up that waits ten days for sign-off means ten days of delay on everything after it. The problem gets worse when several people have to give their approval and do not agree with one another.
Two simple rules change the dynamic: a single decision-maker on the client side, who settles matters after consulting others, and a sign-off period agreed in advance for each deliverable. If that period is not met, the schedule slips by the same amount, and everyone knows it from the start.
Compliance
Personal data, health data, payment, accessibility: each regulatory requirement adds screens (consent, account deletion, data export), hosting choices and sometimes external approvals. GDPR applied to a mobile app is very manageable when handled at the design stage. Discovered on the eve of launch, it forces you to rework the architecture.
The rule is the same for all these topics: a constraint known at scoping costs a few lines in the schedule, a constraint discovered during acceptance testing costs weeks.
Shortening the timeline without cutting quality
Reduce the scope, not the finish
The most powerful lever remains the scope. An app that does fewer things, but does them perfectly, ships sooner and learns faster. We have devoted a whole article to the method for defining the scope of an MVP: the single journey, what you never cut, and the cuts that save the most time.
What you should not do is keep the full scope and squeeze the end. Testing, acceptance and error handling are the first casualties of a schedule that is too tight, and they are what decide whether the app holds up after launch.
Choose cross-platform when the use case allows
For an iOS + Android app, React Native or Flutter save 30 to 40% on the project. One codebase, one team, one series of functional tests: that is that much less effort to fit into the calendar.
Native (Swift, Kotlin) remains relevant for very hardware-heavy uses: intensive Bluetooth, sensors, video processing, advanced system features. Our comparison React Native, Flutter or native sets out the criteria for deciding.
Decide quickly, and in writing
A clear requirements document avoids weeks of back and forth. It is not a hundred-page document, but a precise list of journeys, business rules and edge cases. Our requirements document template runs to a few pages and is enough to launch a project without ambiguity.
During the project, regular demos of progress let you correct course early. A discrepancy spotted after two weeks is fixed in a day. The same discrepancy spotted at final delivery takes several weeks to fix.
Run in parallel whatever does not depend on the code
While the team is developing, you can write the content, prepare the store listings, recruit your testers, obtain partners' access and prepare the commercial launch. The projects that ship on time are the ones where the client works through their own list at the same time as the technical team.
How to read the schedule in a quote
A schedule says a lot about how the provider works. Here is what you should find in it.
| What you should find | Why it matters | Warning sign |
|---|---|---|
| Phases with a deliverable at each milestone | You can check progress in concrete terms | A single final delivery date |
| A separate acceptance testing phase | Testing has time set aside | No acceptance phase, or one merged into development |
| A buffer for store submission | Review times and rejections are planned for | Publication scheduled for the last day |
| A dated list of your obligations | Dependencies are visible on both sides | Nothing is asked of the client |
| The scope assumptions | You know what the timeline covers | A very short timeline with no written scope |
Two questions to ask every time. First: what happens if a sign-off arrives late? A clear answer (the schedule slips by the same amount, with or without extra cost) is worth more than a vague promise. Second: how is the timeline committed to in the contract? Fixed price, time and materials and a capped budget do not share the risk of delay in the same way. We compare these options in our article on billing models.
Finally, be wary of the shortest timeline in the comparison. If it is clearly below the others for the same scope, either the scope has not been understood in the same way, or acceptance testing has disappeared. Either way, the date shown is not the one on which your app will actually be live.
A realistic schedule is not the shortest one: it is the one that says in advance what could make it slip, and who has to act to prevent it.
The key points
For a first mobile project, think in three steps. Choose the right project type and its order of magnitude for the timeline. Start everything that does not depend on the code in the first week. Then check that the proposed schedule makes the milestones, acceptance testing, the stores and your own commitments visible.
If you want a costed timeline for your project, we provide a free quote within 24 hours, with a schedule broken down by phase.
Going further: our mobile app development page explains how we run a project, from scoping to store release.
Sources
- Apple Developer, "App Review": review times and expedited review requests.
- Apple Developer, "Enrollment": enrolment requirements for organisations and the D-U-N-S Number.
- Play Console Help, "App testing requirements for new personal developer accounts": 14-day closed test with 12 testers.
- Play Console Help, app review times: reviews that can take up to seven days or longer.
