When Custom Software Is the Wrong Answer

The Warning Signs

Certain patterns reliably predict that a custom build will not deliver value. Some relate to timing, some to budget, some to the nature of the problem itself. If you recognise several of these in your own situation, that is useful information.

None of these warning signs are permanent. They describe situations where the timing or the conditions are wrong, not where custom software is inherently a bad idea. The distinction matters.

The problem beneath the problem

If you put software on top of a broken process, you get a faster broken process. The errors happen more quickly. The confusion becomes harder to unpick because now it is encoded in code rather than in habits.

If most of your problems sit in the right column, process mapping and some honest internal conversations will do more good than a custom build. Once the process is clear, the technology decision becomes straightforward.

What to Do Instead

Deciding not to build does not mean doing nothing. There are usually better options for where the business is right now. Each of these has a place, and none of them prevents you from building custom software later when the conditions are right.

The common thread is proportionality. Match the size of the intervention to the size of the problem. A £40,000 custom build for a problem that a £200 per month SaaS subscription or a week of process mapping would solve is not a good use of money, however well the software is built.

Choosing the right SaaS by use case

The generic advice to "use SaaS" is not particularly helpful unless you know what to look for. Here is a more specific breakdown of where existing products handle things well, and what to prioritise when evaluating them.

The point is not to endorse any particular product. Products change, pricing shifts, and what suits one business may not suit another. The point is that for each of these use cases, there are products with years of development behind them, active support teams, and thousands of existing users surfacing bugs you would otherwise discover the hard way. Build custom only when these options genuinely fall short for your specific needs.

Consider an MVP before a full build

If you are genuinely unsure whether custom software will solve the problem, there is a middle ground. A minimum viable product (MVP) lets you test the core idea with real users at a fraction of the full cost. Build the small set of functionality that addresses the biggest pain point. Use it for three months. If it proves its value, expand. If it does not, you have spent a modest amount learning something important rather than committing the full budget to discover the same thing too late.

The MVP approach works best when you can define one specific workflow or bottleneck to address. It works poorly when the scope is vague or the problem is not well understood, which brings us back to process maturity.

The Real Cost of Owning Custom Software

One of the most common mistakes in this decision is treating a custom build as a one-off cost. The development fee is the largest single payment, but it is not the total cost of ownership.

A £40,000 build, then, is realistically a £50,000 to £55,000 first-year commitment, followed by £6,000 to £10,000 per year in ongoing costs. That investment pays for itself when the software addresses a genuine, quantifiable problem. It does not pay for itself when the problem is vague, the processes are unstable, or a £50 per month SaaS subscription would do the job.

The Traps That Lead to Bad Builds

Even when the conditions are broadly right for custom software, there are patterns of thinking that lead businesses into builds they later regret. Recognising them early saves significant money.

The sunk cost trap

"We have already spent £15,000 on this direction, so we need to keep going." No, you do not. The money already spent is gone regardless. The only question that matters is whether spending more will produce something worth having. If the answer is no, stopping is the right decision, even though it feels like admitting failure. It is not failure. It is good judgement.

The "just one more feature" trap

The initial scope is sensible. Then someone suggests adding a client portal. Then automated reporting. Then a mobile app. Each addition seems small and reasonable on its own. Collectively, they double the budget and triple the timeline. This is scope creep disguised as reasonable requests, and it is the single most common reason projects exceed their budget. A proper discovery phase helps prevent this by forcing hard decisions about scope before the build begins.

The "our process is unique" trap

Every business thinks its processes are unique. Most are largely the same as their competitors. The genuinely distinctive parts are where custom software earns its place. The rest should use off-the-shelf tools. Overestimating your uniqueness leads to building what could be bought, which is expensive and slow. Before commissioning a custom build, write down the specific parts of your process that no existing product handles. If the list is short, you probably do not need custom software. If it is long and specific, you might.

The technology enthusiasm trap

Sometimes the push to build comes from someone in the team who is excited about technology rather than from a genuine business need. The brief sounds like "it would be cool if we had a system that..." rather than "we are losing money because..." Cool is not a business case. The pressure to build should come from a quantifiable problem, not from enthusiasm for the idea of having bespoke software.

The vendor pressure trap

