The question usually arrives already framed as a comparison: here is what the product does, here is what we would have to build, here are the two numbers. That framing is why the decision so often goes wrong. It compares a finished thing against an estimate, which the finished thing wins every time, and it compares them on the axis — features — that matters least.
A more useful framing: buying software is not buying a tool, it is entering a relationship with a company whose roadmap is not yours. Building software is not buying a tool either. It is taking on an obligation that outlives the person who signed for it. Both are commitments. The question is which commitment fits.
Five questions that settle it
1. Is this process the thing you compete on?
If two firms in your sector would run the process identically, buy. Payroll, accounting, email, ticketing — the differences between companies here are noise, and the vendor has already met a thousand versions of your edge case. If a client would notice the difference between how you do it and how your competitor does it, that is the part worth building.
2. How much does the tool need to know about your data?
A tool that needs one field from you is easy to buy. A tool that needs to understand the shape of your business — what a “case” is, what a “job” is, which states a thing can be in — is where bought software starts requiring you to describe your work in someone else’s vocabulary. That translation cost is paid every day, by everyone, forever, and it never appears on the invoice.
3. How many people, and how often?
Five people using something twice a month can live with friction. Forty people using it hourly cannot. Multiply the awkwardness by the usage before deciding it is tolerable — a workaround that costs two minutes, thirty times a day, is a full-time job nobody budgeted for.
4. What happens when the vendor changes it?
They will. Read the last two years of their release notes, not their roadmap. A vendor who removes features, reprices annually, or has been acquired twice is a different proposition from one whose product looks much as it did in 2022. Neither is disqualifying. Both are worth knowing before you build a process on top of it.
5. What do you keep when you stop paying?
Ask specifically: in what format, how completely, and how long does the export take. “You can export to CSV” is not an answer if the relationships between the records do not survive the export. Software you can leave is software you can safely commit to.
The two answers that should stop you building
“We could not find one that does exactly what we want.” Most of the time this means the requirements have not been separated into what the business needs and what the current team is used to. Build against the first; the second is a training problem wearing a software costume.
“It would be cheaper than the licences.” Compare licence cost against the whole life of the thing you would build — the first version, plus the changes, the dependency updates, the hosting, and the person who has to understand it in three years. Against that total, licences are usually cheap. When custom is genuinely the right call, it is rarely because it saves money; it is because the bought version costs something other than money.
The option people forget
You do not have to choose per company. You choose per process.
Buy the platform, build the edge. Take the accounting system, the CRM, the storage; build the one workflow that is genuinely yours, and connect it to the rest through their APIs. This is the answer far more often than either extreme, and it fails for a specific, avoidable reason: nobody owns the integration. Whatever you build, name the person responsible for the seam between the two, before anything is signed.
- Custom software
- Procurement
- Architecture