Custom developed software is frequently discussed as a philosophy — build versus buy, control versus convenience. In practice it is a narrower question than that, and it can usually be settled with a few honest measurements rather than a debate.
Start by separating the processes
Almost no organisation should build everything or buy everything. The useful first step is to split what you do into two lists: the processes that are genuinely particular to you, and the ones that are the same as everyone else’s.
General ledger, payroll, expense claims, standard reporting — these belong in the second list for nearly everybody. Buy them. The vendor spreads maintenance across thousands of customers and will handle regulatory change you would otherwise track yourself.
The first list is where the conversation actually lives, and it is usually much shorter than people expect.
Three measurements that decide it
Process fit. Take the leading product in the category and count how many of your steps it supports without a workaround. If it is most of them, buy and adapt. If you find yourself planning to export to a spreadsheet at any point in the flow, that is the product telling you it does not model your process.
Integration load. Count the systems that need to exchange data and the direction of each exchange. Products are good at being the centre of a workflow and poor at being one node among several. Above about four systems with bidirectional flow, the integration work usually exceeds the cost of purpose-built middleware.
Volume against friction. Time one workaround, then multiply by frequency. Ninety seconds at ten a day is four hours a year and irrelevant. Ninety seconds at four thousand a day is a hundred hours a day, and at that point almost any build pays for itself.
The hybrid answer is usually right
The framing that gets people into trouble is treating this as one decision for the whole estate. The common good answer is: buy the commodity systems, build the thin layer that makes them work together, and leave the seams visible so you can replace any one piece later.
That approach has a property neither pure option has — it is reversible. A bought system can be swapped when the vendor’s direction stops matching yours. A custom layer can be rewritten when you understand the problem better. A monolithic custom build of everything is reversible only in theory.
What custom actually buys you
Not features. Products can generally be configured into having features. What a build buys is:
- Enforcement of your rules rather than the vendor’s — the system can refuse things the product would allow.
- Freedom from the roadmap — nobody deprecates the thing you depend on because it was unpopular with other customers.
- Data you own outright, in a shape you chose, without export limits.
- Change on your timeline rather than in the next quarterly release.
Whether those are worth the cost depends entirely on how much the process matters, which is a business question rather than a technical one.
What it costs that the business case usually misses
Ongoing maintenance runs somewhere around fifteen to twenty per cent of the build cost annually, and it does not stop. Dependencies need patching whether or not you are adding features. Someone has to own the system internally. And the first release is typically about half of what you will eventually spend, because the valuable version is the one shaped by real usage.
If the case only survives by ignoring those, it has not survived.
A quick test
Describe the process to someone outside your industry. If they say “why do you do it that way?” and you have a good answer that connects to how you win business, that is a candidate for a build. If the honest answer is “that’s how the last system worked”, buy something and change the process.
We work through this with clients before anything is committed — and we will tell you when buying is the right answer. See our custom software development and workflow automation services, or get in touch. If custom is the answer, where the money actually goes sets expectations on cost.
Common questions
How do we decide between custom and off-the-shelf?
Split your processes into the ones genuinely particular to you and the ones everyone does the same way. Buy the second list. Then measure process fit, integration load and volume against friction for the first.
At what point does custom become worth it?
Commonly when more than about four systems need bidirectional data exchange, or when a workaround costing ninety seconds is repeated thousands of times a day. Volume converts friction into money, and money justifies a build.
Is a hybrid approach sensible?
Usually it is the right answer. Buy the commodity systems, build the thin layer that makes them work together, and keep the seams visible so any single piece can be replaced later. That combination stays reversible; a monolithic custom build does not.
