Armada: What Happens When Everyone Can Build Software

Something changed at work over the last year. People who have never written code started showing up with working apps. Not mockups, not feature requests. Working prototypes, built with AI app builders, that solve real problems in their corner of the firm. A workflow tracker here, a data dashboard there, each one built in an afternoon by the person who actually has the problem.

This is great. It’s also a problem, because every one of those apps eventually lands at my team’s door with the same question: can you put this somewhere the rest of the team can use it?

Until recently the honest answer was “not easily.” Deploying an app the traditional way pulls the tech team in for hosting, login, access control, security review, and an unspoken agreement that we now co-own the thing forever. We’re a small team at a roughly 200-person wealth-management firm regulated by the SEC. We manage the firm’s core platform, its data, its integrations, and a roadmap of our own. Our capacity for hand-deploying a stream of prototypes is zero.

The standard menu here has two options. Option one: say no. Safe for us, but it throws away real value, and people don’t actually stop. The app lives on somebody’s laptop, the data moves around in email attachments, and the problem gets worse while looking solved. Option two: absorb it. Take each prototype in, rebuild it properly, own it forever. That’s how a five-app queue becomes a two-year backlog.

Nobody asked us to solve this. There was no executive mandate and no incident forcing our hand. We watched the queue start to form and decided to build the third option before option two buried us.

The third option

Armada is an internal platform that deploys these apps without my team in the loop. One gateway, so everyone signs in once with their normal company account. Every app runs isolated in its own container on its own subdomain. The owner decides exactly who can use their app and grants access themselves. Deploying is uploading a zip file, and the app is live in minutes.

The pitch to a builder fits in a sentence: paste our instructions into your AI tool, build your thing, upload it. The instructions tell the AI how to fit the platform. Read the user’s identity from the headers we send. Never build a login screen. Ask for warehouse data through our query API. It turns out AI tools follow a spec like that very reliably, so apps arrive already compatible instead of needing translation by an engineer.

The boundary is the product

We’re a financial firm. These apps will touch sensitive data, and designing as if they won’t is designing for a fantasy. So the core of Armada isn’t a feature. It’s a responsibility boundary: my team owns getting an app safely onto the network, meaning sign-in, access control, encryption, isolation, and secrets. The app’s owner owns what the app actually does.

Plenty of companies write that boundary into a policy document. The difference here is that the architecture enforces it.

An app can’t skip authentication, because the only network path to any app runs through a gateway that requires sign-in first. There’s no door to leave unlocked.

An app can’t quietly send data somewhere it shouldn’t, because outbound traffic is blocked by default, on the server side and in the browser. If an AI tool bakes a call to some external API into the code, that call simply doesn’t fire.

“Your app cannot leak data” is a much stronger sentence than “please don’t leak data.” That difference is most of the reason a platform like this can exist at a regulated firm.

The human half of the boundary is just as deliberate. Creating an app means checking a plain-language attestation: you own what your app does with data, and we own getting it on the network safely. It’s logged with a timestamp. If a regulator ever asks who was responsible for a given app, there’s a record with a name on it, and everyone knew what they were agreeing to when they clicked.

Designing for zero tickets

The premise fails if every deployed app generates support tickets, so a lot of the design is about keeping humans (specifically, my humans) out of the loop.

Errors that fix themselves. Every deploy is scanned and checked automatically, and plenty will fail on the first try. We write every failure message so the owner can paste it straight back into the AI tool that built the app. The AI fixes its own mistake, the owner re-uploads, and they’re unblocked in minutes instead of waiting on us. The standards still get enforced on every single deploy. We just put our effort into building the checks once instead of reviewing every upload by hand.

Hide the git. Under the hood, every deploy is versioned in a real repository with full history and one-click rollback. On the surface, the owner clicks “upload new version.” We get the audit trail and the undo button. They never have to learn version control, because teaching version control to financial advisors is a project I do not want.

Self-service operations. Owners see their own app’s logs and health from the portal, and get a restart button. Routine problems don’t need a ticket, and the fix sits with the person who cares most about the app being up.

A pre-agreed kill criterion. Every app’s page shows its usage: unique users and last accessed. If an app has had three visitors in sixty days and two of them were the owner, the number is right there saying what nobody wants to say in a meeting. We agreed up front that resources follow usage. Nobody on the platform team has to play villain. The dashboard does it.

Where it stands

Armada is mid-build. The gateway, the control plane, and the portal exist and work. The deploy pipeline and the hardening around it are in progress, and the first real apps haven’t moved in yet. I’m writing about it now anyway, because the interesting part isn’t the launch. It’s the shape of the problem.

Every company is about to have this problem, if it doesn’t already. AI tools moved the bottleneck. The people closest to the work can finally build the software they need, which means the constraint is no longer writing apps. It’s deploying them responsibly. You can meet that with “no” and get shadow IT. You can meet it with heroics and drown. Or you can build the paved road: make the safe path also the fastest one, and let the guardrails come along for free.

That’s the bet we’re making. I’ll write a follow-up when the first fleet of apps is live and we find out how much of this survives contact with real users.