How Long Does It Take to Build an App With AI?
The prototype is 10% of the job and the demos only ever show the prototype. Where the time actually goes across four stages, with concrete ranges by app type.
A working first version of a small app, built with AI by one non-developer, takes about two to five days of focused effort. Getting that same app to something you would let a paying customer use takes another two to six weeks. The gap between those two numbers is the entire story, and it is where nearly every estimate goes wrong.
The build is not the slow part any more. The slow part is everything that surrounds a build: deciding what the thing actually does, handling the cases you did not think of, and the long tail of small breakages that only appear once real people touch it.
The four stages, and where the time actually goes
Rough proportions for a typical small internal tool or simple SaaS product, built by one person with an AI app builder or coding agent.
Stage | Share of total time | What it feels like |
|---|---|---|
Deciding what to build | 15% | Frustrating, feels like not working |
First working version | 10% | Fast, exhilarating, misleading |
Making it hold up | 55% | Slow, unglamorous, where projects die |
Launch and first users | 20% | Fine, if stage three was done properly |
The second row is the one that gets quoted in demos and the one that sets everybody's expectations wrong. Yes, you can genuinely get a working prototype in an afternoon. That afternoon is a tenth of the job.
What "deciding what to build" actually costs
Two to five days for something small, and it is not optional. It is only skippable if you have already done it in your head over months, which is common and easy to mistake for the work being unnecessary.
Concretely, before you start you need: the list of screens, the list of things a user can do on each, the data you are storing, and the one sentence describing what the app is for. If any of those are vague, the AI will make the decision for you and it will make it inconsistently across sessions.
The cheapest possible version of this stage is writing the user-facing help page before writing the app. It takes an hour and forces every ambiguity to the surface.
Why "making it hold up" is 55%
This is the stage nobody estimates, so here is what is actually in it.
The cases you did not think of. Empty states, someone entering a name with an apostrophe, two people editing the same record, a date in a different format, what happens on a phone. Every one is a small fix. There are more of them than you expect, and they arrive in a steady trickle rather than a batch.
Accounts and permissions. Almost every app needs to know who is using it and what they can see. This is more work than it looks and is a common place for AI-built apps to be subtly wrong in ways that only matter later. Adding user accounts and the permissions that go with them takes a day or two to do properly rather than approximately.
The second feature interacting with the first. A prototype has one path. A real app has features that touch each other, and AI coding tools are noticeably worse at the second feature than the first, because the context now includes decisions made in an earlier session.
Things breaking that used to work. This is the tax nobody budgets for. You add something, an earlier thing quietly stops working, and you find out three days later. It is why tests stop being optional somewhere around week two, even if you never wrote a test before. The underlying effect is old news in software estimation: Fred Brooks made the same point about the gap between a working program and a usable product in The Mythical Man-Month, putting the multiplier at roughly three times.
Concrete ranges for concrete things
Times below assume one non-developer working with AI tools, in focused hours, from a clear spec. Multiply by roughly 1.5 if you are learning the tool at the same time.
What you are building | Prototype | Ready for real users |
|---|---|---|
Internal tool replacing a spreadsheet | 1 day | 1 to 2 weeks |
Booking or scheduling app | 2 days | 3 to 5 weeks |
Simple SaaS with accounts and payments | 3 days | 6 to 10 weeks |
Marketplace with two user types | 1 week | 3 to 6 months |
Anything with real-time collaboration | 1 week | 4 to 8 months |
The bottom two rows are where people get hurt. A two-sided marketplace looks like one app and is functionally three: the buyer side, the seller side, and the matching logic between them, each with its own edge cases.
The four things that reliably blow up the estimate
In rough order of how often they do it.
Scope discovered mid-build. Not scope creep from outside, scope you find yourself. "Obviously it also needs to email them" is a day. Three of those is a week.
Payments. Always more than expected. Not the taking of money, which is well-trodden, but refunds, failed cards, plan changes and the states in between. Budget a week for adding payments properly.
Migrating real data in. Existing customer data is messy in ways your app does not expect, and cleaning it is manual.
Waiting on someone else. App store review, a client's feedback, a domain transfer, an API approval. This is calendar time, not work time, and it does not compress.
How to give an estimate you will not regret
Estimate the four stages separately and never quote the prototype.
Then apply one correction that is embarrassingly effective: ask how long you think it will take, then ask what the last three things you built actually took against their estimate. Most people are consistently wrong by a similar factor. Use your own factor rather than a generic one.
For anything you are quoting to a client, quote the range and name the two or three specific things that would push it to the top of that range. That conversation is much easier before the project than during it.
If you have not built anything with these tools yet, do the smallest real thing first, time it, and use that as your baseline rather than any number in this article. Building an internal tool is the usual first candidate because the users are forgiving and the scope is naturally bounded. The general shape of the process is in how to build an app with AI.
FAQ
Is it faster to build with AI than to hire a developer?
Faster to start, and much faster to a prototype. Over a full project the gap narrows, because the slow stages are decisions and edge cases rather than typing. The bigger difference is usually cost and control rather than raw speed.
Why do demos make it look like an hour?
Because demos build the prototype, which genuinely is fast, and stop there. Nothing in a demo has users, data migration, permissions or a second feature.
Does the estimate change with a better model?
Somewhat, and mostly in the first two stages. The 55% stage is dominated by discovering requirements and by things breaking in combination, which better models help with but do not remove.
How do I know when it is ready for real users?
When you have run a real workflow end to end, on a phone, with someone who did not build it, and nothing surprised you. Testing an AI-built app before launch is the checklist version.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
