Build versus buy · 4 min read
When buying is the wrong answer, and how to prove it with a number
Every build recommendation is an opinion until it has a quote attached to it. Here is the arithmetic I do before I open my mouth.
The default in hospital IT is to buy. It is the defensible choice: somebody else carries the roadmap, somebody else answers the phone at two in the morning, and if it goes wrong there is a contract to point at. I have recommended buying more often than I have recommended building, and I want to be clear about that before describing the cases where I did the opposite.
What changes the answer is not enthusiasm for building. It is a number.
Before I recommend building anything, I get a real quote for the alternative. Not a analyst estimate, not a price on a website: a quote for our seat count, our modules, our integration requirements, over the term the finance office actually plans against. That figure is the entire basis of the conversation, and getting it takes a week of somebody else's time that people are often reluctant to spend on a product they have already decided not to buy. Spend it anyway. A recommendation to build without that number is an opinion, and opinions lose to contracts.
Then I cost the build honestly, which mostly means costing the parts that are not the build. The first version is the cheap part. What matters is the second year: who fixes it when the person who wrote it is on holiday, what happens when the underlying framework goes end of life, and what the support load looks like when four departments are using it instead of one. If those answers are uncomfortable, the honest recommendation is to buy, and saying so is what makes the build recommendations credible when they come.
The four platforms I have replaced in-house each cleared that comparison before a line was written. Policy and procedure management, evaluations, on-call scheduling, and digital fax. The modelled avoidance across them is real, and I present it as modelled avoidance rather than savings, because the hospital did not receive a cheque. It stopped paying a licence.
Which brings me to the part of the argument that is usually left out. The licence is the smaller half.
The larger half is what ownership buys you that does not appear on an invoice. One data processing agreement instead of five. One answer to where protected information lives. A department that needs a new field gets it in a sprint rather than in a vendor's next release, if it appears at all, and that changes what departments are willing to ask for. Most usefully: a renewal stops being a notice and becomes a negotiation, because the thing you are negotiating over is already yours.
None of that is quantifiable to the precision a finance office likes, and I do not pretend otherwise. I put the licence figure in the business case because it is the number that survives scrutiny, and I make the ownership argument in person, because that is the one that is actually load-bearing.