Buy, build or integrate? A framework for custom software decisions

“Just buy something off the shelf” is good advice right up until it isn’t. Whether it’s right for you comes down to one thing: how central the process is to the way you actually run.

The advice gets repeated so confidently because it’s the correct answer most of the time, and because everyone has heard a horror story about a custom build that ran over budget and died. Both things are true. What the advice skips is the other horror story, the one that unfolds slower and never makes it into a cautionary tale: the business that bought off the shelf for everything, bent its operations around six different tools’ assumptions, and ten years later runs the way its software vendors decided it should, with its original edge sanded off and a monthly subscription bill that would service a decent loan.

The test: is this your edge?

If a process is generic, buy it. Payroll, email, accounting. Someone has already built a better version of those than you ever will, and rolling your own would just be a maintenance bill you signed up for on purpose. The calculation flips when a process is your edge, the thing you do differently and do well. Bend that to fit someone else’s software and you can quietly file off the exact advantage you were trying to protect.

The test is worth running properly rather than by gut feel, because “our edge” is a phrase every owner applies to more of the business than deserves it. Ask it this way: if a competitor could see exactly how this process works, would it cost us anything? Your leave-request workflow, no. Your invoicing, almost certainly no. But the way a freight company prices multi-leg jobs, the way an equipment hire firm juggles allocations across depots, the way an agronomy business turns paddock data into recommendations, those are the processes customers actually choose you for. A business usually has two or three of them, not fifteen. Everything else is plumbing, and plumbing should be bought.

There’s a second part to the test that gets skipped: how bad is the fit? A core process with a 95% off-the-shelf fit should still probably be bought, because the last 5% might be a workaround you can live with. A core process with a 60% fit is a different animal. That missing 40% becomes spreadsheets on the side, double entry, staff who spend their day translating between how the business works and how the software insists it works. Fit problems on peripheral processes are annoyances. Fit problems on core processes are a tax on every single job you run.

Three options, plainly

Buy when the need is common and the fit is good. It’s the fastest and cheapest path, and the one where you own the least. Buying well is its own skill: pick the boring market leader over the exciting newcomer for anything that holds your data, check the export options before you sign rather than after, and read what happens to your pricing at the next tier, because per-seat pricing quietly taxes your growth. The goal is a tool you could leave, even if you never do.

Integrate when you’ve already got several decent tools that won’t talk to each other. A lot of the time the smartest move isn’t replacing any of them, it’s wiring up what you already have so the data stops getting re-typed between systems. This is the most underrated option of the three, and the one vendors will never suggest, because there’s no licence to sell in it. If your accounting package, your CRM and your job management tool are all individually fine and the pain is a person spending Friday copying between them, the problem is the gaps, not the tools. Integration projects are typically a fraction of a rebuild’s cost, they keep the systems staff already know, and they’re where connecting Xero, your CRM and operations pays off fastest.

Build when the process is core, the off-the-shelf fit is poor, and owning the thing matters. It’s more work up front. In return you own the code and you own the roadmap: the software changes when your business changes, not when a vendor’s product committee gets around to it, and no one can retire it, triple its price, or acquire-and-abandon it out from under you.

Run the numbers over five years, not one

The trap people fall into is assuming buy is always the cheaper option. It often isn’t, once you add up the workarounds, the data someone keys in twice, and the process you quietly reshaped to suit the tool instead of the other way round.

Make the comparison honest by putting the hidden column on paper. Take a 20-person business looking at a job management tool at $90 per user per month. That’s about $22,000 a year, $110,000 over five, before the annual price rises that always come. If the fit is good, that’s likely still the right buy, because a custom build of the same scope would cost more and take longer. But now add the fit tax where the fit is poor: two admin staff spending an hour a day each on workarounds and re-keying is roughly $25,000 a year in wages doing work the software was supposed to remove. Suddenly the five-year cost of “cheap” off-the-shelf is north of $200,000, against a custom build that might land between $80,000 and $150,000 up front plus a maintenance retainer, and the custom option fits how you actually operate. Sometimes the sums still favour buying. The point is that you did the sum, over the realistic horizon, with the workaround column filled in.

The same honesty applies in reverse. A custom build carries costs the quote doesn’t show either: hosting, security patching, someone to call when it breaks, and the discipline to keep maintaining software that never stops needing it. If you’re not prepared to fund the thing’s ongoing life, don’t build it. An owned system nobody maintains ends up worse than a rented one somebody else maintains.

One more line for the hidden column: what the tool does to your process over time. Off-the-shelf software carries opinions about how work should flow, and a poor-fit tool doesn’t just cost workaround hours, it slowly retrains the business to work the tool’s way. Five years in, staff describe the software’s process as “how we do things”, and the original edge, the faster turnaround, the flexible terms, the odd job nobody else would take, has been quietly standardised away. That erosion never appears on an invoice, which is exactly why it needs a line in the comparison.

The hybrid most businesses actually land on

In practice the decision is rarely all-or-nothing, and the best answer for most established businesses is a deliberate mix: buy the plumbing, integrate the gaps, and build only the narrow piece that’s actually yours. The freight company keeps Xero and its telematics platform and builds just the pricing engine. The hire firm keeps its accounting and website and builds the allocation system, connected to both. You’re not choosing a philosophy. You’re making a separate buy-build-integrate call per process, and the discipline is refusing to rebuild solved problems while also refusing to rent your edge.

A decent way to start is an hour with a whiteboard: list your processes, mark which two or three are the edge, mark where the fit hurts today, and see which quadrant each lands in. Redo the exercise every couple of years, because the answers drift: a process that was peripheral becomes the edge, a product that fit well gets acquired and stagnates, and yesterday’s correct buy becomes tomorrow’s correct build. If you’d like a second opinion on the map, bring us the process list and the current tool stack and we’ll tell you plainly which things to buy, which gaps to wire up, and whether anything on the list actually justifies a build, including when the answer is that nothing does.