01
Control without a counterparty.
No contract to read, no roadmap to wait for, no third party whose incentives differ from yours. When something is wrong you change it on Monday. No managed arrangement fully reproduces that.
Every engineer who has wired a model into an internal tool in a weekend knows the first part is easy. The argument is about the second part.
The demo takes a weekend. The platform takes a standing team.
Building it yourself gives you real control, and if you have a capable platform team it is a legitimate answer we will not argue you out of. What it also gives you is a second product to maintain, in a market where the catalogue, the pricing and the model families move every few months.
What a build genuinely buys you.
THE FAIR CASE · 01
We build for a living, so we are not going to be precious about somebody else doing it. An internal build is the only option on the comparison page that gives you both the boundary and the source on day one, with nobody in the middle. Three things are genuinely better when you build, and they are not small.
02
Fit to your actual processes.
Your people know where the work really sticks. A team inside the organization builds against that knowledge without a discovery phase, and the loop between the person with the problem and the person with the editor is minutes long.
03
The capability stays.
Your engineers learn how governed AI actually works, and that knowledge compounds inside the firm rather than inside a supplier. If you intend to be an organization that builds software, this is the argument that should win.
Where builds actually slow down.
THE REAL SEQUENCE · 02
Nobody fails at the first step. The pattern we see, and the pattern the research describes, is a working prototype that cannot get through a security review and then cannot get an owner. Each of these steps ends in a decision somebody has to make on the record.
- 01Days
The prototype
An engineer wires a model to a document store and shows it to the leadership team. It works. Everyone is pleased. Nothing about this step is hard, which is exactly why it is misleading about the rest.
GateDoes this survive contact with a real dataset and a sceptical user?Decides: the sponsor - 02The long middle
Identity, policy, metering, isolation
Sign-in with second factors. Roles and grants that change without a redeploy. A content policy the calling application cannot switch off. Per-person quotas that fail closed. An audit record. Somewhere for business applications to run without reaching platform data. This is the platform, and it is most of the work.
GateCan your security reviewer scope the data flow and sign it?Decides: the security owner - 03Ongoing
Release tooling and evidence
Deployments from a tagged release and a clean checkout. Drift checks before changes. Acceptance scripts that exercise the running system after a deploy. A controls matrix somebody can hand to an auditor. Without this you have a system that works and no way to prove what it was doing last quarter.
GateWho signs that the deployed system matches the documented one?Decides: your platform owner - 04Forever
Keeping up with the market
Model families are replaced, prices move, regions gain and lose routes, a provider changes retention terms. Each event is a small piece of work and they never stop arriving. This is the cost nobody budgets, because at the prototype stage it does not exist.
GateIs this on somebody's permanent job description, or nobody's?Decides: the executive sponsor
What the research says, with its own caveat
MIT's Project NANDA, in "The GenAI Divide: State of AI in Business 2025" (July 2025), reported that of organizations evaluating enterprise-grade AI tools, custom or vendor-sold, "60 percent of organizations evaluated such tools, but only 20 percent reached pilot stage and just 5 percent reached production", attributing most failures to "brittle workflows, lack of contextual learning, and misalignment with day-to-day operations". The same report put internally built tools at about 33% reaching deployment against about 67% for external partnerships. Both figures carry the authors' own caveat: "directionally accurate based on individual interviews rather than official company reporting", from 52 interviews and 153 survey responses, and the report says the correlation "does not necessarily prove causation". We cite it because it matches what we see, not because it proves anything about us.
Eight things you would have to build.
THE INVENTORY · 03
| Platform component | What it has to do | What exists already |
|---|---|---|
| Identity and sign-in | Hosted sign-in, second factors, a user directory, session handling that a reviewer accepts | Hosted sign-in with PKCE, tokens in httpOnly cookies, passkeys and TOTP self-service, directory in your account |
| Policy enforcement | A content policy no application can bypass, plus denies on region, route and retention | Mandatory on every inference call, enforced by cloud identity policy as a deny. Tests fail the build if a deny is weakened |
| Policy versioning | Knowing which policy applied to an answer six months ago | A pinned, numbered version. A change forces a new version |
| Model access | A catalogue that tracks the provider, with residency classification and refusal rather than silent rerouting | Generated from the live catalogue, classified by where inference runs. Refusal in words when a region has no route |
| Metering and quotas | Per-person usage settled against the provider's own record, quotas that fail closed | Reserve and settle per person, tokens only. Home region today, and a failed settlement overstates rather than understates |
| Administration | Users, roles, grants editable at runtime, an access matrix, audited reads of someone's transcript | All of it, with the limits fixed at deploy time: nothing in the running system can create a role |
| Module isolation | Somewhere business applications run without reaching platform data | Own origin per module, per-request content security policy, 5-minute assertions, 15-minute credentials tagged to a named person |
| Release and evidence | Reproducible deploys, drift checks, acceptance tests against the live system, a controls matrix | Tagged release and clean checkout enforced by the factory, discovered architecture reconciled against the diagram, 17 mapped control rows |
A competent team can build every row. The question for your sponsor is whether these eight rows are the product your organization intends to be in the business of maintaining, and what they displace on the roadmap while they are being built.
When you should build.
THE CONDITIONS · 04
01
You already run a platform team.
Not one engineer with spare capacity. A team that owns internal services, carries a release process, and has absorbed this kind of work before without it becoming somebody's evening. If that team exists and has room, the marginal cost of one more internal platform is far lower than it looks from outside.
02
The capability is the product.
If what you are building will end up in front of your own customers, or is the thing you compete on, it belongs inside. Nobody should outsource the part of the system their market judges them by. Buy the foundation if you like, but own that layer.
03
Your constraints are unusual.
An air-gapped environment, a jurisdiction with no compliant managed route, an obligation that no standard posture satisfies. When the requirement is genuinely outside what a productized deployment does, a bespoke build is not indulgence, it is the requirement.
04
You have already started.
If the identity, policy and release layers are done and working, finishing is usually cheaper than switching. The conversation worth having then is narrow: which specific pieces are missing, and is any of it worth taking from somebody who has already built it.
Deployed by us. Owned by you.
THE MIDDLE PATH · 05
The choice is usually put as build or buy, and it is a false pair. The arrangement we run is closer to a build you did not have to staff: the platform is deployed into a cloud account you own and are billed for directly, and if the relationship ends you keep the deployed platform and its source. The monthly fee buys the service, not access to your own system.
If your AI vendor disappeared tomorrow, would anything still run? With us, you log into your own cloud and keep running.The test we would want you to apply to every option on this page
01
What you own.
The cloud account, the credentials, the billing relationship, the data at rest and the deployed platform. Infrastructure as code and runbooks are delivered as deliverables, not as favours, precisely so that taking it over is a real option rather than a comforting sentence in a contract.
02
What it honestly takes to run it.
A competent cloud engineer. Nobody should tell you a business can operate this with nobody technical. The takeover is a staffing decision you can make later rather than a rebuild you have to fund now.
03
Where it is not portable.
It is deeply built on one cloud provider. Moving to a different one would be a rebuild, not a migration, and anyone who tells you otherwise is selling. Composable refers to models: switching the model behind the application layer is configuration. The distinction matters.
01Could our team take over the deployment later?
That is the design intent. You hold the account and the source, the infrastructure is code, and the runbooks exist for exactly this. It needs a competent cloud engineer and a handover, scoped properly rather than assumed. Ownership and exit sets out what transfers.
02Can our own developers build on top of it?
Yes, and it is the most interesting thing about the platform. There is an authoring kit, a manifest contract at schema 1.1, a validator and a scaffold, with promotion to production gated on a named administrator approving an exact artifact hash. The path is proven end to end by us acting as the client; the first client-authored build is in pilot. See developer modules.
03What if we build and it goes wrong halfway?
Then you have learned exactly which layers are hard, which makes the second conversation far better than the first. Bring the architecture to the assessment. The deliverable is a topology and data-flow map you keep regardless, and it is just as useful applied to something you built as to something you are buying.
04Is your platform open source?
No. It is a commercial product deployed into your account, with the source delivered to you as part of the engagement. That is a different arrangement from open source, and worth naming precisely rather than borrowing the word.
⎯⎯ Book the strategic assessment ⎯⎯
Your private AI, inside your control ·
Bring your architecture, finished or half-built. The assessment maps it and says plainly which parts are worth buying and which are worth keeping.