Custom software vs off-the-shelf: how to decide

Build or buy is usually argued on licence cost, which is the least informative number available. The real comparison is total cost of ownership over several years, and it includes things that never appear on a quotation: the hours your team spends working around the system, the integrations you pay to maintain, and the deals you cannot support because the software will not model them.

Here is a way to make that comparison honestly.

Start by assuming you should buy

For anything that is not specific to your business, packaged software wins on almost every axis. Accounting, payroll, email, helpdesk, document storage — these are solved problems with mature products, and building your own means funding a permanent maintenance obligation for no competitive gain.

A good rule: if a process is one your competitors run identically, buy it. If a competitor could copy your process and gain nothing, buy it. The only processes worth building are the ones where doing it your way is part of why customers choose you.

The signals that buying has stopped working

Packaged software fails gradually, and the symptoms are operational rather than technical:

• Shadow spreadsheets. A parallel system exists because the real one cannot represent something important. This is the clearest signal available.
• Manual re-keying. Staff copy data between systems because the integration does not exist or does not cover the fields that matter.
• Process distortion. You have changed how you work to fit the software, in a way that costs you money or customers.
• Licence sprawl. You are paying per seat for a large product to use a small part of it, and the cost scales with headcount rather than value.
• Blocked opportunities. A pricing model, service or market is out of reach because the system cannot express it.

One of these is normal. Three or more, sustained, usually means the workaround cost has passed the build cost.

The costs both sides hide

What buying hides

• Implementation and configuration, frequently a multiple of the first-year licence.
• Integration development and its ongoing maintenance as vendor APIs change.
• Per-seat costs that grow with the company rather than with the value delivered.
• Migration cost if you ever leave — often the largest number and the least discussed.

What building hides

• Maintenance. Software needs security updates and dependency upgrades whether or not you add features.
• The unglamorous 20%: permissions, audit trails, exports, admin screens, error handling. It is most of the work.
• Knowledge concentration. If one person understands the system, you have a risk, not an asset.
• Opportunity cost of the internal time spent specifying and testing it.

The answer is usually hybrid

In practice the strongest architecture is rarely all-or-nothing. Buy the commodity systems — accounting, payroll, communications — and build only the layer that encodes how you actually operate, integrating the two through APIs.

A distributor might keep a standard accounting package and build a custom quotation and inventory system on top of it, because the quotation logic is where their margin is made. That is a far better position than either a fully custom ERP or a packaged one that fights them daily.

If you build, make it safe to own

• You own the code and the infrastructure. Repository and cloud accounts in your name, so you can change supplier without changing systems.
• Conventional technology choices. Mainstream languages and frameworks mean the next engineer is findable.
• Documentation as a deliverable. Architecture, data model and runbooks, written down rather than resident in one head.
• Delivered in working increments. Each phase should leave you with something usable, so the project can be paused without leaving nothing.

These conditions are what turn a custom build from a dependency into an asset.

A short decision test

Total the hours your team currently spends on the workarounds, multiply by loaded cost, and project it over three years. Compare that with a build estimate plus realistic ongoing maintenance. If the workaround cost is clearly larger, building is the cheaper option — and if it is close, buy, because certainty has value.

Our web applications service page describes how we scope and deliver this kind of system.