Custom Software or Off-the-Shelf? The Real Trade-off

The question is almost always framed as two options: do we buy a package, or have custom software built? Framed that way it cannot be answered, because the least expensive option depends on something the question leaves out — how unusual your process actually is.

This page sets the three routes side by side, names what decides it in practice, and describes one shift from 2026 that has made the old rule of thumb outdated.

Three routes, not two

Alongside off-the-shelf and custom sits a third route that most comparisons leave out.

Off-the-shelf

You buy what exists and adapt your process to it. Live quickly, predictably priced, and maintenance is not your problem. You pay for it in fit: every part of how you work that differs from the vendor's assumption becomes a workaround, and workarounds compound.

Custom

You have built what you need. It fits exactly, you own it, and nobody changes it underneath you. Against that, you are the only user: every bug is your bug, every maintenance cycle is your bill, and the knowledge sits with one supplier.

Low-code

A middle route: a platform supplies the building blocks and you assemble the process. Faster than custom, more flexible than a package. The question to settle first is what happens if you ever want to leave the platform — with low-code that is rarely trivial.

What actually decides it

Not the size of your company, and not the budget. It is how far your process departs from what the market assumes.

If you do something the way most firms in your sector do it, a package is almost always less expensive — even when the fit is imperfect. If you do something your competitors do not, and that is precisely why customers buy from you, then a package that pushes you toward the average is not a saving but a risk.

The usable test: describe your process to three package vendors. If all three say "our customers usually do that differently", you have a custom candidate. If they say "that works out of the box", you do not.

What changed in 2026

The classic rule — custom is expensive, so choose a package unless it truly cannot work — came from the cost of building. That cost has fallen over the past two years, as AI-assisted development absorbs part of the routine work.

That moves the line, but less than the stories suggest. What got less expensive is writing code. What did not: working out what should be built, integrating with your existing systems, testing, and keeping it running for five years. In an honestly budgeted project, writing code is rarely the largest line.

So the practical consequence is not "custom is inexpensive now". It is that projects which narrowly failed to justify themselves two years ago now narrowly do — and that the comparison is worth running more often than it used to be.

The most expensive mistake: custom that rebuilds a package

The costliest custom projects we encounter are not the ambitious ones. They are the ones where a company built something an existing package would also have done, because the package failed on three points.

Those three points are genuinely annoying. But you also acquire the other seventy features you now have to build, test and maintain yourself — and which the package already had finished.

So always press on the rejection. "It does not fit" is not an answer; "it cannot carry two price agreements per customer and that is our entire business model" is.

What to settle for all three before signing

Whichever route you choose, three agreements are rarely available after the fact, and they sit differently in each of the three.

Ownership. With custom you should own the source and the documentation, not merely a licence to use it. With low-code you own your configuration but not the platform. With a package you own nothing, which is fine as long as you know it.

Exit. In all three cases, ask how your data comes out: in what format, how completely, and at what cost. This is the question with the most negotiating room before signature and the least after it.

Continuity. For a package, the question is what happens if the vendor is acquired. For custom, it is what happens if the builder stops — and whether anyone else can take the code on without rewriting it first.

A common ordering mistake

Many companies pick the route before the problem. They decide "we are going custom" or "we want to move to a package", then look for a reason to fit it.

The reverse works better: name the process that costs money, measure what it costs today, and only then have all three routes quote against it. That is also the only way to establish afterwards whether it helped.

Cost it over five years, not over the project

A package looks low-cost at purchase and continues in licences. Custom looks expensive at purchase and then carries a maintenance line that people systematically underestimate.

For concrete figures in the Dutch market there is a separate piece on what custom software development costs.

When AI is the custom part

Sometimes the reason no package fits is not your process but that the work requires a judgement standard software cannot make — interpreting documents, assessing applications, recognising patterns in your own data.

We cover it separately in having custom AI software built.

If the comparison lands on custom, the follow-up question is who builds it and at what price: our page on custom software development in the Netherlands covers exactly that.

In short

If your process is not unusual, buy a package and adapt. If it is unusual at exactly the point where you make your money, custom is defensible. If you sit between the two, look at low-code first — and cost all three over five years rather than over the quote.

Frequently asked questions