From prompt to app: how Avery NXR turns a sentence into a working Next.js project

2026-05-07 · Avery NXR Team · product · getting-started

The fastest way to understand Avery NXR is to watch it work.

Type a sentence. The local Small Language Model reads your description, picks an archetype that matches the shape of the work (CRUD, marketing, ops hub, study hub, …), and decomposes it into a list of entities and features. The deterministic generator plugins write the code. Five seconds to a few minutes later — depending on how much you asked for — you have a real Next.js 15 project on disk. You can cd into it, run pnpm dev, and use it.

This post walks through what happens in between, so the next time you see the Activity Stream blink past you can read it.

What you type

Open the desktop and click New app. The Customize step asks for:

A description. "An order-tracking app for a small coffee roaster — orders have items, status, expected ship date." Plain English, no schema syntax.
A name. Becomes the slug under your projects folder (~/nxr-projects/coffee-orders/).
A theme. Six bundled themes; the planner picks one based on the archetype it inferred, you can override.
A database provider. SQLite for local-only or experiments; PostgreSQL for anything that's going to ship.

That's it. No schema editor. No template picker. No "here's a list of 67 plugins, choose ten."

What gets generated

While the SLM works, the Activity Stream narrates each step:

Archetype matched. The first thing the SLM does is decide which archetype best fits — CRUD, marketing, system-of-record, ecommerce, solo-practice, operations-hub, dept-ops-tool, study-hub, or custom. Each archetype carries a set of default generators (auth, CRUD, audit log, notifications, admin, …) and a vibe (default theme, typography, density).
Entities decomposed. "An order has items, a status, and an expected ship date" becomes Order + OrderItem with the right foreign keys. Field types come from a small SLM-driven inference pass + a hand-written rule list (email fields get @unique, created_at gets a default of now(), status becomes a Prisma enum).
Plan locked. The decomposition + the per-entity feature assignments form a Plan. The Plan is deterministic: same prompt, same plugin versions, same Plan id, same generated bytes. You can regenerate from the same Plan and get byte-identical output — useful when you want to upgrade to a newer Avery NXR without redoing your customizations.
Generators write files. Each generator is a versioned plugin (auth-generator@1.4.0, crud-generator@1.7.2, …) that emits Handlebars-templated TypeScript + a Prisma schema fragment. The schema composer merges the fragments into a single prisma/schema.prisma. Every emitted file carries a provenance header listing the generator name, version, and Plan id.
Auto-verify runs. A small post-generate pass typechecks + lint-fixes + (when you ask for it) runs the dev server long enough to confirm the home page renders without errors. Failures get sent back through the fix pipeline — the SLM proposes a bash patch, the runner applies it, retry. Capped at 5 attempts so you don't sit through infinite loops.

When the stream goes quiet, the project on disk is a real production-shape Next.js app: app/ directory routing, Tailwind v4 styling, Prisma 5 migrations, NextAuth (when the archetype calls for it), full TypeScript.

Where it lands

Look in ~/nxr-projects/<your-slug>/. You'll find:

prisma/schema.prisma — one schema, composed from every generator's fragment. Single source of truth for your data model; no second schema file anywhere.
app/ — pages, layouts, route handlers. Prisma queries are in the relevant route handlers, not in a service layer; the generated stack stays close to vanilla Next.js so you can read any chunk of it without learning Avery NXR-specific abstractions.
components/ — shadcn/ui primitives + per-feature components (CRUD list view, audit log row, notification bell, etc.). They consume the active theme via Tailwind utilities — you don't see hex codes anywhere.
lib/ — small helpers (db client, auth config, email driver picker, audit-log wrapper). Each generator owns its slice.
.nxr/ — Avery NXR's per-project ledger. audit.json records every generator run + every fix-pipeline attempt; usage.json tracks LLM spend if you used Consult Mode. These travel with the project — useful for git history when you regenerate.

The whole project is yours. No checkout step. No "open in Avery NXR to keep editing" gate. You can rename it, restructure it, throw away half the generators, or ship it as-is to Vercel — same source tree either way.

What it doesn't do

A few things to set expectations:

It's not a no-code tool. The output is real code; if you want to add a non-trivial business rule, you write TypeScript. The scaffolder gets you to a starting point that's ~70% of an internal tool's surface; the last 30% is yours.
It doesn't keep regenerating in the background. After you customize a generated file, the next regeneration leaves your edits intact only if they sit inside a // user:zone:start / // user:zone:end block. Outside those zones, regeneration overwrites. The convention is documented in every generator's output.
It doesn't deploy for you. The Workspace's Deploy tab knows how to run npx vercel --prod or npx @railway/cli up against your tokens, but the deploy is your CI / your hosting account / your bill. Avery.software never touches the artifact.

That last constraint is on purpose. Local-first means you own the output of the loop, not us.

Try it

Install Avery NXR. Click New app. Type the smallest sentence you can think of that describes a thing you wish existed — a list with three fields, a form, a daily report, an email-on-event automation. Watch the Activity Stream. Hit Open app when it's done.

If you want to compare the same prompt across different SLMs, the local-model picker in Settings lets you swap which model handles the plan. The output's deterministic given the Plan, so the SLM only affects the planning step — not the code that lands.

That's it. That's the loop. The rest of the blog is going to be about specific things the loop produces, and how to lean on each one.