Custom software vs off-the-shelf

The two costs arrive on different schedules

An off-the-shelf product has a low entry cost and a permanent one: licences per seat per year, rising as you grow, plus the integration work to make it fit and redo when it updates. Custom software has a high entry cost and a low tail: maintenance and change, both proportional to how much the operation moves.

That difference is why comparisons made at month three almost always favour buying and comparisons made at year five often do not. Neither is wrong; they are measuring different windows.

The practical fix is to pick a horizon before comparing. Five years is a reasonable default for an operational system, and shorter than the life most of them actually reach.

Where buying clearly wins

Standard functions that every company performs the same way should be bought, always. Payroll, accounting, email, document storage, video calls: there is no version of these where a custom build repays its cost, and building one is a common way to spend a year of engineering on a solved problem.

Buying also wins when the process is genuinely stable. If the way you do something has not changed in five years and you cannot describe a reason it would, a product that does 80% of it and configuration for the rest is the cheaper answer over any horizon.

And it wins under regulatory load in commodity areas. A product whose vendor maintains compliance for thousands of customers is absorbing an ongoing cost that you would otherwise carry alone.

Where building clearly wins

Build when the process is the competitive advantage. If how you route, price, schedule or decide is why customers choose you, then encoding it in someone else’s product means either flattening it into their model or maintaining an ever-growing pile of workarounds.

Build when the workarounds have already arrived. The clearest signal is not a strategic argument: it is a spreadsheet that sits beside the product and holds the part it cannot express, maintained by one person everyone depends on.

And build when integration depth is the point. A system whose job is to sit between several internal systems is mostly integration, and integration is exactly where products are least flexible.

A decision you can run in an afternoon

Four steps. If you finish it and still cannot tell, buy — the reversible choice is the right default under genuine uncertainty.

1. 01

   Pick the horizon

   Five years unless you have a reason for a different number. Compare both options over the same window or the comparison means nothing.

2. 02

   Count the workarounds you already have

   Spreadsheets beside the tool, manual re-entry between systems, rules that live in someone’s head. Each one is a cost you are already paying and probably not counting.

3. 03

   Ask what changes when you double

   Double the users, the volume, the locations. Per-seat pricing and manual steps both scale badly, and the answer often flips the decision on its own.

4. 04

   Check the exit in both directions

   How you would leave the product, and how you would replace the custom system. If leaving the product is impossible, that is a cost too — and it belongs in the comparison.

When to switch back to a product

Custom systems can outlive their reason. If a product category has matured since you built — which happens constantly, and has happened repeatedly in scheduling, support and analytics — the system you built to fill a gap may now be maintaining a gap that no longer exists.

The signal is that maintenance has become the only work happening on it: no new capability in a year, just keeping it alive. At that point the honest move is to migrate to a product and spend the engineering somewhere the advantage still is.

A partner who cannot say this out loud has an incentive you should account for. Recommending the migration away from something we built is the same judgement as recommending building it in the first place.

Common questions

When is custom software better than off-the-shelf?

When the process is your competitive advantage, when workarounds around an existing product have already appeared, or when the system’s main job is integrating several internal systems. Standard functions like payroll and accounting should be bought in essentially all cases.

Is custom software more expensive than buying a product?

Over a short horizon, almost always. Over five years it often is not: products charge per user per year and that cost grows with headcount, while custom software front-loads the cost and then mostly stops. Pick the horizon before comparing or the comparison decides itself.

How do I know if we have outgrown an off-the-shelf product?

Look for spreadsheets maintained beside the tool, manual re-entry between systems, and business rules that live in one person’s head because the product cannot express them. Those are costs already being paid and rarely counted.

What should we do if we cannot decide between building and buying?

Buy. Under genuine uncertainty the reversible choice is the right default: a product can be replaced by a custom build later, while a custom build made for the wrong reason is a sunk cost that also has to be maintained.

Can a custom system be replaced by a product later?

Yes, and sometimes it should be. Product categories mature; a system built to fill a gap can end up maintaining a gap that closed. The signal is that no new capability has been added in a year and all the work is keeping it running.

What is the biggest hidden cost of off-the-shelf software?

Re-doing the fit after major vendor updates, and the workarounds that accumulate where the product cannot express your process. Both are ongoing, neither appears on the licence invoice, and together they are what usually decides the five-year comparison.

If building is the answer

The discovery stage measures what your current process costs to run and tells you which parts justify a build — including the parts that do not. It runs two to eight weeks and produces a plan you own.

Related guides

• Nearshore vs offshore software development

  Overlapping hours, real cost after coordination, IP jurisdiction and travel, compared dimension by dimension — including when offshore is the better call.

• What custom software development costs

  The five drivers that move the number, a worked estimate you can run on your own project, and the questions that change a quote.

• How to choose a software development partner

  Twelve questions to ask before signing, what a good answer sounds like, and the four answers that should end the conversation.