Build or buy is really a question about ownership

The internal team shows a promising prototype. The vendor shows an integrated platform. The steering committee puts the development estimate next to the subscription price and decides building is cheaper.

They might be right. But those two numbers describe different things, and the difference is where most of the cost lives.

Who maintains the connectors when a source system changes? Who investigates an access incident at eleven at night? Who upgrades dependencies, supports users and protects business definitions once the original builders move on? None of that ends after the build or the purchase. It starts there.

Map responsibilities before you compare features

For each option, draw an operating map. Source integration, identity, permissions, data quality, deployment, evaluation, monitoring, incident response, user support. Put a team or a supplier against every item. Mark the shared ones clearly, including how the hand-off works when a problem crosses organisations.

An integrated product can reduce the number of boundaries you have to coordinate. It can also tie you to someone else’s release schedule and supported patterns. An internal build keeps more design freedom and can concentrate critical knowledge in a few people. Either way, you still need an accountable owner.

Ask the internal team to price sustained ownership, including hiring and the work that will be displaced. Ask the vendor to list the implementation work the subscription doesn’t cover. Make both use the same workload, the same availability expectations and the same support scope.

Price the second and third change, not the first

The first use case is often unusually easy. You picked friendly data and a small audience. So introduce a realistic change: a new business unit, a source with different permissions, a reporting definition that needs historical treatment. Watch how much work each option needs.

Speed matters less than you’d think. Ask how the change is tested, explained to users and supported afterwards. A quick change with an unclear owner makes every change after it more expensive.

And allow yourself a hybrid answer. Plenty of organisations buy the common capabilities and keep the distinctive parts, a particular decision process or domain model, in-house. Draw that line by strategic value and maintainability, not by loyalty to building or to buying.

Make the exit plan real

UK Government guidance on technical lock-in is refreshingly balanced: provider-specific capabilities have value, and so does the freedom to move. Avoid every dependency and you give up useful features. Accept every dependency without review and future choices get expensive.

So run a practical export exercise. Could you recover source data, modelled data, metric definitions, history and access configuration in forms you could actually use? What would need rebuilding? Who owns the scripts, documentation and skills for the move? An export button doesn’t answer any of that.

The National Audit Office’s guidance for audit committees also treats exit as strategic, including the skills it requires. Use your exit estimate to understand the commitment you’re making, not as a promise that leaving will be painless.

Decide which work is worth owning

The strongest case for building explains why the capability sets your business apart and how you’ll sustain it. The strongest case for a platform explains which repeated work the product absorbs and how you keep control of your data and decisions.

Akashic is one option if you want a governed data and AI foundation, and DHIRA also builds custom systems on the stack you already run. Either way, a responsible evaluation tests your real sources, deployment constraints and operating boundaries. A long feature list is a hypothesis about value, not proof of fit.