What it does

avo-dynamic_collections

Spin up a brand-new Avo resource from inside the app, no model, migration, or code deploy. Add a record in the Collections menu and Dynamic Collections defines the model, the Avo resource, and the controller for you at runtime, then reloads the routes so the new resource appears in the menu with full CRUD a moment later.

Every collection's records live in one shared entries table (title, slug, and a JSON data column), and each entry carries an avo-meta panel so you can attach custom meta fields without a schema change. Rename a collection and the menu entry swaps cleanly; remove it and its resource and routes disappear. The setup survives boot and code reloads, so what your team builds in the UI stays put. That is a whole admin-authoring layer already built and vetted, so your agent configures it instead of generating it.

See it in action

What you get

Create and manage collections from a Collections menu entry, no code
Each collection becomes a live Avo resource, model, controller, and routes defined at runtime
Full CRUD on the new resource the moment it is created, no app restart
Entries stored in one shared table with title, slug, and a JSON data column
Per-entry meta fields through avo-meta, no migration to add them
Rename or delete a collection and its menu entry, resource, and routes update cleanly

Why it pays off

Let your team stand up a new resource in the UI this afternoon instead of writing a model, migration, resource, and controller for every one.
Defining constants, reloading routes, and surviving code reloads without leaks is fiddly metaprogramming. Those decisions are already made, reviewed by people, and running in production apps.
It keeps improving underneath your code as Avo and Rails move, so the runtime-resource engine stays current with bundle update.
Bugs in the dynamic-define and teardown path are our code in our domain, so we fix them once for everyone.