We build custom software, and we tell a fair number of people not to. That is not modesty. Getting build or buy wrong is one of the more expensive mistakes an organisation can make, because the cost does not land at the start. It lands every year afterwards, quietly, in maintenance nobody budgeted for.
Start by assuming you should buy
If a mature product exists that does roughly what you need, buying is almost always correct, even if it fits imperfectly. You are not just buying features. You are buying the bugs already found, the security patches already written, the documentation, the training material, and the fact that someone else is responsible when it breaks.
Ten years of other people’s problems have already been solved in that product. You cannot buy that with a development budget.
The question that actually decides it
Not “can we build this” — you almost always can. The question is: is this process a source of advantage, or is it just something we have to do?
Payroll is something you have to do. However you run it, no customer chooses you because of it. Buy it.
But the specific way you quote a job, or schedule engineers, or route an order through your particular production constraints, might be the thing you are actually good at. If a bought system forces you to work like everybody else, you have paid to become average at the thing that made you distinctive.
That is the case for building. It is a narrower case than most people assume.
Signs you should build
- Everyone in the market works differently from you, and your difference is deliberate rather than accidental.
- You are running the real process in spreadsheets alongside the system you bought, because the system cannot express it. That is the clearest signal there is.
- Per-seat licensing has grown to where a build pays back in a foreseeable time.
- You need it to talk to something specific, and the vendor’s integration options do not reach it.
Signs you should not
- The main argument is cost. Building to save money nearly always fails, because the running cost is invisible at decision time.
- Nobody internally will own it. Custom software without an owner degrades from the day it launches.
- The requirement is “like that product but slightly different”. You will spend years catching up to a product that keeps moving.
- You are building because procurement is slow. Fix procurement.
The option people forget
Most good answers are not either/or. Buy the mature core, then build the thin layer that carries your difference.
Buy the accounting package. Build the quoting tool that reflects how you actually price, and integrate the two. You get the maintained core and the distinctive part, and the custom code stays small enough that one person can hold it in their head.
That last point matters more than it sounds. A small, well-scoped custom component is maintainable for years. A large one becomes a liability the moment its author leaves.
Cost the whole life, not the project
A build has hosting, monitoring, backups, dependency updates, security patching, and someone available when it breaks at an inconvenient moment. Over five years the ongoing cost commonly exceeds the original build.
Bought software has its own compounding: licence rises, per-seat growth, paid add-ons, and the migration cost if you ever leave.
Compare both over five years or the comparison is meaningless.
A shortcut
Write down the process in one paragraph. If you can describe it without using your own company’s vocabulary, a product exists for it. If the paragraph is full of terms only your team uses, you may genuinely be an exception.
If you want that tested properly against your operation, that is where our custom software engagements begin, and often end with a recommendation to buy something instead. Where the answer is the hybrid, system integration is the piece that makes it work.
Related reading
- What business process automation actually means in practice — Business process automation is sold as removing work. In practice it means writing a process down precisely enough for a machine to follow it.
- API integration: what actually goes wrong between two systems — An API integration is easy to demo and hard to keep running. The failure modes that appear in month three, and how to design around them from the start.
- Barcode symbologies: choosing between Code 128, QR and DataMatrix — Choosing between barcode symbologies comes down to data volume, available space and how damaged the label will get. A practical guide to each one.