Software · Strategy
Build, buy or integrate? A practical test for custom software
Custom software is an asset with running costs. Five questions that separate the projects worth building from the ones better solved with an existing product.
This is a preview edition under review. It may change before publication.
We are a team that builds software, so it may seem odd that we sometimes recommend not building it. But custom software only creates value when it does something an existing product cannot — and it keeps costing money after launch. Before scoping a build, we work through five questions with clients.
1. Is the process stable?
Software encodes a process. If the process is still changing every month, building it in code freezes something that is not ready. Run it with flexible tools — spreadsheets, forms, an automation platform — until it settles. The workarounds will tell you exactly what the software needs to do.
2. Is it a differentiator or a commodity?
Accounting, email, payroll and generic CRM are solved problems; buy them. The way you price complex jobs, schedule specialised staff or deliver your service may be what makes you competitive. That is where custom software can be worth its cost.
3. How much of the gap can integration close?
Many “we need custom software” requests turn out to be “our tools don't talk to each other”. Connecting good existing products through their APIs is usually faster, cheaper and easier to maintain than replacing them. Build only the part that genuinely does not exist.
A common middle path
Keep the commodity systems, build a thin custom layer for the workflow that is specific to you, and integrate the two.
4. Who will own it?
Software needs updates, security patches and someone who understands it. Before building, decide who owns the product internally, who maintains the code, and what that costs per year. If nobody can own it, the right answer is usually an existing product with a vendor who will.
5. What does the first version need to prove?
A good first release is narrow. It serves one group of users, handles one workflow end to end, and is measured against a clear outcome: hours saved, errors avoided, revenue enabled. If the first version cannot be described that way, the scope is not ready.
When building is clearly right
- The software is the product you sell.
- The workflow is a competitive advantage and existing tools force you to dilute it.
- Integration costs and licence fees across several tools exceed the cost of owning one system.
- Data, security or compliance requirements rule out the available products.
If one or more of these is true and the five questions have good answers, custom software is likely to pay for itself. If not, the better investment is usually in configuring, integrating and automating what you already have.