It's the first question every client asks, and the honest answer is: it depends on scope - but not in the vague way agencies use to dodge commitment. Let me break down where the time actually goes, using apps I've shipped as reference points.

The four phases

1. Scoping. Deciding what v1 actually is. Not "an app like Uber" - the specific screens, the specific user flow, the specific problem. This is a conversation, and cutting it is why most projects blow up later. A tight scope makes everything after it faster.

2. Design. Turning the scope into screens people can actually use. Small apps need fewer decisions here than you'd think - consistency beats decoration.

3. The build. Writing the code: frontend, backend, accounts, notifications, whatever your scope demands. This is the longest phase, and its length tracks almost perfectly with how disciplined phase one was.

4. Launch. Store listings, screenshots, privacy policies, review submissions. Apple reviews take real calendar days; Google Play is faster but still a step. First submissions often bounce once over a detail - budget for that emotionally even though my job is to prevent it procedurally.

A real example

LinkLoop, my CGM monitoring app for Type 1 Diabetes families, went from concept to the App Store in a focused sprint - then kept evolving: v1.0 shipped the core dashboard and Care Circle, v1.2 added AI insights, v1.5 brought the Apple Watch companion.

That's the pattern worth internalizing: v1 should be the smallest thing that solves the core problem. Everything else is a version number, not a launch blocker. SubHook, my rec-sports sub platform, followed the same rule - managers post spots, players tap to sub, ship it, iterate based on real usage.

The fastest app to build is the one where you're honest about what v1 doesn't do.

What stretches timelines

  • Moving requirements. Changing what you're building mid-build. Some drift is normal; constant reinvention isn't.
  • Third-party integrations. Every external API adds coordination you don't control.
  • Novel concepts. Genuinely new ideas deserve a small paid consulting engagement before committing to a full build - cheaper to learn in a week than to discover at month three.
  • Decision latency. The clock I can't control: how fast feedback comes back.

How I keep it honest

When you ask me for an app build quote, you get one flat number tied to a defined scope - so timeline and price are commitments, not open-ended meters. Want a realistic estimate for your idea? Bring me the concept and I'll tell you what v1 should look like.