From prompt to running app in 90 seconds: a walkthrough of the iteration loop

The marketing claim is "from prompt to production-ready Next.js app." The honest version of that claim is more specific: from prompt to running application, on the developer's machine, with a working database, running auth, a populated dashboard, and a CLI that does what it says.

We measured the time, across a hundred sessions on standard developer hardware — MacBook Pro M2, sixteen gigabytes of RAM, an SSD with twenty gigabytes free. The median was eighty-seven seconds from the moment the developer hit "run" on the prompt to the moment localhost:3000 served a working page.

This is what happens in those eighty-seven seconds.

Seconds 0–3: the prompt is parsed

The desktop app reads the prompt. The local SLM, already loaded into memory from the previous session, tokenizes the input.

Three things happen in parallel. The prompt is matched against the catalog of installed generators — which of the sixteen are likely needed. The data model is extracted — which entities the user mentioned. The stack is detected — whether the user named explicit dependencies, or whether the defaults apply.

By the end of this phase, the system has a structured plan: which generators to invoke, in what order, with what arguments.

Seconds 3–18: the project skeleton is written

The first generator to run is the project itself. A fresh Next.js 14 application with App Router. TypeScript in strict mode. Tailwind configured. shadcn/ui installed. The folder structure laid out.

This is the slowest phase, dominated by npm install for the base dependencies. On a fresh machine with a cold npm cache, this can take longer. On a warm cache — which most developers have — it is fast.

By the end of this phase, you have a runnable but empty Next.js app on disk.

Seconds 18–32: the data model and database

The CRUD and auth generators write the Prisma schema. The User model, the Account model, the Session model, plus whatever business models the prompt requested.

The schema is migrated against a local SQLite database by default — no Docker, no Postgres install. (The generator emits configuration for switching to Postgres in production, but development defaults to SQLite for the fast loop.)

The migration runs. Seed data is generated, if the prompt asked for it. The audit ledger is initialized with its first entries — recording what models were created and why.

Seconds 32–55: the API and pages

The CRUD generator emits typed API routes for each model. REST endpoints, plus tRPC if the prompt opted in. OpenAPI spec generation is triggered.

The list, detail, and form pages are written for each model. Forms are wired to Zod validation. Optimistic updates are configured. Error states are scaffolded.

The dashboard generator writes the sidebar, the topbar, the auth-aware layout. The settings page is wired to the user model. The admin panel is generated, scoped behind a role check.

Every file written produces an audit ledger entry. By the end of this phase, the ledger has several hundred entries.

Seconds 55–78: integrations and side modules

If the prompt mentioned auth, the auth generator wires up NextAuth — providers, callbacks, session management. The auth UI is rendered.

If the prompt mentioned billing, the billing generator wires up Stripe — checkout, customer portal, webhooks, the subscription model. If the prompt mentioned emails, transactional email is wired through Resend with React Email templates.

If the prompt mentioned background jobs, the jobs generator scaffolds a queue, a worker, and a couple of example jobs. If the prompt mentioned file uploads, the file generator wires up signed URL generation.

The generators run in parallel where they can. They write to disjoint parts of the filesystem to avoid stepping on each other.

Seconds 78–87: final wiring and boot

The last few seconds are integration. The audit ledger is finalized — every entry annotated with cross-references to the others. The README is written, with the project's actual stack, the run commands, and a screenshot or two of the generated UI.

The desktop app launches npm run dev in a child process. The Next.js dev server boots. The first compile finishes. Localhost:3000 starts serving.

The desktop app pops a notification: Your app is running. The developer clicks it. The browser opens. The seeded dashboard renders. Eighty-seven seconds total.

What the developer does in those 87 seconds

In practice, nothing. The desktop app shows a live progress view — which generator is running, which files have been written, which entries have been added to the ledger. Most developers we watched during testing read the live progress for the first twenty seconds, then opened a Slack window or refilled their coffee.

That is, by itself, an interesting product property. The eighty-seven seconds is fast enough that the developer is not annoyed, but long enough that they are not staring at it. It hits a sweet spot of "the tool is working" without "the tool is making me wait."

The cognitive register of the experience is closer to spinning up a Vercel deploy than to running a code generator. Something is happening in the background. You'll be told when it's done. You go do something else for a minute and a half.

What changes when the prompt is bigger

The eighty-seven-second number is for a prompt of moderate complexity — three or four models, auth, a dashboard. For a longer prompt — eight models, billing, emails, file uploads, search, audit trail — the build time scales roughly linearly with the number of generators invoked. A heavy prompt takes two and a half to three minutes.

The thing that does not scale up much is the latency to first feedback. Within the first ten seconds, the desktop app has already written the project plan to the ledger, started npm install, and rendered a live progress view. The developer knows what is happening from the very beginning. The longer build times are filled with visible activity, not silent waiting.

What this changes about prototyping

We think the most underrated consequence of the eighty-seven-second loop is what it does to prototyping.

In a world where scaffolding a real app takes a day, prototypes are precious. You write one. You sink hours into making it work. You're reluctant to throw it away even if the idea is wrong.

In a world where scaffolding a real app takes ninety seconds, prototypes are cheap. You write three. You try variations. You delete two of them. The cost of being wrong is a minute and a half.

That changes how willing teams are to try ideas. It changes how senior engineers spend Monday mornings. It changes what "MVP" means in a calendar week.

The eighty-seven seconds is the headline number. The shift in how teams prototype is the real product.