How long does it take to build a web app? Honest ranges

It is always the same question and it always comes early. How long will this take? The honest answer on day one is that nobody can put a date on it yet, and that is not evasion. The timeline is set by decisions that have not been made, and most of them belong to the client rather than to us.

What follows is how we think about it, including the ranges we are willing to say out loud, and the specific things that move them in either direction.

The question underneath the question

Almost nobody actually wants a duration. They want to know whether this is a two week thing, a two month thing or a two year thing, because that determines whether they need a decision, a budget line or a board conversation. Those are three different problems and only one of them is about calendars.

So the useful first move is working out which of the three you are in. If it is a two year thing and you were hoping for two weeks, discovering that on day one is the single most valuable output of the entire conversation, and it costs nothing.

What actually sets the clock

Build time is dominated by a small number of factors, and the amount of code is not one of them.

• How many decisions are still open. Every unmade decision becomes a question mid-build, and a question mid-build costs several times what the same question costs before anyone opens an editor.
• How many systems it has to talk to. An app that stands alone is straightforward. The same app that must read from an accounting package, write to a payment provider and stay in step with a spreadsheet somebody maintains by hand is a different project wearing the same name.
• Who has to approve what. One decision maker who replies within a day is worth more to a timeline than an extra developer. This is not a figure of speech.
• Whether the data already exists and can be trusted. Migrating clean data is a task. Migrating data that disagrees with itself is a project, and it is almost always discovered late.

Ranges we will stand behind

Those are first versions in front of real users, not finished products. A first version that is genuinely used generates more change requests in its first month than the whole specification did, which is a good sign rather than a failure.

The first row slips more often than the other three, and always for the same reason. We have written up the pattern in the context of the three tools every training centre rebuilds in spreadsheets: what looks like one file is usually a small undocumented system with several copies and no owner.

Why the first version should be smaller than you want

The most reliable way to shorten a build is to cut what is in the first release, and the most common objection is that the smaller version would not be useful. Occasionally that is true. More often the list holds three things that matter and eleven that were added because they were easy to imagine.

The mechanics of that are a separate piece, how to scope a software project before anyone writes code. The short version: scope is not a document you write once, it is a boundary you defend weekly, and the defending is the work.

What delivery teams measure instead of project length

There is a useful shift in how software delivery gets measured, and it is worth borrowing even if you are commissioning software rather than writing it. Google's DORA research programme defines change lead time as the amount of time it takes for a change to go from committed to version control to deployed in production. Notice what that measures. Not how long the project took. How long one change takes to reach a user.

That distinction has a commercial edge. A team that ships a change in a day can be wrong cheaply and correct it on Tuesday. A team whose changes reach production once a quarter has to be right in advance, which is expensive and mostly not achievable. Worth knowing that the framework itself has moved: the same guide notes DORA has shifted from the original four keys to a current set of five metrics, adding measures of instability alongside throughput.

Where AI has changed this, and where it has not

The expectation now is that AI assistance collapses timelines. The research is more careful than the marketing. DORA's 2025 report on AI-assisted software development concludes that AI's primary role is as an amplifier, magnifying an organization's existing strengths and weaknesses, and that the greatest returns come not from the tools themselves but from a focus on the underlying organisational system.

That matches what we see. Generated code speeds up the part that was rarely the bottleneck. The bottleneck is a decision waiting on someone, or a data source nobody will vouch for. An amplifier pointed at an unclear brief produces unclear software faster, and then the review takes the time you thought you had saved.

The limit worth stating plainly

We cannot give you a date for a project nobody has scoped, and a firm that does is quoting a number rather than a plan. If you get a confident timeline before anyone has asked who approves what and where the data lives, you are being sold to.

There is an honest version of a firm date: fix the date and vary the scope. We will commit to a day and then work with you on what fits inside it. What nobody can honestly commit to is a fixed date around a fixed but unexamined scope, and that is the combination most people ask for.

How to narrow your own range before you call anyone

Three things, all free, none of which require us:

• Name one person who can decide. Not a committee. One name, with the authority to say no to their own colleagues.
• Write down the three things the first version must do, and be prepared to defend them against the other eleven when the other eleven arrive.
• Test whether your data is trustworthy by asking two people to produce the same number from it. If they disagree, that gap is now part of your project and it is better to price it than to meet it in week six.

Do those three and the range narrows before a line is written. Skip them and any estimate has to widen to cover the unknown, which is the honest thing for us to do and the expensive thing for you to receive.

The same arithmetic applies to work you already run by hand. If a process eats days every month, the question is not which tool to buy but which decision changes because of it, which is the argument in automating manual reporting without buying a BI platform. Either way, measure the thing before choosing a tool for it, and if you want a sense of how we size work, what we build is deliberately narrower than most people expect to be quoted for.