Custom Software Development: What It Costs and When It Pays

Custom software development is the design and build of an application around one organisation's own processes, data and language, rather than configuring a product sold to many. In the UK it runs from a few thousand pounds for scoping to several hundred thousand for a production system, and whether it pays depends less on the technology than on whether the process it encodes is genuinely yours.

Here is a scene most operations directors will recognise. The team has a tool. The tool does most of what they need, so every day they do the rest in a spreadsheet beside it, with a shared document of workarounds that newcomers are handed on their first morning. Nobody chose this arrangement. It grew, one sensible compromise at a time, until the "system" is really three systems and a person who knows how they fit together. That person is the most expensive piece of software in the building, and she is the reason custom software development comes up at all.

The question is never "custom or off-the-shelf?" in the abstract. It is whether the process your team runs is distinctive enough that bending it to a generic product costs more than building something shaped to it. In this guide, Elliott Prince, Managing Director at Ferrous Labs, sets out what custom software development actually costs in the UK, when it beats the off-the-shelf option and when it does not, how long a build takes, and how to scope one so the money goes on the part that pays.

What you are actually buying

It helps to be clear about the product first, because "custom software" covers everything from a one-page internal form to a platform with a thousand users. In the work we do, it most often means a standalone application shaped around how an operational team actually works: an internal copilot that answers questions from the company's own knowledge, a decision-support dashboard that puts a recommendation next to the data behind it, an intelligent workflow tool, or a client-facing portal. Increasingly it means software with AI built into the workflow rather than bolted on afterwards, so the tool reads the document, drafts the answer or flags the exception rather than waiting for a person to.

What you are buying, in other words, is your own expertise, codified. The knowledge that currently lives in the heads of two or three senior people becomes something the whole team opens every day. That framing matters when you come to cost it, because it tells you where the value is: not in the number of features, but in how much senior time the tool gives back and how many decisions it makes consistent.

What does custom software development cost in the UK?

Let's deal with the number everyone wants first, and be honest that it is a range. Custom AI development in the UK typically starts at £5,000 to £20,000 for a scoping engagement, rises to £20,000 to £80,000 for a validated pilot or minimum viable product, and runs from £80,000 to £300,000 or more for a full production system with integration. Those are our working ranges, and the width is not evasion; it reflects the fact that the same capability can be a small build or a large one depending on how many systems it touches and how messy the data is.

The public numbers show the same spread. The Department for Science, Innovation and Technology's AI Adoption Research, conducted by IFF Research and Technopolis Group across 3,500 UK businesses in spring 2025, found that businesses using or planning to use AI spent a mean of £19,000 on it in 2024, against a median of just £2,000. When the mean is nearly ten times the median, the average is describing a handful of large programmes rather than anyone's actual situation, and the useful lesson is that most businesses are spending very little, which usually means subscriptions rather than builds.

For comparison, off-the-shelf AI (Microsoft Copilot, ChatGPT Teams and the like) costs £20 to £50 per user per month and gives you a general-purpose capability that knows nothing about your processes. That is often exactly the right purchase. The mistake is comparing its monthly fee to a build's one-off cost as if they bought the same thing. Our post on how much custom AI development costs in the UK works through how to turn the unknown into a number for your own case.

When custom beats off-the-shelf, and when it does not

Which leads us to the decision itself. Off-the-shelf wins when the process is generic: accounting, CRM, email, calendars, the things every business does roughly the same way. Nobody should build those, and the vendors have spent more on them than you ever will. Custom wins when the process is yours: the way your surveyors structure a report, the rules your underwriters apply, the taxonomy your documents follow, the questions your clients ask that no generic assistant has the context to answer. If the tool keeps making your team work its way, and your way is where your margin comes from, that is the signal.

There is a third case that catches people out, which is the process that looks generic but is not. Document review is the classic example. Every business reviews documents; very few review the same documents against the same rules. A property-tech business we worked with had thousands of legal documents and a manual review process that could not keep up. The build was not "document AI" in general but a pipeline of domain-specific models, built and benchmarked against the cloud providers' offerings before committing, that took review from hours to under a minute per document. The generic tool would have handled the easy third of those documents and left the expensive two-thirds exactly where they were.

How long does a build take?

For the kind of application described above, a typical build runs eight to twelve weeks from kick-off to a working tool in the team's hands. The timeline depends on integration complexity and the state of the data far more than on the feature list, which is why the first fortnight is spent analysing the workflow with the people who do it rather than writing code, and why the team tries a prototype before the production build begins. A tool the team has already used in rough form is a tool they will open when it is finished; a tool revealed at the end is a tool they will route around.

Critically, "finished" is the wrong word anyway. Software the team opens every day changes as their needs change, and a build that stops at handover starts decaying on the day it is delivered. Maintenance is part of the engagement or it is a problem you have deferred, not avoided.

How to scope it so the money goes on the part that pays

Most of the money wasted on custom software is wasted before the build, in a scope that encodes the wrong thing. Our piece on why workflow design comes first in custom AI software makes the case in detail; the short version is that you should be able to describe, before anyone quotes, exactly which step in which process the software will take over, who reviews its output, and what happens when it is wrong. If that description does not exist, the quote is a guess, and the build will discover the real requirements at the most expensive possible moment.

The practical sequence is short. Name the number the tool should move: hours of senior time per week, days to turn a document round, errors per hundred cases. Map the process and mark which steps follow rules and which need judgement, because the rule-following steps are the ones worth building for. Check the data the tool will run on, as it actually arrives rather than as the demo showed it. Then scope the smallest build that moves the number, and let the result fund the next one. That is the shape of our Custom Software Sprint, and it is the shape of the builds that get used rather than shelved.

Start with the workaround everyone knows about

You may be reading this with a budget that would not stretch to a production system and a team that is coping, more or less, with the tools they have. That is fine; coping is not the same as working well, and the first build does not need to be the big one. Start with the workaround everyone in the team knows about and nobody has fixed, because it is the clearest evidence you have of a process that is yours. Put a number on what it costs in senior time. Scope the smallest tool that would make it go away.

Done that way, custom software stops being a leap and becomes a series of small, provable improvements, each one paid for by the last. The businesses that get real value from it are not the ones with the biggest budgets; they are the ones who knew which part of their work was worth encoding, and built only that.