Engineering4 min read
When custom software is worth it, and when it isn't
Four questions to decide between buying, configuring and building, and why the cost of custom software is not where people usually look for it.
We build custom software for a living, so the honest way to start is with the other side: most of the time it is not worth it.
An ERP, a CRM or an invoicing tool already exists, costs a fraction, and comes with support, updates and certifications you would otherwise have to earn yourself. Building your own version of a mature product is one of the most expensive ways to lose two years.
There are cases where it is worth it. These are the four questions we use to tell them apart.
1. Is this the thing you win on?
Split your processes into two piles. In one, whatever makes customers pick you over the company next door. In the other, everything else: payroll, accounting, email, support, access control.
The second pile you buy. Always. It does not matter how particular your way of doing accounting feels: that is not why anybody buys from you.
The first pile is the candidate. If your edge is how you route orders, how you quote, how you schedule routes or how you prioritise production, an off-the-shelf product will force you to work the way everyone else does — which is the exact opposite of what gave you the edge.
2. How long have you been fighting the tool?
An off-the-shelf product that does not fit does not look like a failure. It looks like a layer of work around it: the parallel spreadsheet, the "notes" field where the important data actually lives, the manual step between two systems, the person who knows the trick.
That layer has a cost and it is almost never in anyone's budget. Before deciding anything, measure it: how many hours a month, from how many people, and what happens when that person goes on holiday.
If the answer is two hours a month, live with it. If it is two full-time people, you are already paying for custom software every year — you just have nothing to show for it.
3. Is what you want to build stable?
Custom software works well when the rules change slowly. If the process is still being invented, anything you build will run a quarter behind.
In those cases we prefer to start with the cheapest thing that resolves it: a configuration, an integration, an automation on top of the tools you already have. When the process settles — and you can tell, because the rules stop changing and only the volumes do — you build.
Building before the process is stable is the number one reason a custom project ships late and arrives out of date.
4. Who maintains it next year?
This is where the cost is actually decided, and it gets the least attention.
Custom software does not end at delivery. It needs dependency updates, security patches, somewhere to run, and someone to answer when it breaks on a Tuesday at 11 p.m. An off-the-shelf product bundles all of that into the subscription.
If you are going to build, the budget has to include maintenance from day one, and the answer to "who" has to be a name, not "we'll see". Without that, the system that gave you an edge in year one is debt by year three.
The middle option almost nobody considers
Buy or build are not the only two boxes. In between sits building only the piece that sets you apart and buying the rest.
Use off-the-shelf invoicing, with your own quoting engine on top. Keep the ERP as the source of truth, and build the field app your technicians actually use. Integrate rather than replace.
It is cheaper, it ships sooner and it can be undone. And it usually resolves 80% of the pain, which is what you were after.
How we decide it with a client
We do not have this conversation in the abstract. The sequence we follow:
- Measure the layer of work around the current tool: hours, people, errors.
- Write the process down on one page. If it does not fit, the tool is not the problem.
- Look at the market again, now with the written process in front of you. Sometimes it does exist and nobody had searched with the right words.
- If it does not exist, scope the smallest piece worth building, and what it integrates with.
- Put a number on maintenance before starting, not after.
If the answer at the end of step 3 is "buy", we say so. We lose the project and win the next conversation, which is usually the more interesting one.
- product
- architecture
- decisions