Armada: Make the Safe Path the Easy Path

People are going to build software with AI whether the technology team gives them a path or not.

That can be a very good thing. The people doing the work usually understand its problems better than anyone else. They see the awkward handoffs, repetitive steps, and missing information that an engineering team may never encounter. Great ideas can come from anywhere in a company, and AI app builders let people test those ideas without waiting for a place on the technology roadmap.

I want to encourage that. People should be able to move quickly, try things, and find better ways to work.

The complications start when an app needs to become something other people can use. At my company, these apps eventually reach the technology team with the same request: can you put this somewhere online?

Putting files on a server is the small part. The application needs company login, access control, secrets, infrastructure, a domain, and some assurance that it will handle data safely. Someone has to keep it running and deal with whatever breaks.

By the time we finish, a quick deployment has become a technology project. We also tend to find other problems while working inside the app, and engineers are not especially good at leaving known problems alone. The original request grows, and the team quietly inherits another application to support.

My team already owns the firm’s core platforms, data, integrations, and infrastructure. Rebuilding and supporting every AI-generated app is not sustainable.

My boss and I came to that conclusion at about the same time. There was no executive mandate or formal project request. We had simply encountered the same problem enough times to know that we needed another option.

I started building Armada.

The approved path has to be convenient

A company can write a policy telling people which tools they may use and where applications may run. Policies matter, but people still need to solve the problem in front of them.

If the approved route involves a project request, several meetings, and time on an already full engineering roadmap, people will look for something faster. AI app builders give them that alternative.

Armada is meant to make the governed option easier. It gives people a place to run useful internal apps without giving those applications unrestricted access to the firm’s systems. It also avoids turning every experiment into a permanent support commitment for the technology team.

The apps do not need to meet every standard expected of a core production system. They do need a controlled place to run.

A platform around the app

Armada does not prescribe what an application should do or which framework it should use. I am optimizing the deployment process around the kinds of projects that tools like Lovable and Claude Code usually produce, but the platform itself is broader than that. If an application can run in a container, Armada should generally be able to host it.

Every app runs behind the same gateway and uses the company’s existing sign-in. Its owner chooses who can access it and who may manage it. Armada provisions the cloud resources, stores secrets, exposes logs, and provides the operational controls around the container.

Applications will not receive write access to the firm’s systems of record. The planned warehouse connection is one-way: an app may request approved data, but it cannot update the systems that produced it. Apps that need their own data will receive isolated storage.

Outbound network access is denied by default. Server-side controls limit where an application can send data, and browser security policies restrict what its frontend can contact. Exceptions can be added deliberately when an app needs them.

This does not eliminate every possible risk. It gives us confidence in the environment around an app, which lets us host a much wider range of code than we could reasonably review, secure, and operate one app at a time.

The name came from the idea that every app is another ship joining the company’s fleet. One might be a dashboard and another might run an entire workflow. Armada does not care what job each one performs. Once an app joins the fleet, it gets the same security and infrastructure around it as the others.

The boundary is the important part

I own the common platform: authentication, isolation, infrastructure, secrets, networking, and deployment. The application owner remains responsible for what the app does and whether it is useful.

Hosting an application should not automatically make the technology team responsible for its business logic. If every upload creates another codebase that engineers must understand and support, self-service deployment has only moved the queue.

Armada enforces the boundary through the capabilities it gives each app. Authentication happens at the gateway. Apps do not receive credentials that can update shared firm systems. They do not share databases because that happened to be convenient during development.

App owners can move quickly without needing to understand the infrastructure underneath them. My team can manage the security and platform concerns without taking ownership of every application’s code.

Armada’s first app is Armada

The control panel is itself one of the apps running inside Armada.

It enters through the same gateway and runs through the same application model. It is subject to most of the same controls, but it has privileged access to Armada’s control database so it can manage permissions, secrets, and the resources allocated to the rest of the fleet.

