What we learned building Automo on Automo Build

I have lost track of how many times someone on the Automo team has hit Publish and watched the deployment plan surface a decision the team had never made out loud.

Automo runs as several services. Each one has its own deploy lifecycle. Some of those services talk to tenant databases in different regions, because some customers contractually require their data to never leave a specific jurisdiction. There is no version of “just press deploy” for Automo. We cannot operate without help.

Pressing Publish in Automo does not push code. It starts a three-stage process. An algorithm walks the change set and the full dependency tree, and produces the list of modules that actually need to ship. An agent reads that list and drafts a deployment plan: which versions are coming, what shifts as a side effect, what the team should think about before approving. Then the human and the agent talk it through. The agent can show its work for any item on the plan, down to the commit and the prompt that produced the change.

That conversation has saved us more times than I can count. A migration about to run against the wrong region. A version bump that would have invalidated cached state across half the customers.

The plan surfaces the questions the team should have been asking and was not. That is why we run Automo on Automo Build.

Why we run Automo on Automo Build

We don't run Automo on Automo Build because we have to. We could host Automo any way we want. We run it on Automo because nothing forces honesty about a platform like betting your own production app on it.

Every shortcut we'd ever consider letting slide in someone else's codebase, we cannot let slide in our own. Every feature we'd ever consider half-finishing, we are the first to hit when it breaks.

The pitch deck calls this “dogfooding.” The day-to-day reality is more like a forcing function. The platform that ships Automo is the platform agencies are going to ship their own production work on. Anything less than that would be dishonest.

Here are four things running Automo on Automo Build has taught us. Each one is now baked into how the platform works for everyone.

1. Guardrails train the team

When we first set up Guardrails on the Automo workspace, the assumption was that they would protect us from the AI. The AI does not know which parts of the codebase are sensitive. We do. We mark them: billing logic, auth boundaries, secrets, schema changes, customer data, tenant isolation. The AI asks before it touches any of them.

What we underestimated is what guardrails do to a team. The approval flow is now the surface where the team trusts each other. It is also where any new contributor learns where the sharp edges of the codebase live, on their first day, without anyone having to tell them. The guardrail definition is the documentation of where care is required.

When an agency onboards a junior, an intern, or a contractor onto their Automo workspace, the guardrails do the work that a senior engineer would normally do by hovering. They turn institutional knowledge into a structural property of the codebase.

2. We ask Doctor

A customer writes in: “you changed something about the export and our integration broke.” The old answer to that kind of question used to take half a day. Search the diffs. Track the deploy. Ask the engineer who shipped it. Find the prompt. Reconstruct the intent.

We don't do that anymore. We ask Doctor.

Doctor is a project agent we built into Automo. It reads from every audit source a change could have come from: Git, Automo's own change history, Supabase, sandbox logs, deployment logs. The audit log is one input among many, not the answer surface. We don't open log viewers and filter. We forward the customer's question to Doctor and Doctor comes back with what changed, when, why, who approved it, and where the related state lives. No archaeology.

What makes this matter for a team is bigger than the thirty-second response time. It is the ability to answer questions about changes nobody currently on the team made, including changes the AI made on its own, without needing the engineer who shipped them to be available.

For an agency, that is the difference between a client conversation that closes inside an hour and one that drags through a week of internal forensics.

3. Why we said no to manual merge

Two of Automo's engineers, Gabriel and Vlad, kept asking me to add manual merge and squash commits to Automo. I kept saying no. Not because we couldn't ship them. Because that is not how I think we are going to work with AI.

So I dug into what they actually wanted.

Gabriel wanted to spawn five variations of a feature, try each one, pick the best, then bring it to the team. He was reaching for git tools because those were the closest thing he knew to “let me experiment cheaply.” That instinct is right. The tools were wrong.

Last week we released subagents. Subagents are ephemeral parallel work surfaces. The underlying tech is similar to git worktrees, with some moves of our own on top. The usage is different: they exist for experimentation, not for production tracking. They are not bound to git's commit and merge model.

Gabriel's workflow now: branch first, then swarm subagents into the branch. Run five experiments in parallel. Keep the one that holds up. Throw the other four away. Only then does the work touch the team's main flow.

The lesson sits at the workflow layer. AI moves too fast to be constrained by git's commit-by-commit ergonomics. Branches are still load-bearing for us. Automo uses remix branches every day for work that needs to land in production. The actual experimentation layer is now somewhere else.

For an agency this is what AI-assisted engineering looks like at the workflow level. Shipping in branches, exploring in subagents. The agency that runs both moves at a different cadence than the one still working through one commit at a time.

4. Most of the time, we roll forward

The honest version of our rollback story is that we don't roll back very often. Automo's development pace has accelerated to the point where shipping a small fix on top of the bad deploy is usually faster than reversing it.

That does not mean rollback doesn't matter. It matters at a layer below the deploy decision itself. The deploy decision is cheap because rollback exists as a one-click action sitting underneath every deploy. The team ships smaller increments and ships them more often because the worst-case cost of getting one wrong is bounded.

When we do need to roll back, the platform handles the parts that are normally awkward. Frontend and edge functions revert instantly. Database schema gets a compatibility analysis: in most cases the previous version runs cleanly against the current schema, so the rollback doesn't touch the DB at all. When it does have to touch the DB, the platform shows the team exactly where and why, so the decision is informed instead of guessed.

The hardest part of rollback has always been the question “will the old code work against the new schema?” Most teams answer it by panicking. We answer it by reading what Automo tells us.

For an agency, this is the difference between a deploy the team treats as routine and a deploy the team treats as a Friday-afternoon nightmare. Once routine deploys are real, the cadence of the agency changes.

The point of running on our own platform

The four lessons above are operational realities. We ship AI-engineered software for paying users every day. These are the moves that make that possible.

The reason it matters is the meta-lesson: we built the tool we wished existed when we were running an agency. The proof that it works is that we use it for our own production product.

There are AI builders that look impressive in a demo and that none of the team behind them would dare run their own business on. We notice. Anyone who looks closely enough notices.

We built Automo the way we wanted to use it. We use it the way we want our customers to use it. The features on /agencies are the ones we needed last Tuesday, and last week, and the week before that. They are what agencies look like when they finish graduating from drag-and-drop.

The pick

If you are an agency owner trying to decide whether AI-generated software is something you can put your name on for a paying client, the test is straightforward.

Look at the team that built the platform. Ask what they ship with it themselves. If the answer is a demo, a marketing site, or “internal tools, mostly,” you have your answer.

If the answer is a real production product carrying paying customers, then you have the only proof that matters. We can keep telling you that Automo is safe to ship from. The team running Automo every day is the one actually answering the question.