What is a custom software system? It is software built for one organisation’s specific process, rather than sold to many organisations with configuration options. That is the whole definition. Everything interesting is in when it pays and when it does not.
The real difference is not features, it is assumptions
People usually describe the choice as custom-versus-off-the-shelf in terms of features: the product has these, you need those. That framing is misleading, because most products can be configured into having most features.
The difference that matters is assumptions. Every product encodes a model of how the work should be done — what happens first, who approves what, which states a record can be in. Configuration lets you change labels and options. It rarely lets you change the model.
When your process matches the product’s assumptions, buying is obviously right. When it does not, you have two choices: change your process to match the software, or build software that matches your process. Both are legitimate. The mistake is pretending there is a configuration path that avoids the choice.
Three conditions where building pays
Custom software earns its cost in reasonably specific circumstances.
The process is a competitive advantage. If the way you do something is genuinely better than how competitors do it, buying the same product they use erases the advantage. This is the strongest case, and the rarest. Be honest about whether your process is actually differentiated or merely familiar.
The integration surface is the product. Some organisations do not need a new system so much as they need their existing seven systems to behave as one. Off-the-shelf products are poor at this because each one wants to be the centre. Custom middleware that assumes no centre is often cheaper than the licence you were about to buy.
The volume makes small inefficiencies expensive. A workaround that costs ninety seconds is irrelevant at ten transactions a day and serious at four thousand. Volume converts friction into money, and money justifies a build.
Three conditions where it does not
The process is genuinely generic. Payroll, general ledger, standard tax reporting. If a thousand companies do it nearly identically, someone has already built it better than you will, and they maintain it for a fraction of what your maintenance will cost.
You are building to avoid a decision. Sometimes a custom build is commissioned because two departments cannot agree on a process, and bespoke software promises to accommodate both. It will — and you will maintain both forever. Settle the disagreement first; it is cheaper.
Nobody will own it. Custom software needs someone internally who understands it and has authority over its direction. Without that, it decays into a system everyone depends on and nobody can change.
The cost people forget
The build is the visible number. The costs that surprise people arrive later:
- Dependency updates and security patching, indefinitely.
- Changes forced by other systems — an API you consume deprecates a version, and you have no choice about the timeline.
- Knowledge transfer every time someone leaves.
- The second and third releases, which are where most of the value actually appears and which almost never appear in the original business case.
A reasonable planning assumption is that ongoing cost runs at fifteen to twenty per cent of the original build per year, and that the first version is roughly half of what you will eventually spend. If the case only works when you ignore that, it does not work.
A third option that is often better than both
The custom-versus-buy framing hides a middle path: keep the systems you have and automate the joins between them.
A great deal of the pain attributed to “our software does not do X” is really the cost of humans copying data between systems that do not talk. That is frequently solvable with workflow automation at a fraction of the cost of replacing anything, and it has the useful property of being reversible.
It is worth pricing this option explicitly before committing to a build, because it is the one nobody sells you.
How to decide
Write down the process as it actually runs, including the exceptions and the unwritten rules. Then ask which parts are genuinely yours and which are the same as everyone else’s. Buy the second category. Consider building or automating the first.
If the answer is that almost none of it is genuinely yours, that is a good outcome — you just saved a significant amount of money.
We help companies work through exactly this question before anything is committed. Read more about our custom software development work, or start a conversation. If the answer is yes, where the money actually goes covers what you are paying for.
Common questions
What is custom software in simple terms?
Software built for one organisation's specific process, rather than sold to many organisations with configuration options. The meaningful difference is not features but assumptions — every product encodes a model of how work should be done.
When is custom software worth the cost?
When the process is a genuine competitive advantage, when integrating several existing systems is the real requirement, or when volume makes small inefficiencies expensive. Outside those, buying is usually better.
What does custom software cost to maintain?
Plan for roughly fifteen to twenty per cent of the build cost each year, and expect the first release to be about half of total eventual spend, since the valuable version is the one shaped by real usage.