This gives me an immediate test of the platform. The application responsible for operating Armada has to live inside the environment it manages. When the abstraction is awkward or incomplete, I encounter that problem before asking anyone else to build on it.

Turn an application into infrastructure

The deployment pipeline will include a deterministic parser that inspects the submitted application and determines which resources it needs. Its job is not to judge whether the application is worth hosting. It translates the shape of the app into a repeatable deployment plan.

An app that needs persistent storage should receive it. An app that only serves a frontend should not carry unnecessary infrastructure. The same application should produce the same resource plan every time it is inspected.

The parser can also catch problems before deployment. When it finds one, Armada should tell the maintainer what failed, the common reasons it happens, and what to ask their AI coding tool to change.

The maintainer can take that guidance back to the tool that built the app and submit the corrected version. Armada remains deterministic about infrastructure and security while still fitting naturally into an AI-assisted development workflow.

Support needs a boundary too

Owners can already view their application’s logs and restart it through the control panel. Access management also stays with the person who understands who should use the tool.

The deployment workflow will add code versioning so an unsuccessful update can be rolled back. The owner should get the operational benefits of version control without needing to learn Git before they can maintain an internal app.

The application can be as simple or complicated as its owner needs. Armada handles the infrastructure around it so every builder does not have to become a cloud engineer.

Some apps will still need help. The goal is to make routine deployment and operation something the owner can handle without automatically adding the app to the technology team’s workload.

Let ideas prove themselves

Armada also creates a way to learn which apps are genuinely useful.

Usage analytics come later in the current plan. They will show whether an application is being adopted and whether people continue using it after the initial excitement wears off.

An app with a small audience may be perfectly successful as an owner-supported tool. An unused app can be retired without the firm having invested in a full engineering project. If an application becomes widely used, we have evidence that the underlying idea may deserve real development and support.

That does not mean the existing code automatically becomes a supported production system. It means the technology team can make an informed decision about investing in the problem. We can design the supported system with the architecture, testing, data model, and ownership that its importance requires.

My experience building CARL reinforced that AI does not remove the need for technical ownership. Armada does not change that conclusion. It gives people room to build and experiment without treating every app as a new core system.

The humans are part of the system

Armada has plenty of conventional platform engineering in it: containers, identity, networks, databases, and cloud infrastructure. Those pieces alone will not determine whether it works.

People choose tools based partly on convenience. If the secure option is consistently slower and more difficult, some people will go around it. That behavior is part of the system whether or not it appears in an architecture diagram.

The same is true on the technology side. Engineers tend to fix the problems they find. Without a clear support boundary, a request to host an app can easily become responsibility for improving and maintaining it.

Armada is designed around both groups. App builders get a faster route from idea to something their coworkers can use. Engineers retain control of the infrastructure and security boundary without taking ownership of every application.

Longer term, I would like to move more of the building experience inside that boundary as well. A managed creation environment could apply the platform’s rules from the beginning rather than waiting until someone asks to deploy an app built elsewhere.

For now, the first priority is making Armada easier than the alternatives. Governance works better when following it helps people accomplish what they were trying to do.

Where it stands

Armada is very new and moving quickly. No real user application is live on it yet.

The gateway and company SSO work. The control panel runs inside Armada. App access, management permissions, secrets, cloud-resource provisioning, logs, and restarts are in place. I recently finished the first work needed to deploy application code, but the complete deployment and versioning workflow is still under construction.

Usage analytics, approved warehouse reads, and isolated app-local storage come later in the plan.

I have designed, planned, and implemented Armada end to end. I am building it alongside my ongoing work across VAMOS, Salesforce, CARL, and the rest of the firm’s technology platform. That workload is one reason this problem needs a platform solution. We cannot keep scaling by manually absorbing every tool people create.

The apps themselves are worth encouraging. They let people closest to a problem test an idea and show what better could look like. Armada gives them somewhere to do that without asking the technology team to rebuild every app or accept risks we cannot see.

People will use the path that helps them make progress. I want Armada to make that path secure by default.