The honest answer to "should we build custom software?" is: sometimes. Building when you should have bought wastes money and time; buying when you should have built quietly caps how well your business can run. The trick is knowing which situation you are in — and most teams decide by default rather than on the merits.
Here is the framework we use with clients, including the cases where we tell people not to build.
Buy when the process is a commodity
If a process works the same way at thousands of companies — email, accounting, payroll, general CRM — a packaged product has already solved it better and cheaper than you can. Building your own is almost always a mistake here. The market has amortized the cost across every customer; you would be paying full price to reinvent it.
The tell: if you cannot describe how your version of the process is a competitive advantage, it is a commodity. Buy it.
Build when the software IS the operation
The opposite is true when the software encodes how your business actually competes — the specific way you take orders across channels, manage inventory, price, fulfill, and reconcile. Packaged tools force you to bend your operation to their model, and the gaps get filled by people copying data between systems. That manual glue becomes the ceiling on how fast you can grow.
When the process is your edge, custom software is what lets you run it as one connected system instead of a patchwork. This is the case where building pays for itself, often many times over.
The hidden cost of "buy" is integration
Buying rarely means buying one thing. It means buying five things that were never designed to talk to each other, and then paying — in salaries and errors — for the humans who move data between them. When people evaluate build-vs-buy, they compare the license cost of the tool to the build cost of custom software and forget the ongoing operational tax of the gaps.
A useful exercise: add up the hours your team spends re-keying and reconciling between systems each week, and annualize it. That number is often larger than anyone expects, and it does not shrink as you grow — it grows with you.
A simple decision test
Run the candidate process through four questions:
- Is this process a source of competitive advantage, or a commodity? (Advantage → lean build; commodity → lean buy.)
- Does an off-the-shelf tool fit without heavy customization? (Heavy customization erodes the "buy" savings fast.)
- How much manual work sits in the gaps between our current tools? (High → integration or a platform pays off.)
- Will this need to scale or change in ways a packaged product will not follow? (Yes → build for control.)
The pragmatic answer is usually a mix
The best architecture is rarely all-custom or all-bought. Buy the commodities (email, accounting, payments), build the parts that are your operation, and invest in the integration that makes them behave as one system. We recommend build-vs-buy honestly per capability — custom where it creates advantage, proven tools where it does not — because our incentive is a system that works, not a bigger build.