Custom Software vs Off-the-Shelf: How to Actually Decide

The default should be buy. Off-the-shelf software is cheaper, faster, better tested, and maintained by someone else. A company that builds what it could have bought has usually made an expensive decision for a comfortable reason.

But the default isn’t always right, and the way to tell isn’t a feature comparison.

The wrong way to decide

Most build-vs-buy decisions are made by comparing feature lists. It produces bad outcomes in both directions: products win because they list features you’ll never use, or lose because they’re missing one thing you could have worked around.

A better framing: which parts of how you work are your competitive advantage, and which are just how everyone does it?

Bending your process to fit a product is cheap when the process is generic. It’s expensive when the process is why customers choose you.

When buying is clearly right

• Accounting, payroll, email, HR. Regulated, well-understood, universally similar. Building here is close to indefensible.
• CRM for a conventional sales process. If your pipeline looks like everyone’s pipeline, a product will fit.
• Anything where compliance is the hard part. Let someone else keep up with the rules.
• When you have no capacity to maintain software. This is the one people ignore. Custom software is a permanent commitment, not a purchase.

When building starts to make sense

• The process is the product. A logistics business whose routing logic is genuinely better than competitors’. An agency whose delivery method is the reason clients stay.
• Your data is trapped across several systems and nobody trusts the numbers. Sometimes the build is a thin layer that makes existing systems agree — often the highest-return software a business ever commissions.
• Per-seat pricing has become absurd relative to the value. Fifty licences for a tool where your team uses 15% of it is a real number worth comparing against a build.
• The workaround has become the process. Spreadsheets shadowing the official system, exports that get re-imported, one person who "does the thing on Fridays".
• You need something that doesn’t exist. Rare, but it happens, especially in specialised industries.

The costs people miss

Buying: per-seat costs as you grow, integration work to make it fit, data you can’t easily export, price rises you can’t control, and features being removed in a redesign you didn’t ask for.

Building: the build itself is usually the smaller half. Then there’s hosting, monitoring, security updates, dependency upgrades, browser and OS changes, bug fixing, and the fact that every improvement request now comes to you. Budget 15–25% of the build cost per year to keep custom software healthy — permanently.

The hybrid answer, which is usually right

Most good outcomes aren’t pure. They look like:

• buy the commodity systems (accounting, email, CRM);
• build the thin layer that’s specific to you;
• connect them properly so data flows without anyone retyping it.

This gives you the maintenance profile of a small codebase and the capability of a large one. It’s less satisfying than "we built our own platform", and it’s usually the better business decision.

A test you can apply this week

For the process you’re considering building for, answer three questions:

1. Would a competitor doing this exactly our way be at an advantage? If no, buy.
2. Have we tried and failed to make an existing product fit? If you haven’t tried, you’re not ready to decide.
3. Who maintains this in two years? If there’s no answer, buy.

Two clear "build" answers and a named owner for question three means a build is worth scoping. Anything less and you’re better off buying, integrating, and revisiting in a year.

---

We do both sides of this conversation. If you’re weighing it up, tell us about the process — we’ll give you an honest read, including the times we’ve told people not to build anything.