Did You Really Need to Build That? The Honest Guide to Not Reinventing the Wheel on Someone Else's Budget

Let us talk about the notification system.

Not any specific notification system. The archetype of the notification system — the internal tool, the bespoke pipeline, the custom-built piece of infrastructure that a team of three developers spent four months constructing with great care and genuine skill, which does exactly what Twilio, SendGrid, or any one of fourteen other established services does, and which now requires maintenance, monitoring, and the quiet anxiety of knowing that if it falls over on a Saturday night, someone is getting a phone call.

This is not a rare story. In British tech companies of all sizes, it plays out with impressive regularity. And it is worth asking, clearly and without judgement, why.

The 'Not Invented Here' Syndrome Has a Postcode

There is a peculiarly British variant of Not Invented Here syndrome. It does not present as arrogance — British developers are, on the whole, not an arrogant bunch. It presents as caution. As thoroughness. As a reasonable concern about vendor lock-in, data sovereignty, or the long-term cost of a SaaS subscription that might increase in price.

These are legitimate concerns. They are also, in many cases, a sophisticated rationalisation for wanting to build something rather than buy it, because building things is more interesting than configuring things, and because owning your own code feels more professional than depending on someone else's API.

The result is a category of internal software that exists in British companies across every sector: functional, reasonably well-built, solving a problem that was already solved, and consuming engineering time that could have been spent on the thing that actually differentiates the business.

The Beermat Audit in Practice

At Beermat Software, we think about this through a simple lens. Before a line of code is written, the purpose of a new system should fit on a beermat. More specifically: the reason why this cannot be solved by something that already exists should fit on a beermat.

If that reason is 'it's cheaper in the long run', do the maths. Actually do them, on paper, in front of people. Take the developer time required to build, test, and deploy the custom solution. Add the ongoing maintenance burden — patching, monitoring, updating dependencies, fixing the bugs that will inevitably emerge. Add the opportunity cost of those developer hours not being spent on your core product. Now compare that to the annual cost of a SaaS tool.

In a remarkable number of cases, the SaaS tool wins. Sometimes by a factor of ten.

If the reason is 'we need complete control', ask what specific control you need and whether the available tools actually lack it. Data residency is a real concern, particularly post-Brexit, particularly in regulated industries. But 'control' used loosely often means 'we would feel better if we owned it', which is an emotional preference dressed as a technical requirement.

Case Studies in Expensive Self-Sufficiency

A logistics company in the Midlands spent eighteen months building a custom CRM. Their reasoning: they needed specific workflow features that existing tools didn't support. By the time the build was complete, HubSpot had shipped an update that included most of those features. The custom CRM is still running. It is maintained by one developer who is the only person who understands it. When she goes on holiday, nobody touches it and everyone holds their breath.

A financial services firm in Leeds built their own document management system because they were concerned about storing sensitive client data on third-party servers. A reasonable concern. Less reasonable: the system they built has fewer security features than the tools they declined to use, because security tooling is genuinely difficult to build well and the team's expertise was in financial software, not information security. They discovered this during an audit.

A digital agency in Bristol — and this one is almost too painful to recount — built a bespoke project management tool for internal use because none of the existing tools 'quite fit their workflow'. They spent approximately £40,000 in developer time. The tool was used for eight months before the team quietly migrated to Notion.

The Ego Component

It would be dishonest to discuss this phenomenon without mentioning ego. Not personal ego — or not only personal ego — but organisational ego. The sense that a serious technology company should own its own infrastructure, write its own tools, and not depend on the products of other companies.

This is an understandable impulse. It is also, in most cases, economically indefensible. The companies that build the best products are almost universally the ones that are ruthlessly focused on what makes them different, and ruthlessly pragmatic about everything else. They use boring, reliable, off-the-shelf solutions for the commodity parts of their stack, and they reserve their engineering creativity for the problems that nobody else has solved.

Amazon did not build their own office chairs. They buy them from someone who is very good at making chairs, because making chairs is not their competitive advantage.

A Framework for the Genuinely Uncertain

If your team is facing a build-versus-buy decision and you want a structured way through it, try this:

Step one: Define the actual requirement. Not the solution you have in mind — the underlying need. 'We need to send transactional emails' is a requirement. 'We need to build an email delivery system' is already a solution. Strip it back.

Step two: Spend two hours looking for existing solutions. Not a cursory Google. A genuine two-hour exploration of what exists. G2, Product Hunt, direct searches, asking peers. If you cannot find something suitable in two hours, the market probably has not solved this problem, and building starts to make sense.

Step three: Cost both options honestly. Build cost is not just initial development. It is maintenance, monitoring, documentation, and the ongoing opportunity cost of the developer hours required to keep it alive. Be honest about this. Most teams are not.

Step four: Ask who else has this problem. If thousands of other companies face the same challenge, someone has probably built a good solution. The existence of a thriving SaaS market in a given category is evidence that the problem is solved. Trust the market, at least enough to investigate it properly.

Step five: Make the decision explicit. Write down why you are building rather than buying. Not to justify it — to test whether the reasoning holds up when articulated clearly. If it fits on a beermat and makes sense, proceed. If it takes three paragraphs and several caveats, reconsider.

The Honest Conclusion

Custom software is sometimes the right answer. For genuinely novel problems, for highly specific regulatory requirements, for core product functionality that constitutes actual competitive advantage — build. Build carefully, build well, and own what you build.

For everything else: there is almost certainly a tool. It probably costs less than you think. It is probably better than what you would build in the time available. And the engineering hours you save can go toward the thing that actually makes your company worth using.

The beermat is small on purpose. It forces clarity. If your justification for a custom build does not fit on one, it is worth asking whether the justification is actually there.