Knowledge baseSoftware

When custom software is the wrong answer

8 September 20264 min read

Ask a software builder for advice and you expect one outcome: "let's build." Yet that is often the wrong answer, and a supplier who does not dare say so out loud is not advising but selling. The honest question behind every custom project is not "can we build this?" — that is almost always possible — but "is this process worth building something for?"

The calculation nobody makes

Custom software does not cost money once. After delivery the real contract starts: security updates, ageing dependencies, further development, and in five years the question of who still knows this code. With standard software those costs are spread across all users of the package; with custom software you carry them alone. That calculation regularly comes out in favour of building, but it has to be made — and whoever skips it discovers the outcome anyway, only later and at a higher price.

When standard wins

  • The process is not distinctive — accounting, CRM, inventory, HR: processes that run practically the same at thousands of companies. There, standard software is not the cheap choice but the better one; it contains more thinking and more field experience than one custom project can ever catch up with. Often configuring a package like Odoo is the entire answer.
  • The problem is connecting, not building — a lot of "we need custom software" turns out, on closer questioning, to be "our systems do not talk to each other". An integration is days of work where an application of your own would cost months.
  • The package covers ninety per cent — and the last ten per cent is a working habit you can change without pain. Adapting a process to a package feels like losing, but sometimes it is simply the cheapest improvement available.

When custom software does pay off

Custom development belongs where the process is the distinction: the work you do differently from your competitors, where a standard package presses you into a mould that flattens that advantage. Automation around standard packages belongs here too — the package stays the foundation, the custom part does what no package can know about your situation. And sometimes there simply is no package for what you do; then building is not a choice any more but a given.

The ratio is rarely all-or-nothing. Most healthy landscapes are a combination: standard for the bulk, custom on the distinctive part, and integrations in between.

How we advise on this

We deliver both sides of this advice — Odoo implementations and custom development — so whichever way it falls, we have no interest in reasoning towards building. And when we do say build, everything we described earlier applies: transferable from day one, so the custom software does not chain you to us. Unsure whether your problem calls for building, configuring or connecting: get in touch and we will make that calculation first.

Frequently asked questions

Frequently asked questions

You earn money on custom software — why would this advice be honest?

Because we deliver both: Odoo implementations and custom development. Whichever way the advice falls, the work can land with us, so there is no incentive to reason towards building. And wrongly advised custom software comes back to us through maintenance anyway.

Can I still move from standard to custom later?

Yes, and that is often the sensible route: start on standard software, learn where it genuinely pinches, and build only that. You then finance custom work with certainty instead of assumptions, and your data has a proper system as its home base in the meantime.

What is the most expensive scenario?

Custom software that rebuilds a standard package. You pay to build functionality that was for sale, and then every year you pay the maintenance that a package spreads across thousands of users — but yours is spread across one.

Answer not found?

Ask an engineer directly — we usually respond within one business day.