What the CLI gives you
One command produces a working app with TypeScript, ESLint, Tailwind (optional), the App Router, and Turbopack on for dev and production:
| Path | Purpose |
|---|---|
app/layout.tsx | Required root layout. Renders <html> and <body>. |
app/page.tsx | The / route. |
app/globals.css | Global styles (Tailwind import goes here). |
public/ | Static assets served from root (/favicon.ico etc.). |
next.config.ts | Framework config — written in TypeScript natively. |
tsconfig.json | TypeScript with the @/* import alias preset. |
The root layout you can't skip
The root layout has hard requirements: it must render <html> and <body>, and it wraps every route in your app. Common pattern: load fonts here and apply them as a className on <body>.
Turbopack as the default
Since v16, Turbopack is on by default for both next dev and next build. You don't need --turbopack. Reported wins versus Webpack: ~3.8× faster cold start, ~9× faster HMR, ~2.3× faster prod build. File-system cache makes warm starts even faster.
Use create-next-app to establish the current App Router, TypeScript, lint, and bundler contracts, then inspect every generated file before deleting or relocating it. Keep the required root layout and decide intentionally which global concerns it owns.
A successful scaffold proves only that the toolchain starts. It does not prove the team understands route exposure, layout inheritance, client boundaries, or production behavior. Replacing the scaffold wholesale can erase the conventions it was meant to teach. Add a second route and shared navigation, then verify direct visits and client navigation. Save a file and observe state preservation, inspect the root document elements, and run a production build so the first exercise tests conventions rather than only the dev server.