Build or buy decides more of a software budget than any other question, and it is usually settled by whoever argues most confidently in the room. Here is a way to settle it on the facts instead.
The question underneath the question
It is not "can we build this?" — you almost always can. It is: is the way we do this thing part of why customers choose us?
If yes, build. You are encoding your advantage, and bending it to fit someone else's product means slowly becoming the same as everyone using that product.
If no, buy. You are purchasing a solved problem, and building it yourself means paying to solve it again and then paying forever to maintain your version.
Most things are the second kind. Accounting, payroll, email, helpdesk, payments, CRM. These are not where you win, and companies that build them anyway are usually doing it because building was more interesting than choosing.
Buy, and don't call us
Plainly, because it is true more often than a firm like ours has any incentive to say: if a product does 80% of what you need and the missing 20% is preference rather than necessity, buy it.
The 20% will feel important. It usually is not. And the cost of custom software is not the build — it is the maintenance, the upgrades, the person who has to understand it in three years, and the day the one who wrote it leaves. A subscription has all of that priced in, and someone else is on call.
Buy when the process is standard, when the regulation is standard, when you would be one of many similar customers. Being an ordinary customer of a good product is an excellent position.
When buying goes wrong
Two ways, and both are predictable.
You bend the business to fit the product. Small compromises accumulate until the thing that made you distinctive has been configured away. This is the real cost of buying where you should have built, and it arrives slowly enough that nobody attributes it.
You buy several and connect none. Six good products, none talking to each other, and a person in the middle copying between them. You have bought six solutions and manufactured a seventh problem. The integration work you avoided at purchase arrives anyway, later, more expensive, and now spread across six vendors' interfaces.
The middle option people forget
Buy the commodity, build the thin layer that is actually yours, and connect them properly.
Standard accounting package, standard CRM — and a custom piece in between that encodes how your business moves work through them. Small surface area, high leverage, and you own the part that matters while someone else maintains the parts that do not.
This is the right answer surprisingly often, and it is rarely proposed, because it is neither of the two options anyone came into the room with.
How to decide this week
Write down the process. Ask whether a customer would notice if you did it the standard way. If no, go shopping and take the best fit at 80%. If yes, ask what specifically is different, and whether that difference is worth owning, maintaining and staffing for a decade.
Then, before committing either way, ask what it costs to reverse. Buying is usually reversible at the price of a migration. Building is reversible at the price of the build. That asymmetry should make you lean towards buying whenever the case is genuinely close.
If it is not close and you cannot tell which way, an outside read helps — particularly one from someone who will say buy. A Reality Check is a week, a fixed fee, and it disqualifies work as readily as it recommends it.
This is the part we do — the crossing from a demo to a system that survives production.