Skip to content
Atomberg

Strategy

Buy vs build: a decision framework for mid-sized businesses

28 April 2026 · 6 min read

Short answer

Buy for processes that are identical across your industry — accounting, payroll, email, payments. Build for the process your margin depends on, where packaged tools force you to change how you operate or add manual work around them. Most mid-sized operators should run a hybrid: a custom operational core for the differentiated workflow, integrated with bought tools for everything commoditised.

The wrong question

'Is there software that does this?' is almost always yes, and almost never decisive. The useful question is: what does adopting this tool require us to stop doing, and is that thing part of why customers choose us?

Signals you should buy

  • The process is legally or financially standardised (bookkeeping, VAT, payroll)
  • Your requirements read like the vendor's feature list with no exceptions
  • The tool's per-seat cost stays small relative to the value of the work it handles
  • Nobody in the business has a strong opinion about how the process should run

Signals you should build

  • Staff maintain spreadsheets to work around a tool you already pay for
  • The same data is typed into two or more systems
  • Your quoting, configuration, or fulfilment logic is unusual for your sector — and profitable
  • Reporting takes a person a day, or answers arrive too late to act on
  • Growth (a second site, a bigger customer) is blocked by admin capacity rather than demand

Running a hybrid properly

A hybrid fails when nobody decides which system is authoritative for each piece of data. Name the source of truth per entity — customers here, invoices there, stock in the custom core — and make every integration one-directional from that source. Two systems both allowed to edit the same record is how reconciliation work is invented.

For Burin Boats we built the storefront and the operational layer around it rather than replacing every tool the business used, which is the usual shape: custom where the commercial logic lives, bought where it does not.

How to de-risk a build decision

Do not commit to a platform to test an assumption. Take the single most expensive manual process, build it end to end as a fixed-scope pilot, and measure the time it removes. If the pilot pays back, the platform case makes itself. If it does not, you have spent weeks instead of quarters finding out.

Written by the Atomberg team, based on systems we build and run for European operators. See client work.

Related questions

Questions this raises

Is custom software risky for a small business?
The risk is scope, not technology. Phased delivery with a working output in the first weeks keeps the exposure small: you can stop after any phase and still have a system in production.
What happens if we outgrow the people who built it?
You should be able to leave. Ownership of the code, the data, and the infrastructure sits with the client, standard technologies are used deliberately so another team can pick it up, and handover documentation is part of delivery.

Client enquiry

Tell us what is slowing the business down.

Send the problem, not a specification. We will tell you what kind of system solves it, what it involves, and whether we are the right partner for it.