How long does it take to build custom software?

Most people asking this want a date they can plan around. The honest structure of the answer is that a simple system can be live in weeks, a substantial one takes months, and almost every overrun in this industry comes from the same handful of causes rather than from developers being slow.

The shape of a normal project

Discovery, one to three weeks. Working out precisely what it does, what happens in the awkward cases, and what is deliberately not in version one. Rushing this does not save time, it moves the delay into the build where it costs more.

Design, one to three weeks. Screens, flows and the language the system uses. Frequently overlaps with the start of the build.

Build, the bulk of it. A single workflow can be a couple of weeks. A customer portal with several user types and a couple of integrations is more often two to four months. A platform that several different audiences depend on is longer still, and should be delivered in pieces rather than as one event.

Testing and launch, one to three weeks. Not just finding bugs. Getting real data in, training people, and running the old and new ways side by side long enough to trust it.

Why the first usable version matters more than the finished one

A project that delivers nothing for five months is a project where nobody has learned anything for five months. The requirements you wrote in month one were your best guess, and some of them were wrong, which is normal and only discoverable by using the thing.

Far better to agree what the smallest genuinely useful version is and get it in front of real users early. It changes what gets built next, it usually shortens the whole project, and it means the value starts arriving before the invoice does.

That is how an operating platform we have grown over several years came about. It was not commissioned as a finished article, it was built up as the business needed each part, which is why it still fits the business rather than the business fitting it.

The four things that actually cause overruns

Decisions nobody has made. Development stops while someone works out what should happen when a customer cancels after part-payment. The build is rarely the bottleneck. The answers are.

Feedback that arrives slowly. A one-week review that takes three weeks adds two weeks to the project, and it adds them at the end where they are most visible. Agreeing who reviews and how quickly is worth more than any project management software.

Other people's systems. Anything that depends on a third party, a government endpoint or a client's internal IT team moves at that party's pace. Our own work going through HMRC's approval process is a good example of a timeline that is genuinely not ours to set, and it should be planned as such rather than discovered as a surprise.

Scope arriving quietly. Not big changes, which get discussed and priced. Small ones, one at a time, each perfectly reasonable, none of them re-planned. This is the commonest cause of the polite fiction that a project is nearly done for two months.

What to ask for instead of a single date

• What will I be able to see and use, and when?
• What is in version one and what is explicitly waiting?
• What are you waiting on from me, and by when?
• What is the risk that would move this by a month, and what would it look like early?

An agency that can answer those has planned the work. One that offers a single confident date for everything either has not thought about it or is telling you what you want to hear.

Our answer

We would rather quote a first usable version in weeks and be held to it than quote a finished platform in months and revise it twice. What that looks like for your project depends on what it is, which we can tell you fairly quickly once we have seen it.

If you want a realistic timeline for something specific, tell us what you are trying to build, or see how we work.