Opinionation as a feature: why we built Avery NXR for one stack

There is a temptation at every dev tool company that goes like this.

We started by supporting one stack. Users love it. Now there are users asking for a second stack — please support Remix, please support Astro, please support SvelteKit. The team huddles. The argument for adding the second stack is straightforward: more users, more market, more growth.

The argument against is harder to articulate. It sounds like resisting growth. It feels like leaving money on the table. But the argument against is, for a tool like Avery NXR, almost always right.

The cost of generality

Every dev tool that tries to support every stack ends up in the same place. The tool is wide. The tool is shallow. The tool generates code that technically works in every framework but is idiomatic in none of them.

You can see this in the long tail of "framework-agnostic" code generators. They emit a CRUD layer that looks vaguely like every framework and like none of them. The auth flow has been refactored to use generic concepts that don't map cleanly onto NextAuth or Lucia or Better-Auth or whatever the user is actually running. The forms are validated through an abstraction that ignores the framework-specific form library the user expected. The whole tool feels like almost the right tool, but not quite.

This is not a failure of execution. It is a failure of strategy. Generality and idiomaticness are in tension. The more frameworks a tool tries to support, the further its output drifts from what any single framework's community considers the idiomatic answer.

For a code generator, idiomaticness is the product. Code that works is the floor. Code that looks like a senior engineer in that specific framework wrote it — that is the ceiling, and it is what users actually want.

What we picked, and why

Avery NXR generates Next.js (App Router, version 14+), Prisma, and TypeScript. That is the entire menu.

Next.js is the framework. Not because it is universally the best — there are real arguments for Remix, for SvelteKit, for SolidStart — but because it is the framework with the largest community, the most well-trodden patterns, and the most stable conventions for the kind of app most users want to build. The probability that a developer's "I want to ship a SaaS app" use case is well-served by Next.js is the highest of any framework on the market today.

Prisma is the ORM. Not because there are not strong cases for Drizzle, Kysely, or raw SQL — there are — but because Prisma has the most mature pattern library for the specific operations Avery NXR generates against. The migrations are clean. The types are integrated end-to-end. The seed scripts are first-class. We will revisit if the community shifts.

TypeScript is the language. This one needs less justification.

The rest of the stack falls in line with the same logic. Tailwind for styling, because it is the dominant pattern. shadcn/ui for components, because it has become the de facto Next.js UI library. NextAuth for auth, with a swap path for Better-Auth. Resend for email. R2 or S3 for files. The choices are the same choices the median senior Next.js engineer would make, and the generators emit code that looks like the median senior Next.js engineer wrote it.

What we are giving up

We are giving up Remix users. Astro users. SvelteKit users. SolidStart users. Nuxt users. Rails users. Django users. Phoenix users. All of them.

That is the tradeoff. We picked the largest population we could pick while still being able to be deeply opinionated, and we accepted that we cannot serve the others.

This is the part that founders usually resist. "Why not just also support Remix? It's not that different from Next.js." The answer is: every stack we add costs us depth on the stack we have. Every generator gets shallower the more frameworks it has to abstract over. Every audit ledger entry gets more generic. Every error message gets less specific. The product becomes worse for the existing users every time a new stack is added.

We would rather be the best tool for one stack than the okay tool for five.

What this enables

Picking one stack lets us go deep in ways that polyglot tools cannot.

The local SLM is trained on Next.js patterns specifically. It does not waste capacity learning to scaffold Django views. Its weights are dense with the conventions of one framework. The output reflects that — the code that comes out of Avery NXR looks like Next.js code, not like generic code that compiles in Next.js.

The generators know about each other. The auth generator knows the exact shape of NextAuth's session callback. The billing generator knows how Stripe's webhook handling works in App Router specifically. The CRUD generator knows how to emit server actions that look like the App Router community would write them. The generators are not abstract over a generic framework concept. They are concrete about this framework.

The audit ledger is sharper because the decisions are sharper. "Use NextAuth instead of Lucia because the project flagged Vercel as the deployment target" is a meaningful audit entry. The polyglot equivalent — "use the auth provider that fits the runtime" — is not.

The community can extend the tool without re-doing the integration work. Plugins for Next.js can assume Next.js semantics. They do not have to write conditional code for "if Remix, then this, if Astro, then that."

Every property of the product gets better when the stack is narrower.

What we will do, eventually

We are not zealots about the choice. If the Next.js community fractures or a clear successor emerges, we will follow. The principle is not "Next.js forever." The principle is "go deep on one well-chosen target."

We have looked at Remix. We have looked at Astro. We have looked at SolidStart. The honest answer for each of them is: we love the framework, we are not the right tool for it. Someone should build the Avery NXR for Remix. We will cheer them on. It just is not going to be us.

The thing this gets right

For a developer who is already building in Next.js, Avery NXR is the most specific, most idiomatic, most opinionated generator they can use. It is not framework-agnostic. It is the opposite. It assumes Next.js, it speaks Next.js, it generates Next.js.

That is the feature. The narrowness is what makes the output good. The opinion is what makes the loop fast. The willingness to leave the rest of the world out is what makes the tool useful for the people it does serve.

Generality is not a feature. Idiomaticness is. We picked the second one.