Business

Custom software: when it wins, and when it is a waste

Standard software is right for everything you do the way everyone else does it. Custom pays off only where your way of working is the competitive advantage: there, an off-the-shelf product forces you to resemble your competitors. The practical rule is to customise little, in the right place, and stay standard everywhere else.

13 Jul 2026 · 9 min read · updated on 27 Aug 2026

Let's start from an uncomfortable position for people in our trade: in most cases you should buy, not commission. A standard product costs a fraction, has already been tested by thousands of companies, and will still exist tomorrow morning even if your supplier disappears.

But there is a part of every company's work that standard products don't cover, and not out of laziness on their part: it is the part where you do things differently from everyone else. And it is exactly the part your margin comes from.

The question that decides everything

For every function, the question is not "does the system do it?" but a different one:

Do we do this process the way everyone does it, or is it one of the reasons customers choose us?The test we use to decide standard or custom

If the answer is "like everyone" — accounting, payroll, e-invoicing, basic stock — buying is almost always right. Adapting your company to the standard costs less than adapting the software to your company, and it hands you features somebody else will keep up to date for you.

If the answer is "it is why they choose us", a standard product forces you to work like your competitors. You are paying to resemble them.

The signals that custom is genuinely needed

These are not opinions: they are symptoms you can observe on site in half a day.

The parallel spreadsheets. If beside the business system there is a file someone updates by hand and on which the real decisions are made, that file is the specification of the software you are missing.
The people who "know how it's done". When a process works only because two people hold it up from memory, the company has a risk, not an advantage.
Exceptions that are the norm. If ninety per cent of orders go through a procedure the system calls a "special case", the system is describing a different company.
Translation work. If someone spends the day turning one system's data into another system's format, you are paying a person to act as middleware.
Customers asking for what you can't give. A portal where they see the status of their orders, an app that records what happens on site: if three of them ask, it is a market.

The real costs, on both sides

An honest comparison is not "licence versus development". They are two routes with different costs that show up at different times.

The standard product costs little up front and presents the bill later: fees that grow with users, extra modules for things you assumed were included, customisations to be redone at every upgrade, and a hard ceiling the day you need a feature the vendor has no plans for. On top of that, your data lives in a format that is theirs, not yours.

Custom costs more up front and is an asset that must be maintained: someone has to update it, fix it, evolve it. In exchange there are no per-user fees, it does exactly what is needed, and the data stays in your house in a format anyone can read.

The risk of custom has a precise name, and it should be said out loud: depending on whoever built it. It can be reduced concretely — source code yours by contract, widespread rather than exotic technology, decisions documented, and no piece only one person knows how to run — but it does not disappear. Ask about it before signing, not after.

The route we recommend almost every time

In practice the best choice is rarely all on one side. It works like this:

Standard for the common work. Accounting, invoicing, compliance: a mature product, well configured, without touching its code.
Custom only where you are different. One module, one app, one portal: small, targeted, wired into the system you already have.
A clean connection between the two, with an explicit data contract, so upgrading one does not break the other.
One slice at a time, in people's hands. Every piece we deliver has to be used by someone before we start the next: it is the only way to find out in time that a feature wasn't needed.

This approach has an advantage you only see later: if one day you change business system, the custom piece stays. It is attached to your process, not to somebody else's product.

How to recognise a project that will end badly

It starts from the screens instead of the process and the permissions.
The quote covers everything down to the last detail, with firm dates a year out: it means nobody has understood the problem yet.
Nobody asked you what happens when someone makes a mistake, or when two people edit the same thing at once.
There is no plan for anyone in your company to use the software before the end.
Technology is discussed before how you work is discussed.

If you are weighing whether to commission something, the useful conversation does not start from what you would like to see on screen: it starts from which part of your work resembles nobody else's. If there isn't one, the honest advice is to buy a product and spend that money elsewhere.

What does custom software cost?

It depends on scope, but the useful order of magnitude is this: a targeted module on a single process is measured in weeks of work, a full platform in months. Be wary of anyone quoting a price before seeing how you work: they are guessing, and the bill arrives later as change requests.

Is the source code ours?

With us, yes — and put it in writing with whoever you work with. Along with the code you need the instructions to rebuild the environment and the credentials: code alone, without knowing how to run it, is worth little.

Can we start small?

It is the way we recommend. Pick the process that costs most today, build only that, and put it in people's hands. If it works you continue; if it doesn't, you spent little to find out.

What if we later want to change supplier?

It is the main risk of custom and it is reduced beforehand, not afterwards: widespread technology, your code, documented decisions, no pieces only one person can run. They are the same things that make software maintainable — anyone refusing them is tying your hands.