Be cautious of any agency or consultancy that recommends building in every conversation. A company that profits from development has a structural incentive to recommend development. This is not necessarily dishonest. It is just how incentives work. The same dynamic exists in any profession where the adviser also sells the service: accountants recommending complex structures, architects recommending extensions, mechanics recommending repairs.

Protect yourself by separating the advice from the sale where possible. Get an independent assessment of whether you need custom software before engaging the company that would build it. Ask the consultancy what percentage of their discovery conversations end with a recommendation not to build. If the answer is close to zero, their discovery process may not be as impartial as it appears. A good consultancy will sometimes tell you not to build, because the alternative is building something that fails and damaging the relationship.

When to Revisit the Decision

The decision not to build is not permanent. Businesses change. Processes stabilise. Budgets grow. What was wrong last year might be exactly right this year.

The following checklist works as a reusable decision framework. Come back to it every six to twelve months, or whenever your situation changes significantly. When the majority of these statements are true, the conditions for a successful custom build are likely in place.

• ✓
  Your processes have been stable for six months or more You can describe your core workflows clearly and specifically. The team agrees on how things should work. You could write a requirements document without needing to resolve internal disagreements about how the process should run, because those disagreements have already been settled through practice.
• ✓
  You can quantify the cost of the current setup Track the hours. If your team is spending more than 10 hours a week on manual workarounds across your tools, the cost of the current setup is becoming significant. Multiply those hours by average hourly cost and add the cost of errors caused by manual processes. When the annual workaround cost approaches the cost of building, the maths starts to favour custom development.
• ✓
  You can budget for the full lifecycle Not just the build, but the ongoing maintenance, hosting, and support. As a rough test: can you commit to 15% of the build cost per year for at least three years after launch, plus a 20% contingency on the initial budget? If yes, the investment is sustainable. If that figure makes you uncomfortable, it is worth waiting until it does not.
• ✓
  SaaS friction is compounding Per-seat pricing is growing with your team. You are paying for multiple tools that do not talk to each other. The gap between what you need and what the tools provide is widening, not narrowing. You may also be feeling the effects of vendor lock-in, where switching costs make it harder to leave with each passing year. If you are spending more than £1,000 per month on SaaS tools that still require significant manual workarounds, the economics of custom development start to look different.
• ✓
  You have outgrown the alternatives The Airtable base that worked for a small team is buckling under complex relationships, layered automations, and views that take seconds to load. The Zapier automations are hitting limits. The low-code tool cannot handle the complexity your operations now require. This is a good problem to have, because it means you validated your needs before investing in a full build.
• ✓
  You can identify the specific workflows that need to be custom Not "we need a system," but "we need automated job allocation based on engineer certifications and geographic proximity" or "we need a quoting tool that pulls live supplier pricing and calculates margins." The more specific you can be about what no existing product handles, the stronger the case for building.
• ✓
  Your team is ready to engage with the build Custom software requires input from the people who will use it. If your team has the capacity to participate in discovery, review prototypes, and test iterations, the project has a much higher chance of delivering something that actually works. If the team is already stretched thin and cannot dedicate time to the process, even a well-built system will struggle to land properly.

When the score is high enough, the next step is a proper discovery phase. This is a structured process (typically two to four weeks) where you define the scope, validate the requirements, and get a realistic cost estimate before committing to a full build. The build vs buy framework provides a structured way to work through the decision itself.

Making the Decision Well

The fear of wasting a significant sum on something you cannot see or touch yet is real. So is the anxiety about being pushed into a project by someone who profits from building it. Both fears are reasonable, and both can be managed with the right preparation.

Custom software is a significant investment. For the right business at the right time, it pays for itself and keeps paying. For the wrong business at the wrong time, it is an expensive lesson. It is well documented across the industry that a significant proportion of software projects fail to deliver their intended value. Most of those failures trace back to the same causes: unclear requirements, unstable processes, and unrealistic budgets.

The difference is rarely about the software itself. It is about readiness. Three things predict success more reliably than anything else:

Businesses that get these three things right tend to have successful projects. Businesses that skip them tend to have expensive regrets. If you are considering scaling your operations and wondering whether custom software is part of the answer, use the framework on this page to test your readiness before you engage any consultancy.