How Long Does It Take to Develop an App? The Honest Math

An 8-week build that ships in week 14 is usually not a story about lazy developers or a shop that lowballed the number to win the deal. Six weeks of gap leaves a paper trail. Here is what that trail looks like across our projects, which parts of it sit on your side of the fence, and how to read the next timeline a vendor hands you so the happy path does not stand in for a plan. One more thing colors every trail we autopsy now: AI. It writes production code faster than any tool we have used, and at the same time it adds a failure mode the older timelines never priced in. Both facts matter, and neither cancels the other.

The honest answer, in ranges

First, the question everyone types into a search box at some point. How long does it take to develop an app? Across our builds, the honest ranges look like this:

• A focused web app with a clear scope, one user type, and standard screens: 6 to 10 weeks.
• A mid-size business app with roles, reporting, and two or three integrations: 3 to 5 months.
• A platform with multiple user types, external systems, and compliance in the mix: 6 to 12 months.

AI has compressed the middle of those ranges, not the ends. Scaffolding, boilerplate, CRUD screens, and first-draft integrations now appear in days instead of weeks, and on a clean-scope build that can pull a quoted 8 down toward 6. What it has not compressed is the rest of the range, because the rest was never made of typing. Decisions, third parties, and verification set the ends, and AI has not touched them.

Notice those are ranges, not single dates. Anyone who quotes you one date is quoting the happy path. The happy path assumes nothing goes wrong on either side, and something always does.

Where the weeks actually go

An 8-week quote for a focused web app breaks down roughly like this: two to three weeks of discovery and design, four to five weeks of building, and a week or two of testing and hardening before launch. That math only holds if the clock runs continuously, and the clock runs continuously only if decisions arrive while the build is moving.

AI changes the shape of the building weeks more than their length. Screens that took a week to hand-code now draft in a day, which sounds like the whole build should halve. It does not, because every line of AI-generated code needs senior review before it earns the name production code. Models write plausible code: it compiles, it handles the demo path beautifully, and it quietly mishandles the empty state, the concurrent user, or the odd timezone that only shows up under real data. Reviewing, correcting, and hardening that output takes real senior hours, and those hours land in the same weeks the quote allocated for building. The typing got faster. The verification bill is new, and it is not small.

The quote prices effort. The calendar eats elapsed time. Those are different things, and the difference is where six weeks of your life goes. Testing is where it shows up first, because testing is scheduled, budgeted, and staffed, so every day of drift lands directly on the launch date instead of quietly spreading out across the build.

Stretcher one: the decision that waits on your desk

Builds move in loops. We build a screen, you look at it, we adjust. We propose two report layouts, you pick one, we build it. Every loop has a wait built into it, and the wait sits on your side of the fence. AI has not touched this number, and nothing on our side can.

Three business days per decision feels responsive. It is responsive, in office terms. But a mid-size app carries six to ten of these checkpoints, and the arithmetic is brutal: six approvals at three days each burns eighteen calendar days before anyone writes a line of slow code. That is three and a half weeks of a quoted eight. Nobody lied in the proposal. The waits just stacked.

The fixes are unglamorous. One empowered decision-maker instead of a committee of four that meets weekly. A standing 30-minute review slot twice a week instead of ad hoc feedback. Content, logins, and credentials for the systems we touch, handed over at kickoff instead of at the moment we ask for them. One client of ours collapsed three weeks of drift into four days purely by moving sign-offs out of email threads and into two fixed weekly calls.

Stretcher two: scope that grows after kickoff

Nobody plans scope creep. It arrives dressed as a small favor. While you are in there, can the intake form also flag duplicates? The dashboard should probably show margin alongside revenue. Sales wants a CSV export, and that is tiny, right?

AI has made this stretcher worse, not better, because it makes every favor feel free. The request now arrives with a new preamble: if the AI is writing the code anyway, can it also...? Drafting did get cheaper. But every AI-drafted addition still needs the same review, the same edge-case testing, and the same ripple check across the database, validation, reports, and exports as hand-written code. Sometimes it needs more, because generated code fails in confident, plausible ways that only surface under real data. A two-hour feature in discovery is still a two-day feature in week five, whatever wrote the first draft.

Individually, yes, each one is tiny. But mid-build changes do not add up linearly. A field on the intake form touches the database, the validation, the report, the export, and the tests, and every touch re-opens work that was already finished.

The shops worth hiring put every change in writing, with its timeline cost, and make you approve the trade. The ones that want to stay likable absorb the small favors silently, then miss the date and let you conclude the problem is their speed. When a build runs long and you cannot remember approving any changes, that is usually what happened.

Stretcher three: the dependency nobody scheduled

The third stretcher is the one nobody owns, which is exactly why it runs long. Your app needs things from third parties. A payment gateway account. Access to your old database. A sandbox key from your CRM vendor. A compliance sign-off. Credentials from whoever hosts your current site.

Some of those arrive in a day. Some take weeks, and the vendor doesn't care about your launch date because you are not their customer yet. We have waited longer for a gateway sandbox key than for the legal review of the entire engagement, and the calendar cannot tell the difference. A build moves only as fast as its slowest external dependency. This is also the stretcher AI cannot help with: a model can draft the integration code before the sandbox key exists, and the calendar will still wait on the vendor.

Hunting those dependencies in week zero and starting the slow clocks first is our job. But the account you must open, the form you must sign, the vendor you must chase, the bank officer who needs a phone call before any of it moves, those sit with you, and no amount of building outruns an unopened ticket.

Which of the three are yours to fix

Split the ledger honestly and the diagnostic writes itself. Decision latency is yours, along with content, credentials at kickoff, and chasing your own vendors for access. Dependency discovery in week zero is ours, along with writing down the timeline cost of every change and saying so out loud when a wait is our fault. Scope is shared. You own the asking. We own pricing it honestly instead of absorbing it to avoid a hard conversation.

So when a project starts slipping, ask which of the three is eating the calendar. A good shop answers with names and dates. A vague one answers with a weather report about how software is unpredictable.

How to read the timeline in a quote

Before you sign, interrogate the number.

• What has to be true for the 8 weeks to hold? A good answer names assumptions: content ready at kickoff, feedback inside two business days, no new integrations after scope lock.
• What happens to the clock when feedback waits? If the answer is nothing, the quote is fiction with a date on it.
• What is excluded? Data cleanup, third-party accounts, and launch-day support hide in that gap.
• Who signs off, and how fast can they?
• If AI is part of the plan, who reviews what it writes? A good answer names senior reviewers and audit hours. A vague one assumes generated code is free and correct, which no code ever is.

If the person across the table cannot answer those, the timeline was a closing technique. If they answer crisply, you are talking to a shop that has lived through the gap and prices for it.

The decision rule

Ask for two numbers, not one. The effort timeline, and the elapsed timeline under your real feedback speed. A shop that won't build the second number with you is not managing the gap, it is hoping it away.

Then plan around the second number. Take the quoted date, add the buffer your own decision speed honestly needs, and treat that buffer as a deliverable, because it is one. And when AI is in the pitch, ask for the same second number with review time priced in. Machine-written code has made the first number smaller and the audit line bigger, and a shop that cannot show you both is selling you the demo, not the deployment. The builds that ship on time are rarely the fastest ones. They are the ones where the client ran their side of the calendar as seriously as we run ours.

If you are sizing a web app and want a timeline built on your actual decision loop instead of the happy path, that is the first conversation in every web application development engagement we start. Bring your last quote if you have one. Reading the gaps in it takes about half an hour and costs nothing.