You're not building just one app. You're building two.

the app behind the app

One app faces your customers. The other never stops changing.

The first app is the product people pay for, the public-facing one you obsess over. The second is the internal tooling behind it: the admin panels, the dashboards, the CRUD screens your team lives in every day. It's never finished. Every new model, every new team, every "can you just add a screen for this" grows it again. So while the product ships and stabilizes, the second app keeps demanding your attention forever.

No company ever won its market because the admin panel was great. Every hour on that second app is an hour not spent on the one people pay for. Build it from scratch and you carry two apps. Build it on Avo and most of the second one is already there. Already carrying an old admin? Retiring it is about a week of work, not a quarter.

"just have the agent build it"

You can generate the admin. Don't start from zero.

Point an agent at a blank app and it builds the same foundation every admin needs, then builds it again, a little differently, in the next app. This is what it regenerates each time, and what you review from scratch each time.

1. SEC

   The access-control layer

   Who can load which records, who can see which attributes, who can run which actions. Scoped queries, mass-assignment protection, file and association permissions, and the same answer whether the request comes from a screen, an API call, or an agent. It's the code you can least afford to get subtly wrong, and generated fresh, it's the code you have to review hardest.

2. BUG

   The edge cases

   Nil, empty states, pagination, timezones and DST, money rounding, every Rails association type. N+1 queries and unindexed lookups that pass in dev and fall over at real volume. Destructive operations that need a confirmation, a soft-delete, an audit trail. None of it shows up in a single-user demo, and all of it has to be prompted for, one case at a time.

3. DEBT

   The consistency

   Every screen, and every app, ends up with its own version of the same pattern, so there's no single place to fix anything and nothing learned in the last app carries into the next. One-off dependencies bolted on per project. Upgrades that land on each admin separately, if they land at all.

4. GAP

   The stuff you'd have to ask for

   Select-all across the whole filtered query, not just the visible page. An extra confirmation on the models that deserve one. Sane guardrails on bulk actions. These are the taste decisions that keep an admin safe to use, and they only get built if you already knew to ask.

None of this is an argument against agents. Everybody codes with them now, and so do we. It's an argument about what they build on: this foundation is the same in every app, so it shouldn't be new in every app. Avo is the foundation your agents build on.

where Avo comes in

Build on a foundation that's already there

The decisions are already made, tested in production, and hardened, and still yours to override. We use AI to move faster too, and every release is reviewed by the Avo team and vetted across hundreds of customers' apps before it reaches yours. Your agent writes a short Ruby resource on top, and it keeps working as the foundation improves underneath it.

the app you ownthe app Avo owns, filled in

And because Avo is conventional and documented, with skills shipped inside the gem, the knowledge lives in the framework, not in one person's head or one long chat. Any Rails developer, and any agent session, is productive on day one. The same foundation in every app, and one app to maintain instead of two.

it comes down to three things

Time, Trust, and Taste