How long does software development take?

Timeline questions get vague answers because the honest answer depends on things the supplier cannot see yet. Here are the realistic ranges, and — more usefully — the three variables that actually decide where within them you land.

Typical timelines

These assume a competent team working continuously. Where a project lands within its range is decided mostly by three things, and two of them are on the client's side.

1. Decision speed — the largest factor

This is the single biggest variable, and it is entirely yours.

Projects where one person can approve a decision the same day move roughly twice as fast as projects where every decision goes to a committee that meets fortnightly. On a four-month project, client-side approval delays routinely add months — and from the outside it looks like the supplier was slow.

Before the project starts, name the person who can make decisions and commit to a turnaround. That single arrangement compresses schedules more reliably than adding engineers.

2. How clear the requirements are

A documented specification produces an accurate estimate. A conversational brief produces an estimate based on what the supplier assumed you meant — and the gap surfaces in week six, when something is built and you say that is not what you wanted.

That is not negligence on either side. It is the predictable result of two people using the same words to mean different things. Time spent writing down what you need, before anyone estimates, is the cheapest time in the whole project.

3. Integrations

Connecting to a third-party system consistently takes longer than anyone estimates, for reasons that are nobody's fault:

• Getting credentials from the other party takes days or weeks
• API documentation is incomplete or out of date
• Sandbox access has its own approval queue
• The system behaves differently from what the documentation describes

If your project has three integrations, assume at least one of them will be the thing that delays go-live. Starting the credential requests in week one, before the code that needs them exists, removes most of that risk.

More people does not mean faster

Adding engineers past a certain point slows a project down. Every additional person needs briefing, coordinating and reviewing, and the senior people who would have been building are now mentoring instead.

An eight-person team is rarely twice as productive as a four-person one. If a supplier proposes to hit an aggressive deadline by adding staff, ask what specifically the extra people will work on in parallel — the honest answer is often that some of the work simply cannot be parallelised.

The only reliable way to go faster

Cut scope, not time. A shorter schedule for the same scope means the same work compressed, and what actually compresses is testing.

Then ask for something usable early — a working piece in week three, and every two weeks after. This gives you two things: real data on how fast the team is actually moving, rather than a percentage-complete figure, and protection against the late surprise where everything is reportedly ninety per cent done for two months.

A supplier confident in their estimate will agree to this readily. Reluctance is itself information.

If you have a deadline and want an honest view on whether it is achievable, we would rather tell you before you commit than after.