16 September 20268 minute read
Most software conversations start in the wrong place. Teams argue about platforms, vendors and features before they have agreed what the business is actually trying to change. Build versus buy is not a technology preference. It is a commercial judgement about where your process is ordinary, and where it is the thing that makes you different.
Buying a proven product is usually faster, cheaper to start and easier to support. Building something of your own takes longer, costs more up front and creates an asset you will have to look after. Both can be the right answer. The costly mistake is treating either as a default.
Buy when the work is standard
If a well-understood product already covers the job, you should use it. Accounting, payroll, email, commodity CRM, standard document storage and common HR administration rarely justify a custom build. You are not going to out-design a mature product in a market where thousands of organisations share the same need.
Off-the-shelf software also wins when the process can flex a little. If your team can adopt a reasonable way of working, the licence fee is almost always lower than the cost of designing, building, testing and maintaining an equivalent system of your own.
Build when the process is the advantage
Bespoke software starts to make sense when the way you serve customers, run operations or handle information is not generic. That might be a quoting method no package supports, a multi-party workflow that spans several systems, a portal that has to match a distinctive service model, or operational rules that a configuration screen cannot express without endless exceptions.
It also makes sense when the current “system” is really a pile of workarounds: spreadsheets passed by email, copy-and-paste between tools, shadow databases, and one person who knows how the month-end actually works. At that point you are already paying for a bespoke process. You are just paying for it in time, error and key-person risk rather than in a designed application.
A hybrid is often the grown-up answer
The useful question is rarely “all buy” or “all build”. Many organisations should buy the commodity layers and build only the distinctive join: the operational application that sits between finance, CRM, operations and the customer. That keeps you from reinventing payroll while still giving teams a system that matches how the business actually runs.
Integration matters here. A standard product that cannot talk to the rest of the estate can become as expensive as a custom build, because people will re-key data to make it usable. Conversely, a small bespoke layer that connects existing tools can remove that cost without replacing everything.
Questions that settle the decision
- Is this process commercially distinctive, or is it work every comparable business does in roughly the same way?
- What does the workaround currently cost in time, rework, delay and missed information?
- Can a standard product be configured to fit, or would you be bending the business around the tool?
- Who owns the data, and what happens if the vendor changes pricing, packaging or direction?
- How often will the process change, and who needs to be able to change it?
- What must still work if a key person is away?
If you cannot answer those questions, you are not ready to choose a stack. You are ready for discovery: map the work, name the outcome, and only then decide whether to buy, build or connect.
