Build or buy: when custom software pays off
Buying is the right default. Building wins in a few specific situations, and it helps to recognise them before the licence renewal.
By the Maple Crew team · · 4 min read
We build custom software for a living, and our first advice to most clients is still to buy. Packaged software is cheaper, available today and maintained by someone else. Custom development has to earn its place. It does so in a small number of recognisable situations.
When the process is your advantage
If the way you do something is the reason clients choose you, forcing it into a generic tool erases the difference. Accounting is rarely a competitive advantage. The way you match candidates, assess risk or schedule field teams might be.
When the workarounds have become the system
Look for the spreadsheet that sits between two applications, updated by hand every morning. Look for the export, re-format, import routine that only one person understands. These are signs that the packaged tools no longer fit, and that you are already paying for custom software, in salaries.
When integration is the product
Often no single system is wrong. They just do not talk. A small, well-built integration layer between the tools you already own can deliver more than replacing any of them.
When licences scale worse than code
Per-seat pricing is attractive at twenty users and painful at two thousand. Run the five-year numbers, including the features you pay for and never use.
If you build, build small
- Start with the one workflow that hurts most, not a platform.
- Put working software in front of users within weeks and adjust.
- Insist on tests, documentation and a deployment you could hand to another team.
- Own the code and the data. Lock-in to a developer is still lock-in.
The honest answer to build or buy is usually both: buy the commodity, build the difference, and connect the two cleanly.