Problem
Anyone building an internal AI tool chose their own stack and solved sign-on, access, data and delivery before their own problem. Then there was nowhere to put the result, so working tools stayed on laptops.
Solution
One template that settles the stack and starts every application at production grade, and one platform that carries it from a laptop to production behind a single intake and approval gate.
- Sign-on, access control, versioned migrations, a governed model route and a delivery pipeline arrive with the template.
- Applications never hold model credentials: one issued token each, every request through the platform.
- Four checks before any platform time is spent, then tiering by consequence.
- The platform was built together; the gate, the onboarding and the training sit with one owner.
Every team was building the same thing again.
Anyone who wanted an internal tool had to solve the same problems before they could solve their own: how people sign in, who is allowed to see what, where the data lives, how any of it reaches a server. Every project paid that cost again, and each of them paid it slightly differently.
So the question stopped being how to build another tool, and became what every tool should be allowed to assume.
One template, and you start at production grade.
Instead of an empty repository, a team starts from a template that already holds the parts nobody should build twice: single sign-on, role based access, a database with versioned migrations, a governed route to the models, containers, and a delivery pipeline.
The guardrails arrive with it. The template also carries the rules for working inside it, so the constraints live in the codebase rather than in somebody's memory.
Anatomy of one application
- The team's own featuresthe only layer a team writes
- Interface shell and navigationalready wired to the identity layer
- Sign-on and role based accessdeny by default, roles from the directory
- Data layer with versioned migrationsone database per application
- Governed route to the modelsno credentials held by the application
- Containers and delivery pipelinethe same path for every application
The rules for working inside the template ship with the template, so the constraints live in the codebase.
The applications stay simple because the platform is smart.
No application holds its own model credentials. Each is issued a single token when it is deployed, and every request it makes to a model goes through the platform.
That one decision buys three things at once. An application can stay simple. The estate can be audited down to who asked for what, and what it cost. And an integration can be built once for everyone instead of once per tool. It is a factory in the useful sense: the line is the product, not any one thing that comes off it.
Where the intelligence sits
Applications
Application
features only
Application
features only
Application
features only
Platform core
- Identity
- Access control
- Secrets
- Model route
- Audit and metering
- Shared integrations
One issued credential per application
Beyond the platform
Models
reached only through the core
Systems of record
integrated once for everyone
A business user can ship to production without touching a server.
Merging a change is the last manual step. After that it is checked, built, packaged and shipped down the same path every application uses, into three isolated environments, with an approval standing between the last of those and production.
The point is not the automation. It is that somebody who is not an engineer can make a real change to a real tool, put it in front of real users, and still not be able to damage the platform underneath it.
From a change to production
The person
- Merge the changethe last manual step, and the only one a builder takes
Automatic
- Checks and tests
- Build and package
- Versioned image, stored once
Environments
- Developmenton merge
- Stagingpromoted
- Production
Approval before production
Not everything gets built.
Four questions come first: is this a duplicate of something that already exists, who will actually use it, what is it worth, and what will it cost to run. Applications are then tiered by how much damage they could do, so a personal script and a system holding production data are not held to the same standard.
The rule is that a team reconciles its own codebase against the template rather than handing it over to be fixed, and the process settles who supports an application once it is live. That discipline is what let the rest of it scale.
The gate
Anyone can ask for an application.
Duplicate
does this already exist, or extend something that does
Users
who will actually use it, and how often
Value
what is the work it removes worth
Running cost
what will it cost to serve once it is live
Then tiered by consequence
- Personal
- Team
- Department
- Business critical
A returned request keeps its place: it comes back with what is missing, not a refusal.
Teams queued to build on it.
Once other parts of the business could see a route to production that already had sign-on, access control and a governed way to reach a model, they stopped asking for their own infrastructure and asked to be let in. Each team arrived through the same onboarding, with training built for people who do not write software for a living.
One of the applications on the platform is now used by hundreds of people across two continents. The constraint stopped being whether a team could build something, and became which requests were worth a very small core team's attention. That is what the gate is for.
Selected technical detail
- Infrastructure as code with isolated state per application, so one team's deployment cannot disturb another's.
- Containers built and versioned in a pipeline, promoted through three environments, with a manual approval before production.
- Single sign-on and role based access inherited from the template, and one issued credential per application for all model access.
Why the gate exists
- Requests arriving
- Capacity to serve them
(illustrative)
Teams across the business now ship internal AI applications on shared rails, through a single gate.
Building AI capability inside financial services?