How long does it take to build bespoke software?

"How much?" is the first question. "How long?" is the second, and it is usually the one that decides whether a project happens this year or next.

The unhelpful answer is that it depends. The useful answer is that it depends on a small number of things you can work out in advance, most of which are about your business rather than about the code.

Indicative timescales

These are broad ranges for planning, not a quote. The actual timeline goes in the written proposal, after the scope is agreed, and it is specific to your project.

A single process system, roughly £15k to £25k. Replacing one spreadsheet or one workflow. Typically a couple of months from agreed scope to live, sometimes less where the process is well understood and the data is clean.

A multi-user system with integrations, roughly £25k to £40k. Several roles, a connection to the accounts package, migration from whatever you run now. Typically three to five months, with parts of it in real use well before the end.

A full operational platform, £40k to £60k and up. Several connected workflows, often a portal for customers or suppliers. Five months and up, and always delivered in stages, because nobody should wait that long to see anything.

The price bands and what pushes a project between them are set out on the bespoke software development page, and if you want the mechanics rather than our rates, our guide to what bespoke software costs covers what drives a quote, the pricing models and the ongoing costs most proposals leave out.

What the time is actually spent on

Very little of it is typing code, which is the part most people picture.

Understanding the process properly. Usually a week or two of the calendar, and the highest value part of the project. What people describe in a meeting and what they do on a Tuesday afternoon are different, and the difference is where the exceptions live. Every business has a "we normally do it this way, except when..." and the exceptions are what make software either useful or infuriating.

Data. Consistently the most underestimated item. Ten years of records in a spreadsheet or an old system will contain duplicates, three spellings of the same customer, dates typed as text, and rows somebody used as a note. It all has to be cleaned and mapped before it moves. On projects that involve replacing a legacy system this is often the single biggest task.

Integrations. Connecting to Xero, Sage or QuickBooks is routine. Connecting to a niche industry product with no documented API is not, and the honest answer is that we find out early and tell you which one you have.

Your team's time. The part nobody puts in the plan. You need people to answer questions, look at what has been built, and say when it is wrong. A day here and there, at the right moments. Projects slip far more often because a decision sat waiting for a fortnight than because the build was slow.

Testing with real people and real data. Not a formality. It is where the last round of "that is not quite how we do it" surfaces, and it needs to happen before go live rather than after.

Why we build in stages

Six months of silence followed by a big reveal is how software projects fail. Everybody agrees the specification, everybody imagines something slightly different, and the gap only becomes visible at the end when it is expensive.

Building in stages means you see working software early and steer it. The first release usually does the single most painful thing in the process and nothing else. It goes into real use, people find the things nobody thought to mention, and the next stage is better for it.

The practical consequence is worth stating clearly: the date the project finishes is not the date you start getting value. On a five month build you should be using part of it in month two. When you are weighing up the cost of waiting, that is the number that matters.

What makes a project run long

In rough order of how often we see it.

The scope grows. Not through anybody's fault. You see the system working and think of three more things it could do, all of them good ideas. The way to handle that is not to refuse, it is to be explicit: what is in this stage, what goes on the list for later, and what each addition does to the date. Vague changes are what wreck timelines, not changes.

Decisions wait. A question that needs an owner's answer sits for two weeks, and two weeks come off the end of the project.

The data was worse than anyone thought. Very common, and largely avoidable: get an export of what you have looked at early, before the schedule is set.

A third party is slow. Waiting on someone else's API credentials, or on a supplier who has no commercial interest in helping you migrate away from them. Start those conversations at the beginning.

The process itself was not settled. If the business is still arguing about how the work should be done, software will not settle it. Sort the process, then build.

How to make it faster, honestly

• Pick one process to start with. The narrower the first release, the sooner it is live and the sooner it is paying for itself.
• Nominate one decision maker. Someone who can say yes without convening a meeting.
• Get your data out early. Even a rough export tells us what we are dealing with.
• Be honest about the exceptions up front. The awkward cases you were hoping to gloss over will surface anyway, just later and more expensively.
• Leave the nice to haves for stage two. They are usually easier once the core is live, and by then you will have changed your mind about half of them.

Where the clock actually starts

Not at the first phone call. The sequence is a free 60 minute process audit, usually on site, then a written proposal with the scope, the price band and the timeline in it. The build starts when you agree that.

The audit itself is a single session, and the proposal follows shortly after. If you have a deadline you are working back from, a season, an audit, a contract renewal or a system going out of support, say so at the start. It changes what we recommend building first, and occasionally it changes whether we recommend building at all.

If you want an indicative timeline for something specific, tell us the process you want to fix. We will give you a straight answer, including whether it is achievable in the window you have.