“How long will it take” is the first question every founder asks and the last one most agencies answer honestly. The standard reply is “it depends,” which is true but useless. So we went back through our last five client projects and pulled the actual dates: contract signed, first commit, feature-complete, submitted to the App Store or first production deploy, live. Then we broke out what ate the time that wasn’t building.
The build work itself — writing the app, wiring the backend, testing the flows — was consistently the smallest source of surprise. It’s everything around the build that stretches timelines, and it stretches them in predictable, repeatable ways. Here’s where the clock actually went.
The three delays that show up on every project
Across all five engagements, the elapsed time from signed contract to live app was longer than the engineering estimate in every single case. Not because the estimate was wrong about the work — it was wrong about the world around the work. Three causes accounted for almost all of the gap:
- App Store and Play Store review cycles. First submissions get rejected more often than founders expect — usually for things that have nothing to do with code quality: missing privacy policy language, screenshots that don’t match the actual app flow, or a login requirement Apple’s reviewer couldn’t get past because we hadn’t provided a demo account. Each rejection-and-resubmit cycle costs anywhere from two days to two weeks depending on the store’s queue at the time.
- Third-party account and credential setup. Payment processor approval, Apple Developer Program enrollment for a new business entity, push notification certificates, mapping or SMS API keys — these are gated by outside companies, not by us, and they routinely take longer than the feature they unlock. A client who hasn’t registered their Apple Developer account before day one has already lost a week they didn’t know they’d lost.
- Client-side decision latency. Waiting on a logo file, a final decision on whether guest checkout is in scope, sign-off on a design mockup. This isn’t a criticism — founders are usually running the rest of their business at the same time — but it’s real elapsed time, and it’s the single largest variable between our fastest and slowest project.
None of these are engineering problems. All of them show up on the calendar as “the app isn’t done yet.”
What actually moved the fast ones faster
The two projects that shipped closest to their original estimate had one thing in common: the founder treated store accounts and third-party credentials as day-one setup tasks, not week-six afterthoughts. We sent a checklist before the contract was even signed — Apple Developer account, Google Play Console, payment processor application, any API keys we knew we’d need — and the client knocked it out in the first few days, in parallel with us starting the build.
That single change routinely saves one to three weeks, because it removes a dependency from the critical path instead of discovering it there. It’s the cheapest timeline improvement available and almost nobody does it by default.
The other pattern in the faster projects: scope was locked before the build started, in writing, with an explicit list of what was “v1” and what was “fast-follow.” The slowest project on our list wasn’t slow because of bad code — it was slow because “let’s also add X” kept arriving mid-sprint, and each addition reset testing, not just development. We don’t treat scope changes as a problem; founders learn things mid-build and should act on them. But we do treat them as a timeline conversation the moment they come up, not a surprise at delivery.
What we tell clients now
We stopped giving single-number timeline estimates. Instead we give three numbers: engineering time (the part we control), external dependency time (store review, API approvals — bounded but not controlled by us), and decision time (bounded by how fast the client can turn around approvals). We tell clients upfront which bucket is likely to be the long pole for their specific project, because it’s different every time — a consumer app with in-app purchases will usually have App Store review as its long pole; an internal admin tool for an existing business usually has decision latency as its long pole, because there’s no store review at all.
We also flag the App Store submission risk early rather than at the end. If a client’s app touches health data, financial accounts, or has any login-gated content, we build the reviewer demo account and privacy documentation alongside the feature, not after — because that’s the exact category of app most likely to bounce on first submission.
None of this makes timelines fixed. A founder who takes three weeks to approve a design mockup will still take three weeks, and we can’t ship an app store submission that’s stuck in Apple’s queue any faster than Apple moves it. But naming the actual sources of delay, instead of hiding behind “it depends,” at least means nobody’s timeline conversation six weeks in starts with “wait, why isn’t this done yet.”
This is the same approach we bring to code audits and stalled builds we’re brought in to rescue — Crumb Count and Kompete both shipped on this model, and if you’re weighing whether a build is on track or quietly drifting, we’re happy to look at where your clock is actually going.