What happens when you run next dev, next build and next start?

Q: What happens when you run next dev, next build and next start?

**Target Audience:** Beginners preparing for Next.js interviews — no prior Next.js knowledge assumed. **Difficulty:** Easy > **How to read this doc:** Each idea is explained in plain language first, then tagged with `📌 Interview term:`. Every behaviour claim was checked against the Next.js 16.4.2 docs shipped with the package and, in the **Verified** section, against a real `create-next-app@16.4.2` project run under all three commands and probed with `curl`. ## 1. Why This Even Matters — A Story First A restaurant has two modes. During recipe testing, the chef cooks each dish only when someone orders it, tastes it, changes the salt, and cooks it again — slow per plate, but every change is visible immediately. Before opening night, the kitchen preps: sauces made, desserts plated in advance, the menu fixed. Then service starts and plates go out fast, but changing a recipe means prepping again. `next dev` is recipe testing, `next build` is the prep, and `next start` is service. Most c

The problem

Question presented to candidate: "A new teammate asks why the app is fast after deployment but the first page load on their laptop takes seconds, and why their change does not show up on the staging server until someone rebuilds. Explain what next dev, next build and next start each do."

What a strong answer should cover:

next dev: a development server that compiles routes on demand with Turbopack, hot-reloads changes, shows detailed errors, sets NODE_ENV=development, sends Cache-Control: no-store and writes to .next/dev.
next build: compiles and minifies for production, runs TypeScript checking, prerenders static routes, and prints a route table with symbols (static, SSG, partial prerender, dynamic).
next start: a production Node.js server that serves the existing .next build; it does not compile, so code changes need a new build, and it fails if no build exists.
Static pages built ahead of time are served from the prerendered output (with cache headers), dynamic ones are rendered per request.
Practical details: default port 3000, -p/PORT, --webpack, next build and next dev can run side by side because dev uses .next/dev.

Clarifying questions expected:

"How is the app deployed: a Node server, a container, static hosting or a platform?" — next start only applies to a Node server.
"Is the slow page static or dynamic in the build output?" — that tells you what production does with it.

Code / implementation expected: Optional — the commands and a page showing the mode.

nextjs
cli
build
tooling

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Beginners preparing for Next.js interviews — no prior Next.js knowledge assumed. Difficulty: Easy

How to read this doc: Each idea is explained in plain language first, then tagged with 📌 Interview term:. Every behaviour claim was checked against the Next.js 16.4.2 docs shipped with the package and, in the Verified section, against a real create-next-app@16.4.2 project run under all three commands and probed with curl.

1. Why This Even Matters — A Story First

A restaurant has two modes. During recipe testing, the chef cooks each dish only when someone orders it, tastes it, changes the salt, and cooks it again — slow per plate, but every change is visible immediately. Before opening night, the kitchen preps: sauces made, desserts plated in advance, the menu fixed. Then service starts and plates go out fast, but changing a recipe means preppin

The solution is hidden so you can try first

9 min read · 9 sections

Read the code

The three commands and their common options

# Development: compile on demand, hot reload, detailed errors. Output goes to .next/dev
next dev                 # http://localhost:3000
next dev -p 4000         # another port (or PORT=4000 next dev)
next dev --webpack       # use Webpack instead of the default Turbopack

# Production build: compile, type-check, prerender static routes, write .next/
next build
next build --debug-prerender   # readable stack traces for prerender errors (do not deploy)

# Production server: serve the existing build (fails if there is none)
next start -p 3000

# With npm scripts, pass flags after --
npm run dev -- -p 4000

A page that shows which mode it runs in

// app/env/page.tsx
export default function EnvPage() {
  // "development" under next dev, "production" under next build + next start
  return <p>NODE_ENV={process.env.NODE_ENV}</p>;
}

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.