Most people asking this question are really asking two others: when will I see something, and when can we stop doing it the old way. Those have different answers, and the gap between them is where most of the frustration in software projects lives.
The short version
A single, well-understood process can usually be live in a matter of weeks. A connected internal system takes a couple of months. Anything involving external users, or several systems that have to agree with each other, takes longer than that.
Those are working ranges rather than promises. What follows is what moves them, because the variables matter more than the averages.
What actually sets the timescale
How well the process is understood
This is the single biggest factor, and it is almost never the code. A process that one person can describe end to end, including the exceptions, can be built quickly. A process that three people describe differently cannot be built at all until that is resolved, and resolving it is organisational work rather than technical work.
If you want to compress a timeline, this is where the time is. Writing the process down before anyone quotes for it routinely saves more time than any decision made later.
How many other systems are involved
Standing alone, an application is straightforward. Reading from the finance system, writing back to the CRM and honouring a supplier feed is a different proposition, and the difficulty is rarely the code. It is access, credentials, test data, and finding the person who knows why a field means something other than its name.
Integration is also where estimates go wrong most often, because the unknowns only become visible once someone tries it. A supplier who asks detailed questions about your other systems early is not being difficult, they are removing the largest source of slippage.
Who has to sign it off
A project with one decision-maker moves at the speed of the build. A project needing sign-off from three departments moves at the speed of the meeting schedule. This is worth being honest about at the start, because it is entirely predictable and entirely outside the developer’s control.
How much of it has to be right on day one
Not everything does. A system that replaces a spreadsheet for one team can go live with the second team following a month later. Deciding what must be in the first release, and what can wait, is usually the difference between weeks and months.
Whether anyone is available to answer questions
Every build generates questions that only the business can answer. If those wait a week each, the project runs at the speed of the replies. An hour a week from somebody who knows the process is worth more to a timeline than almost anything else.
What the time is spent on
It surprises people that writing code is rarely the majority of it. A typical project splits roughly into:
Understanding and agreeing the process. Turning what people do into something precise enough to build.
Building. The part everyone pictures.
Data. Getting what exists today into the new system, in a state worth keeping. Historic data is almost always messier than expected, and cleaning it is work nobody budgets for.
Testing with real people. Not whether it functions, but whether it fits. This is where the useful changes come from, and skipping it only moves those changes to after launch.
Getting it live. Access, accounts, training, and the week where both systems run side by side.
Why projects run late
In our experience the causes repeat, and none of them are exotic.
The requirement changed because it was never settled. Not the same as legitimate change. This is where a process was described optimistically, and the real one surfaced during testing.
An integration turned out to be harder than the demo suggested. The API did not expose the field, or the credentials took six weeks.
Sign-off queued. Work finished, then waited.
Scope grew quietly. A small addition each week, none of them individually worth arguing about.
Data migration. Consistently the most underestimated task in the whole project.
Notice how few of these are about development speed. Hiring more developers does not fix any of them, which is why adding people to a late project so rarely helps.
Getting something useful sooner
Cut the first release hard. One process, one team, the smallest thing that replaces a real piece of work. Something live and useful in weeks beats a complete system in six months, because it produces feedback while the decisions are still cheap to change.
Write the brief before asking for quotes. It is the cheapest acceleration available, and it improves the quotes as well. We have set out what belongs in one in how to write a brief for a software project.
Name one decision-maker. Someone who can answer questions without convening anybody.
Start the access conversation on day one. Credentials, test environments and permissions for other systems take calendar time regardless of effort.
Deal with the data early. Look at what you actually have, in its current state, before anyone plans around it.
What a realistic plan looks like
A sensible project has a first release that is deliberately small, a date for it, and an explicit list of what is not in it. It has a named person on your side who answers questions. It has the integration risks identified rather than assumed. And it has a second release already sketched, so the first one can be genuinely minimal without anybody feeling short-changed.
If a supplier quotes a long timeline with no interim delivery, ask what could be live in the first month. If the answer is nothing, the scope is probably wrong rather than the estimate.
Time against cost
The two are related but not the same. A longer project is more expensive, but the reverse does not hold: compressing a timeline by adding people generally raises cost faster than it saves time, because coordination grows quicker than output.
The reliable way to spend less and finish sooner is the same in both cases, which is to build less in the first pass. We go through the cost side of that trade in how much custom software costs in the UK.