“It depends on scope” is a true answer. It’s also a useless one when you’re trying to decide whether to start now or in the spring, or whether you can promise something to a client in June.
So here are real ranges — and more usefully, the things that actually move them. Most of what decides whether an app ships in three months or seven isn’t the code. It’s decisions.
The short answer, in ranges
Simple app / MVP — roughly 6 to 10 weeks
One core job, a handful of screens, light or no custom backend. A booking tool, a field-reporting app for your crew, a customer-facing app that does one thing well. This is the fastest real thing you can put in front of users.
Standard business app — roughly 3 to 5 months
User accounts, a real backend, permissions, one or two integrations with systems you already use. This is where most business apps actually land.
Multi-role platform — 6 months and up
Several types of user with different permissions, complex business logic, payments, reporting, multiple integrations. The kind of build where “the app” is really a system.
One caveat that matters more than the ranges themselves: these assume decisions arrive on time. That assumption is doing a lot of work, and the rest of this post is mostly about it.
Where the time actually goes
Discovery and scoping — 1 to 2 weeks. Working out what the app has to do, for whom, and what’s explicitly out of scope for v1. Skipping this doesn’t save two weeks; it moves them later, and they cost more when they arrive.
Wireframes and design — 2 to 4 weeks. Mapping the screens and the flow between them before anything gets built. Changes here are cheap. The same change during the build is not.
Build — the bulk of the timeline. This is the part everyone pictures when they think about how long an app takes, and it’s the part that’s most predictable once scope is settled.
Testing and fixes — 1 to 2 weeks. Reliably the most underestimated phase. Real devices, real edge cases, the things that only surface when someone who didn’t build it starts using it.
App store review — a few days to about two weeks. Only applies if you’re going native, and it’s the one stretch of the timeline nobody can speed up. Worth knowing before you book a launch date around it. (If you’re still deciding between native and web, that choice changes this whole picture — we wrote about it separately.)
What actually stretches a timeline
Almost none of the real delays are technical.
Scope that keeps moving. The single most common one. Every “can we also just…” mid-build is a small, reasonable request that pushes the finish line. Ten of them is a month.
Waiting on things only you can provide. Content, logo files, an API key for the CRM, an Apple Developer account, sign-off from someone on holiday. Work stops, and the calendar keeps going.
Decision latency. When a question needs an answer and it takes nine days to get one, that’s nine days. This isn’t a criticism of anyone — it’s the most normal thing in a business with actual work to do. But it needs an owner, because it’s usually the biggest single factor.
Integrations with undocumented systems. Connecting to a well-documented service is predictable. Connecting to the system a former employee built in 2019 is not, and nobody can quote it accurately up front.
What you can do to make it faster
Genuinely faster, not rushed:
- Decide the one job v1 has to do. Not the five. One. Everything else becomes v2, and v2 is much easier to plan once v1 exists and people are using it.
- Name one decision-maker. Someone who can answer a scoping question the same day without convening a meeting. This does more for a timeline than any technical choice.
- Get the boring accounts ready early. Developer accounts, API credentials, access to the systems you want integrated. These take days to sort out and they always get started too late.
- Accept a smaller v1. The version that ships teaches you more in two weeks of real use than another month of planning will.
Why shipping smaller is usually better, not just faster
A smaller v1 isn’t a compromise version of the real thing. It’s how you find out which of your assumptions were wrong while it’s still cheap to change them.
Build the full feature list up front and you’ll ship six months of guesses at once. Build the core, put it in real hands, and the next set of decisions gets made with evidence instead. That’s also why the architecture matters early — an app built to grow can absorb v2 without starting over, which is a very different position from having to rebuild because the foundation only fit the original guess.
How we scope timelines
We work through requirements with you before any code gets written, and you get a realistic timeline before the project starts — not a best case we both quietly know won’t hold. If something in your scope is genuinely unpredictable, like an integration with a system nobody has documentation for, we’ll say that’s unpredictable rather than average it into a number that looks tidy.
If you’ve got an app in mind and need to know what it would actually take, tell us what you’re trying to build — or read more about how we approach app development.