Avo: building a zero-maintenance Rails admin framework that teams actually keep (16 months)
Co-founded an open-source admin framework for Ruby on Rails, still shipping at avohq.io. Configuration-based, no code generation, designed so teams can extend it without owning it.
- Ruby on Rails
- Hotwire / Stimulus
- Tailwind
- PostgreSQL
Challenge
Every Rails team reaches the same moment. Some part of the product needs an admin panel, and the existing options are not great. Generate scaffolding and spend the next two years maintaining code nobody wrote on purpose. Or pull in a framework that becomes its own ecosystem, with its own upgrades, its own conventions, its own bugs.
The pattern was consistent: teams picked an option, lived with the maintenance burden for a year, and either abandoned it or rewrote it. There was no third path: something you describe, not generate; something Rails-native enough that a senior engineer feels at home; something with an escape hatch that doesn't require rewriting when you outgrow a screen.
Solution
We built Avo as a configuration-first Rails gem. The key design decisions:
- Describe, don't generate. Avo resources are Ruby classes that describe fields, actions, filters, and permissions in a DSL. No generated files sitting in the codebase, no divergence between the gem version and what was generated at install time.
- Rails-native, Hotwire-first. Avo uses Turbo and Stimulus so interactions feel snappy without a SPA. A Rails team does not need to learn a new frontend stack to extend or override anything.
- The escape hatch is free. Every Avo resource maps to an ordinary Rails controller action underneath. If you outgrow a screen, you drop into Rails, not into a new templating language.
- Ship the boring parts by default. Auth, roles, filters, search, CSV export. Every admin needs these. Avo includes them so teams do not reinvent them, project after project.
We completed YC Startup School during the build. It was an external forcing function for scope discipline and launch cadence.
Getting an admin panel
Before
Generate scaffolding and maintain code nobody wrote on purpose for two years, or pull in a framework that becomes its own ecosystem with its own upgrades, conventions, and bugs.
After
Describe admins in a Ruby DSL. No generated files in the codebase, no divergence between the gem version and what was generated at install time.
Outgrowing a screen
Before
Teams picked an option, lived with the maintenance burden for a year, and either abandoned it or rewrote it. No third path that did not require a rewrite.
After
Every Avo resource maps to an ordinary Rails controller action underneath. If you outgrow a screen, you drop into Rails, not into a new templating language.
No usage numbers are published or invented; the difference is qualitative.
Results
Avo shipped as an open-source Rails gem. It is still actively maintained and growing at avohq.io, five years after the initial build, which is the real proof-of-concept for a zero-maintenance-on-the-user-side framework.
The gem grew a plugin ecosystem, documentation, and a community of Rails teams using it in production. It is endorsed by the broader Rails/Hotwire community as an idiomatic option for teams that want an admin without owning one.
No usage numbers are available to share: the project is open-source and self-hosted by adopters, so download counts are not a meaningful measure of production use. The proof is that the gem still ships.