The honest timeline for a first version is somewhere between two weeks and three months, and the gap between those numbers isn't mostly about how much code there is to write. Writing the code got a lot faster over the last two years. Everything around it didn't move nearly as much, which is why a project can still stretch even when the tooling is quicker than ever.
Where the time actually goes
- Deciding what you're actually building. A brief that's still being figured out mid-build turns every week into a negotiation about scope. Settling this before anyone writes a line is the single biggest lever on the calendar.
- Waiting on you. Logins for the systems you want connected, a decision on a screen, feedback on a draft — every day that sits in someone's inbox is a day added to the project, and it rarely gets counted as part of the timeline.
- Review cycles. Not the building — the back-and-forth of "nearly, but not quite" that happens when what was asked for and what was pictured don't quite match.
- Anything connecting to a system you already run. A payment provider, a CRM, an accounting package. These have their own quirks and their own support queues, and they don't move faster because your project is in a hurry.
What got faster, and what didn't
Scaffolding a project, wiring up standard pieces, writing a first draft of a form or an admin screen — AI tooling collapsed the time this used to take, sometimes from days to hours. What it didn't touch is judgement: deciding what the app should actually do, catching the version of a feature that looks right but is subtly wrong, and testing it properly before real customers touch it. That part takes the same care it always did.
This is the same shift covered in our piece on why agency pricing looks inflated now — the slow-but-not-hard work shrank. The work that needs a person thinking about it didn't.
What actually shortens the timeline
- 1Write down what "done" looks like before asking for a quote — one paragraph, in plain language, is enough to start from.
- 2Have your logins and accounts ready on day one for anything the app needs to connect to.
- 3Agree a single point of contact who can give feedback within a day, not whoever's free that week.
- 4Decide upfront what's genuinely needed for launch versus what can wait for version two, and write both lists down.
A fixed 2–3 week timeline, like the one we quote for a first version, only holds if those four are true going in. It's not a marketing number — it's what's left once the guesswork about scope has already happened somewhere else, earlier, on paper.