The Spreadsheet Will Not Scale: A Build-or-Buy Framework for UK SME Internal Tools

There is a moment in the life of many growing UK businesses when the operational backbone is a spreadsheet, a shared inbox and the memory of one long-serving member of staff. Everyone knows it is fragile. Someone suggests building a proper internal tool, and a quotation arrives that seems, on the surface, entirely reasonable.

It may well be. But the comparison is usually drawn between the build cost and the subscription fee of a software-as-a-service product, and that is the wrong comparison. The correct comparison is between the full lifetime cost of ownership on both sides. Once that is done honestly, the answer is sometimes to build and often to buy — and the pattern is more predictable than most SMEs expect.

Where the arithmetic goes wrong

The appeal of the in-house build is straightforward. The tool fits the process exactly. There is no per-seat fee that grows with headcount. There is no vendor who might double prices at renewal or discontinue the product. The data stays where the business puts it.

Each of these is a genuine advantage, and none should be dismissed. The difficulty is that the build quotation typically covers construction and launch, while the subscription fee covers construction, launch, hosting, security patching, compliance updates, support and a roadmap — bundled and paid for monthly. Comparing the two headline figures is not a like-for-like exercise, and it flatters the build every time.

Total cost of ownership, line by line

A defensible comparison over five years needs to account for the following on the build side:

• Discovery and specification, which is rarely free even when it is not separately invoiced.
• Development, including the inevitable second and third rounds of change as users discover what they actually need.
• Integration, discussed below, and usually the largest hidden item.
• Hosting and infrastructure, including environments for testing and staging.
• Security patching and dependency updates. Frameworks move quickly; an unmaintained internal tool becomes a liability within eighteen months.
• Accessibility and regulatory adjustments as obligations evolve.
• Support and incident response, including out-of-hours cover if the tool is operationally critical.
• Enhancement, because the business will change and the tool will need to keep up.
• Succession risk, if only one person understands the codebase.

On the buy side, the equivalent list includes licence escalation, implementation and configuration, data migration, integration work, training, contract exit costs and the productivity loss if the product is discontinued or the vendor is acquired.

Integration is the hidden line item

For most SMEs the decisive cost is not the software itself but the connective tissue around it. An internal tool that does not talk to the accounting platform, the CRM and the warehouse system will be abandoned within a year, because someone will end up re-keying data between them.

Buying does not remove this cost. A reputable SaaS product will usually have pre-built connectors for widely used systems, which materially reduces the effort. A bespoke tool will need those connections written from scratch, and every future change to the external system's interface becomes a maintenance task for the business.

Data residency and UK obligations

The build argument often rests on control of data, and that is legitimate. Under UK GDPR, a controller remains accountable for personal data wherever it is processed, and international transfers require appropriate safeguards. SMEs handling sensitive categories — health information, safeguarding records, financial data — will reasonably want a clear view of where their data sits and who can access it.

That said, buying from a supplier with UK or European hosting and a well-documented data processing agreement can satisfy the same requirement. The question is not build versus buy but whether the chosen option can evidence its position. A bespoke tool hosted carelessly is no safer than a SaaS product with a robust contract.

Lock-in cuts both ways

Vendor lock-in is cited constantly in favour of building. Export complexity, proprietary formats and steep renewal increases are real problems. But in-house builds create a different lock-in: to the developer who wrote it, to the agency that maintains it, or to the business's own inability to migrate away because nobody documented the schema. The exit plan deserves equal scrutiny on both sides.

The staffing assumption that breaks the case

This is the assumption that most often undermines a build decision. A custom tool requires a named owner with technical judgement, a route to maintenance, and a budget line that survives the departure of the person who championed it. Many SMEs have none of these, and the tool quietly degrades until it becomes the new spreadsheet.

If the business cannot commit to ongoing ownership — whether through an internal developer, a retained agency or a managed support arrangement — the build case is weak regardless of how well it fits the process.

A simple scoring framework

Score each statement from one to five, where five strongly favours building:

1. The process is genuinely distinctive and confers competitive advantage.
2. No credible product covers at least eighty per cent of the requirement.
3. Integration needs are limited or already well supported.
4. The business can fund and name an ongoing owner for five years.
5. The data is sufficiently sensitive that hosting location is decisive.
6. The expected user base is stable enough to make per-seat pricing unattractive.
7. A phased build with a walk-away point is affordable.

A total below twenty generally points towards buying, or towards configuring a product more thoroughly. Above thirty, a build is worth serious consideration. The middle band calls for a hybrid: buy the commodity, build only the differentiating edge, and integrate the two deliberately.

Where buying usually wins

Scheduling, HR administration, expense management, basic CRM, document approval, helpdesk and bookkeeping are all solved problems. Building them in-house means paying to rebuild something that already exists, while accepting the maintenance burden in exchange for marginal fit. For an SME of thirty people, that is rarely a sound use of capital.

Where building can be justified

The strongest cases share a common shape: the process is the product. A specialist manufacturer with an unusual quality-assurance workflow, a professional services firm whose engagement model differs sharply from the norm, a logistics business with a bespoke routing requirement — these may hold genuine advantage in the way they work, and a bespoke tool can protect it.

Even then, the build should be narrow. Assemble the commodity parts from existing services and write only the code that carries the difference.

A closing caution

The question is not whether custom software is better than off-the-shelf software. It is whether this business, at this size, with these constraints, can carry the lifetime obligation that a build creates. Answer that honestly and the rest of the decision tends to settle itself.