Build or buy: when custom software beats off-the-shelf

“Should we build it or buy it?” is one of the most common questions in business technology, and the honest answer is usually “it depends”. The useful part is knowing what it depends on. Here is a straightforward way to think it through.

Start with what makes your business different

Buy the things every business needs. Build the things that make you different.

Payroll, email and accounting are the same for almost everyone, and there are mature products for them. If a process is part of how you win customers or run uniquely well, an off-the-shelf product forces you to work like everyone else.

Seven questions to ask

1. Is this a competitive advantage or a commodity? Commodities are usually better bought.
2. How closely does a product fit? If a product does most of what you need out of the box, that is a strong reason to buy. If you would be bending your process to suit it, or bolting on workarounds, that is a warning sign.
3. How much integration is involved? Connecting a product to your other systems can cost as much as building. Ask for the true integration effort, not just the licence price.
4. What does it cost over three to five years? Compare the full picture: licences that grow with your headcount, customisation, integration, support and upgrades against the build cost, hosting and maintenance.
5. How often will it need to change? If your needs shift regularly, owning the software gives you control. If vendors change pricing, features or terms, you carry that risk.
6. Who owns the data and the logic? Make sure you can get your data out in a usable form, whichever route you choose.
7. How fast do you need it? Buying is usually quicker to start. A well-scoped first version of custom software can be faster than people expect, but be honest about the timeline.

The hybrid approach often wins

Many organisations do best by combining both:

• Buy the commodity pieces, such as identity, payments, email and accounting.
• Build the part that is specific to you, such as a customer portal, a workflow or an integration layer that ties the products together.

This keeps the build small, so it is cheaper, quicker and easier to maintain.

Warning signs

On the buy side:

• Lots of “customisation” to make it fit.
• You are paying for modules you will never use.
• Getting your data out is difficult.

On the build side:

• No one owns the product after launch.
• The scope keeps growing before anything has shipped.
• You are building something a product already does well.

How to reduce the risk of building

• Start with the smallest useful version. Release something real to a few users, learn from it, then extend it.
• Own the plan for after launch. Software needs updates, fixes and security patches. Decide who does that, and what it costs, before you start.
• Document it and keep the code in your control. Make sure you could change suppliers if you needed to.
• Measure what matters. Agree upfront how you will know it has worked.

A quick way to decide

If a good product covers around 80% of what you need and the rest is minor, buy it. If the thing you need is central to how you compete, or no product comes close, building is worth serious consideration. If it is in between, buy the foundation and build the part that is yours.

If you are stuck between the two, a short discovery conversation usually settles it. We would rather tell you to buy a product than build something you do not need.