A tour of the 16 generators: the boring-but-critical stack, in one place

When we started Avery NXR, we made a list of every Next.js application the team had built or shipped in the previous five years. About forty projects, across startups, agencies, and side projects.

We wrote down what each project's first ten engineering tasks looked like. The list was nearly identical every time.

Set up auth. Wire up Stripe. Build the dashboard layout. Add a few CRUD pages. Set up a job queue. Add transactional emails. Add file uploads. Add search. Set up an audit log. Wire webhooks. Add feature flags. Add roles. Add API routes. Build forms. Add a settings page.

That list became the spec for the first sixteen generators.

Why generators, not templates

A template gives you a finished app you have to delete most of. A generator gives you a working subsystem you can compose with the others.

The difference matters because real applications are not "an auth template with a CRUD bolted on." Real applications have auth that knows about the CRUD models, billing that knows about the auth, dashboards that know about all three. A generator system lets the pieces compose. A template system makes you re-do the integration by hand.

Each of the sixteen generators is independently runnable, but they know about each other. The auth generator emits the user model that the CRUD generator references. The billing generator hooks into the auth roles. The audit-trail generator instruments every other generator. The composition is the product.

The sixteen

Auth — Email, Google, and GitHub OAuth out of the box. Sessions in cookies, JWTs as an option. Role-based access control. Magic links. Password reset. Two-factor as a flag.

Billing — Stripe with Checkout and Customer Portal. Subscription plans, one-time payments, metered usage, webhooks all wired. The billing model knows about the auth roles.

Dashboard — Sidebar plus topbar shell, dark mode default, responsive. Layouts for list, detail, and form pages. shadcn/ui components throughout.

CRUD — Database model, API routes, list and detail pages, forms, validation, optimistic updates. You name the model, the generator writes the stack.

Background jobs — A queue backed by Postgres (no Redis required for the default), with cron-style schedulers and retry policies. Workers are TypeScript functions, not YAML.

Emails — Transactional via Resend by default, templates as React components, preview UI for development. The auth and billing generators emit emails through this.

File uploads — S3-compatible (R2, S3, MinIO), with signed upload URLs, image processing, and a drag-and-drop component. No multipart parsing in your route handlers.

Search — Full-text search across whichever models you opt in. Postgres tsvector by default, with a swap path to Meilisearch or Typesense.

Admin panel — A generated admin UI for the CRUD models, behind a role check. The kind of thing every project needs and nobody enjoys building.

Webhooks — Inbound webhook receivers with signature verification (Stripe, GitHub, Slack patterns built in) and outbound webhook delivery with retry.

Feature flags — Server-side flags with environment-based defaults and per-user overrides. Toggle without a deploy.

Roles and permissions — RBAC with a default role hierarchy. The CRUD, admin, and billing generators all check against this.

Audit trail — A per-model change log that captures who changed what, when, and why. Pluggable into the audit ledger.

API routes — REST and tRPC scaffolds for every CRUD model. OpenAPI spec generation included.

Forms — Forms with validation (Zod), error display, and submission state, all typed end-to-end against the CRUD model.

Settings — A user settings page covering profile, password, email preferences, API keys, and billing — wired into the corresponding generators.

What's not in the sixteen

We were deliberate about what didn't make the cut.

We did not build a generator for analytics. Real analytics tools (PostHog, Mixpanel, Plausible) are better than anything we would generate, and integrating them is two lines of code.

We did not build a generator for AI features. Those are the business logic of an application — they are the thing you are building. We are not in the business of generating your differentiation.

We did not build a generator for marketing pages. The landing page of an app is not infrastructure. It is design and copy, and it should not look like every other generated landing page on the internet.

The sixteen are the things that every project needs, that nobody wants to think about, and that should look the same in every well-built application.

What comes next

We have a working list of the next eight generators, queued for the months after launch. The shortlist includes notifications (in-app plus push), real-time collaboration primitives, multi-tenant isolation, and on-device telemetry for the local model.

We will add them when they are good. We will not ship sixteen more generators in the next six weeks just to have a bigger number on the homepage.

The first sixteen are what every project needs. Getting those right is the whole game.