Realistic Timelines: Why Your App Will Take Longer Than You've Been Quoted
This is the fourth post in a series adapted from my guide, Build It Right: An Insider's Guide to Mobile App Development for Non-Developers. Each entry takes one slice of the guide and turns it into something you can read in ten minutes.
Almost every client comes into a project with a timeline in their head, and almost every one of those timelines is wrong. Not because clients are unreasonable, but because they're being quoted by people who are leaving out half the work.
This post is about what an app project actually involves, why the estimates you'll be given are usually optimistic, and how to recognize a timeline that's been thought through.
The phases nobody mentions
Most timeline conversations focus on the part where the developer writes code. That's one phase out of five, and it's usually not even the longest one.
Planning and design (2 to 4 weeks)
Before any code gets written, someone has to make decisions about what the app does, how the screens fit together, and what they look like. Done seriously, that means wireframes, then visual design mockups, then your review and feedback, then revisions.
If you skip or rush this phase, the cost reappears later as feature changes mid-development, which are far more expensive than design changes are. I won't skip this phase even when clients ask me to. Code written without a clear design is code that gets thrown away.
Initial development (4 to 12 weeks for an MVP)
The actual coding. The range here is huge because it depends on what the app does. A simple content app or utility takes 4 to 6 weeks. An app with user accounts, a backend, and several connected features takes 8 to 12 weeks. An app that does anything genuinely complex (real-time features, AR or VR, sophisticated AI integration, deep system integration) takes longer.
Testing and refinement (2 to 3 weeks)
Even setting aside dedicated QA, the developer has to test the app, you have to test the app, and bugs have to be fixed. This phase always takes longer than expected, because finding bugs and fixing them are different problems, and fixing one sometimes uncovers others.
App Store review (1 to 7 days, sometimes longer)
This is the phase clients forget about most often. Apple and Google both review every app before it appears in the store. The first submission is frequently rejected, often for reasons that aren't obvious until you've been through it. Common rejection reasons include incomplete metadata, missing privacy policy disclosures, in-app purchase implementation problems, and ambiguity about what the app does.
I plan for at least one rejection and resubmission cycle. Clients who haven't been through the process before are usually surprised by it.
Post-launch fixes (ongoing)
The first two weeks after launch will produce bugs and edge cases nobody saw during testing, because real users use apps differently than test users do. A serious developer plans for this. A casual one disappears the day the app goes live.
Add it up and you're at roughly 9 to 22 weeks for an MVP-grade app, with most projects landing somewhere in the middle.
Why estimates go wrong
Four things, mostly.
Optimism bias
Developers, myself included, underestimate how long things take. We remember the projects that went smoothly and forget the ones that didn't. The fix is experience, and even with experience the bias never fully goes away.
Undefined scope
The most common cause of timeline blowouts is that the scope was never clearly defined at the start. Every "wait, can we also add..." conversation extends the timeline, and most projects accumulate dozens of those. This is also why post 1 in this series spent so much time on getting the vision clear before development begins.
Your own time
Your timeline includes the time you take to review and approve work, give feedback, make decisions, and answer questions. If you're not available for a week, the project is paused for a week. Most estimates assume you'll respond within a day or two. That's often unrealistic, and the project pays for it.
External dependencies
APIs you're integrating with, third-party services, designers and testers other than the developer, your own marketing team. Anything outside the developer's direct control adds variance, and clients tend to underestimate how much of a project is outside the developer's direct control.
What a realistic timeline looks like
A timeline you can trust has a few characteristics.
It includes design and review phases, not just development. If a developer quotes you 6 weeks of "build" with nothing else, ask what that 6 weeks includes.
It identifies milestones with deliverables you can review. "Mid-project demo of the login and onboarding flows" is a milestone. "Halfway done" is not.
It includes buffer for App Store review and at least one rejection cycle. A developer who claims they've never had an app rejected has either not shipped many apps or is rounding the truth.
It accounts for your time. A good developer asks how much availability you have for review and feedback, and adjusts the timeline accordingly.
It distinguishes hard deadlines from estimates. "We can ship by mid-March" is different from "I think we can ship by mid-March, with the following risks." A developer who can't articulate the difference hasn't thought about it.
Red flags
A few things to watch for when someone gives you a timeline.
"I can have this done in two weeks." For anything other than a genuinely small project, this is either a misunderstanding of the scope or a developer trying to win the bid. You'll find out which one when you're three weeks in and not done.
A timeline with no design phase. Either design is happening somewhere you're not seeing, or it isn't happening at all. Both are problems.
A timeline that doesn't mention App Store review. The developer has either not actually shipped many apps or hasn't planned for review at all.
Estimates that don't change as the scope changes. If you ask for a new feature mid-project and the developer keeps the original timeline, they're either not telling you the truth or they were padding the estimate from the start.
What to do with this
You can't make a timeline more accurate by asking for it to be shorter.
What you can do is make sure the timeline you're being quoted reflects all the work, not just the visible parts. If a developer's quote is dramatically faster than what I've described above, that's not necessarily wrong. They may be more efficient, the scope may be smaller than I'm assuming, or they may have done similar projects before and know shortcuts. But ask. A serious developer will be able to walk you through where the time is going. A less serious one will give you a number and move on.
And once a timeline is set, treat slippage as a signal, not a normal part of the process. Some slip is inevitable. Repeated slip is a sign that the original estimate was wrong, the scope is changing, or something else is going sideways. None of those resolve themselves by waiting another week.
The next post in the series gets into the question that comes before the timeline question: how to evaluate a freelancer in the first place. What their profile actually tells you, what to listen for in the interview, and how to tell the difference between someone who can do the work and someone who can describe it.
This post is adapted from Build It Right: An Insider's Guide to Mobile App Development for Non-Developers. If you'd rather just talk it through, reach me at scott@appswage.com.