From Blank Page to Production: 12 Prompts That Let AI Architect, Code, and Ship Your Next.js Site

From Blank Page to Production: 12 Prompts That Let AI Architect, Code, and Ship Your Next.js Site

Most developers use AI as an autocomplete. Paste a function, get a function back. That leaves 80% of the actual work — deciding the data model, choosing a rendering strategy, wiring CI/CD, debugging hydration errors at 2 a.m. — entirely on you. The gap between "AI writes code" and "AI ships a site" is not model capability; it is prompt structure.

This roundup collects twelve prompts that cover the real web development pipeline: architecture, frontend, fullstack API layer, and deployment. Each one is copy-paste ready, scoped to Next.js (App Router, as of Next.js 15/16), and designed so the output is verifiable against official docs rather than plausible-sounding guesswork. Treat them as a checklist you run through a project, not a magic button.

1. The Architecture Brief: turn a one-liner into a technical spec

When to use: Day zero, before any file exists. This forces the model to commit to a rendering strategy and data flow instead of defaulting to client-side everything.

You are a senior fullstack architect. Product: {{one-line description}}.
Constraints: Next.js App Router, TypeScript, PostgreSQL via Prisma, deploy on Vercel.
Produce: (1) a route map (app/ directory tree) with each route's rendering mode — SSG, ISR (with revalidate value), SSR, or client — and one sentence justifying each choice; (2) the Prisma schema in schema.prisma syntax; (3) a list of Server Actions vs Route Handlers, with reasons.
Do not write component code yet. Flag any route where the rendering choice is debatable.

Example: for a job board, the prompt should output app/jobs/[slug]/page.tsx as ISR with export const revalidate = 3600, while /dashboard is SSR because it depends on the session cookie. If the model marks everything "client", your prompt worked — it exposed a bad default.

2. Scaffold the project without version drift

When to use: When you need create-next-app flags and config that match the current release, not a tutorial from 2023.

Give me the exact commands to scaffold a Next.js App Router project with TypeScript, Tailwind, ESLint, and src/ directory. Then generate next.config.ts and tsconfig.json paths ("@/*" -> "./src/*").
For every flag, cite whether it is still valid in the current Next.js docs. If unsure of a version-specific detail, say so instead of guessing.

Run the commands yourself; the value is the config files and the honesty check. Cross-reference anything version-specific against nextjs.org/docs before trusting it.

3. Component generation with a design contract

When to use: You have a Figma frame or a textual description and need accessible, typed components — not div soup.

Build a <PricingCard> React Server Component. Props: name, price, features (string[]), highlighted (boolean).
Rules: semantic HTML, Tailwind classes only, no client hooks, keyboard-focusable CTA, aria-label on the CTA, forwardRef not needed (RSC).
Output: the .tsx file plus a short note on which HTML element you chose for the price and why.

This produces Server Components by default — the right call for static content. Ask for 'use client' explicitly only when state or browser APIs are required.

4. Data fetching and caching strategy

When to use: When pages are slow or stale and you cannot remember Next.js's caching defaults.

Given this page component: {{paste code}}. Explain what is cached by default in the App Router, then rewrite it using fetch with explicit cache options and revalidate. Show the diff and cite the Next.js caching docs section you relied on.

Next.js changed its default caching behavior across major versions, so always ask the model to state which version it assumes. Treat unversioned answers as suspect.

5. Server Actions and validation

When to use: Forms. This is where most AI-generated fullstack code fails — no validation, no error states.

Write a Server Action `createPost` for a Next.js App Router app. Validate input with Zod; return a typed result { ok: true } | { ok: false, errors: Record<string,string> }.
Include: Prisma insert, revalidatePath call, and a matching client form using useActionState (React 19). No try/catch swallowing — surface DB errors.

The prompt names useActionState deliberately: it replaced the older useFormState in React 19, and older models still emit the deprecated hook.

6. API Route Handlers for external consumers

When to use: When a mobile app or third party needs JSON, not a Server Action.

Create app/api/orders/route.ts with GET (paginated, cursor-based) and POST (Zod-validated). Use NextResponse, set Cache-Control: no-store on POST responses, return RFC 9457 problem+json on errors. Include a curl example for each method.

RFC 9457 (Problem Details for HTTP APIs) is the current standard superseding RFC 7807 — asking for it by number keeps error shapes consistent across your API.

7. The hydration-error debugger

When to use: The classic "Text content does not match server-rendered HTML" in production.

This component throws a hydration mismatch: {{paste component and error}}. List the three most likely causes in order of probability (Date/time, random values, browser-only APIs, invalid HTML nesting). For each, show the minimal fix using suppressHydrationWarning only where legitimately needed. Explain why suppressHydrationWarning is a last resort.

8. Accessibility and Core Web Vitals audit

When to use: Pre-launch. AI is good at spotting missing alt, bad heading order, and next/image misuse.

Audit this page for WCAG 2.2 AA: {{paste JSX}}. Output a table:

| Issue | WCAG criterion | Fix |. Then list image and font optimizations per Next.js docs (next/image sizes, next/font). Do not invent criteria numbers — cite only real WCAG 2.2 success criteria.

WCAG 2.2 is a W3C Recommendation; requiring the model to cite actual criteria (e.g., 1.4.3 Contrast) prevents fabricated rule numbers.

9. Test generation for critical paths

When to use: Before refactoring anything you did not write.

Generate Vitest unit tests for this utility and a Playwright E2E test for the checkout flow at /checkout. Cover: empty cart, invalid promo code, successful payment redirect. Use role-based selectors (getByRole), not CSS classes.

Role-based selectors double as accessibility checks — if a button has no accessible name, the test fails, which is exactly what you want.

10. CI/CD pipeline that actually gates merges

When to use: First deploy. This is the "autopilot" part — the pipeline runs without you.

Write .github/workflows/ci.yml for a Next.js app: install with pnpm, cache the store, run lint, typecheck (tsc --noEmit), Vitest, and a Playwright job on pull_request. Add a separate deploy job on push to main using the Vercel CLI. Pin action versions to major tags and explain each step in a comment.

11. Environment and secrets hygiene

When to use: Right after the first git push where someone almost committed .env.

List every environment variable this project needs ({{paste .env.example}}), classify each as build-time (NEXT_PUBLIC_) or server-only, and generate a validation module that fails fast at startup if a required var is missing. Explain the security implication of prefixing a secret with NEXT_PUBLIC_.

12. The pre-launch checklist prompt

When to use: The night before launch, when you want a second pair of eyes.

Act as a release manager. Given this repo structure and package.json: {{paste}}. Produce a go-live checklist covering: redirects, sitemap/robots, OG images, error boundaries, 404/500 pages, rate limiting on API routes, and rollback plan. Mark each item as blocking or non-blocking.

Quick reference

The pattern across all twelve: name the framework version, demand citations to official docs, and ask the model to flag uncertainty instead of filling gaps. That is what separates a prompt that ships a site from one that ships a bug. Pick the prompts that match your current stage, run them in order, and verify every version-specific claim against nextjs.org/docs — the model is your pair, not your authority.