Building makes you a developer under Singapore's AIHGle 2.0, with the obligations that carries. That belongs in the decision, and rarely is.
Frame it by role rather than cost. Under Singapore's AIHGle 2.0, building in-house makes your organisation the developer as well as the deployer, adding documentation, validation and post-market obligations you would otherwise share with a vendor. Buying keeps you as deployer but ties you to a roadmap, an update cadence and a commercial relationship you do not control. Build where the workflow is genuinely specific to you and you can sustain the capability. Buy where the problem is common.
Most build versus buy analyses compare a development estimate against a licence fee. That comparison is nearly always wrong, because it prices the first version and ignores the decade.
A more useful question: which regulatory role are you willing to hold? AIHGle 2.0 distinguishes developers, deployers and users. Buy a solution and you are a deployer. Build one and you are both, and the developer obligations are the heavier set.
That last one causes more failures than the technical work. Institutions build a working model with a talented team, and the team disperses. Three years later a system nobody understands is still making recommendations.
Our default recommendation is buy, with one clear exception. If the problem is common to healthcare organisations generally, someone has solved it better than you will, and building is usually an expensive way to acquire a worse version of an available product.
The exception is where the workflow is genuinely idiosyncratic to your institution, and where the thing you are encoding is your own accumulated practice rather than general clinical knowledge. That is rarer than internal enthusiasm suggests. When a team argues their situation is unique, ask what specifically about it no vendor could accommodate through configuration. The answer is often nothing.
The scenario we caution against most is the middle path: buying a platform and building substantially on top of it. It is attractive because it feels like control without the burden. In practice it can move you across the line into the developer role for the parts you built, while leaving you dependent on a vendor for the parts you did not, and the accountability boundary between the two becomes impossible to draw when something goes wrong.