The build-versus-buy framing hides the option most enterprises actually need, and the three constraints that decide it have nothing to do with engineering capacity.
The debate usually opens with capacity. Do we have the engineers? Could we hire them? How long would it take? Those questions feel central and are close to irrelevant, because capacity is the constraint most easily bought and the one least likely to determine the outcome.
From the standard
“a framework to better manage risks to individuals, organizations, and society associated with artificial intelligence (AI)”
What each pure option actually costs
Building from zero
The visible cost is the team. The invisible one is that most of the budget goes into infrastructure that is entirely solved and confers no advantage: identity federation, a policy engine, tool orchestration, distributed tracing, an approval gate that survives replay, execution sandboxing, and an audit pipeline.
Teams routinely underestimate this by a factor of three, because the demo — the part that shows the model doing something impressive — genuinely is quick. The remaining 80 percent is the part that makes it deployable, and it is invisible until you attempt to deploy.
Buying a hosted platform
Fast, well-supported, and the correct answer for a large class of problems. It fails on two specific conditions: when the deployment topology it offers cannot satisfy a residency commitment you have already made, and when the integration you need sits on a roadmap you do not control.
The second is underweighted at signing. Every enterprise has a system that matters and that no vendor prioritises — the internal platform, the twenty-year-old system of record, the regional instance nobody outside the company has heard of. A platform that cannot be extended to reach it will be worked around, and the workaround becomes the shadow architecture.
The third option
Assembly: start from a proven architecture, adapt it to your environment and constraints, deploy it inside your own perimeter, and take ownership of the source at the end.
The solved infrastructure is not rebuilt, which is where the schedule compression comes from. The topology is yours, so residency is answerable with a network diagram. Integration is your decision rather than a vendor's prioritisation call. And the engagement terminates in a transfer rather than a subscription.
The trade is that you own it afterwards. That is a real obligation, and it is the reason the third constraint below decides more projects than the other two.
The three constraints that actually decide
1. May the data leave? If a contract or regulator says no, hosted platforms are eliminated regardless of their merits. 2. Is this a differentiator or a commodity? Commodity capability should be bought; differentiated capability should be owned. 3. Who owns it in eighteen months? If no named internal team will receive the system, it will decay whoever builds it.
Commodity and differentiator are not obvious
Most organizations classify this wrongly in a predictable direction. General conversational assistance, meeting summarisation, and document search are commodity — they are the same problem everywhere and buying them is correct.
What is differentiated is anything grounded in knowledge only you hold: your signal taxonomy, your requirement corpus, your pricing logic, your equipment configurations. Those are not features a vendor can ship, because the value is in the grounding rather than the model. Buying a generic tool and pointing it at that knowledge produces confident output that references things which do not exist.
What to require in the contract
If you choose assembly, the deliverable list is what protects you, and it should be explicit rather than assumed.
Full source with history. Infrastructure-as-code, so the deployment is reproducible from a commit rather than from a document describing what someone clicked. Architecture decision records covering what was chosen and what was rejected, so your team can revisit a decision without re-deriving the context. The automated test suite, running in your CI. And hands-on enablement for the engineers who will carry it — working sessions against the real system, not a slide deck and a recording.
The test is simple: if the supplier disappeared the following Monday, would the system keep running and could your team extend it? If the honest answer is no, you bought a dependency, and the eventual exit will cost more than the original build.
Decide ownership before you decide approach
Constraint three quietly overrides the other two. A brilliantly built system with no internal owner is a liability with a maintenance schedule — it degrades, nobody is accountable, and within two years it is the thing everyone routes around. Identify the receiving team before the engagement starts, and involve them in the build rather than at handover.
Axionalytics
Production agentic AI for enterprise engineering, data, and revenue teams.