In a Next.js project, what is the difference between running `next dev` and running `next build` followed by `next start`, and why can you not judge caching or bundle size from `next dev`?

## Two different programs, not two modes of one It is tempting to treat `next dev` as "the app, but slower". It is closer to a different program that happens to render the same routes. Development optimizes for the edit-save-see loop; production optimizes for what a user gets. Almost every property a candidate is asked about — is this route static, is this response cached, how big is the client bundle — is a property of the production build only. ## What `next dev` does The dev server compiles routes lazily: nothing is built until you navigate to it, and then only that route's module graph is compiled. React runs in development mode, which keeps warnings, prop checks and extra bookkeeping that never ship. Output is unminified, source-mapped, and carries the hot-reload client. Because a stale cached render would defeat the whole point of hot reload, development deliberately does not reuse rendered output between requests the way production does — every request re-renders. The practical consequence: "my data isn't caching in dev" is not evidence of anything, and neither is "my page re-renders on every request in dev". Equally, a route that will be prerendered at build time in production is indistinguishable in dev from one that renders per request, because in dev both render per request. ## What `next build` does `next build` is where the real decisions get made: - it compiles and minifies the client bundles and tree-shakes what nothing imports; - it runs a prerender pass, actually executing every statically renderable route so it can emit HTML plus the React Server Components payload; - it decides, per route, static or dynamic — a route that reads request-scoped data cannot be prerendered and is marked dynamic; - it fails the build on type errors and on errors thrown during prerendering. It then prints a per-route table with each route's status and its first-load JavaScript. That table is the artifact of record: it is the fastest way to notice that a route you expected to be prerendered became dynamic, or that one page's first-load JS jumped after a dependency change. Nothing in dev surfaces either fact. ## What `next start` does `next start` boots the production Node server against the finished build. It compiles nothing; it replays what `next build` produced, serving prerendered HTML where it exists and rendering on demand where it does not. Run against an empty or missing `.next` directory, it exits with an error telling you to run `next build` first — which is exactly the error people hit in a Dockerfile that forgot the build step. ```bash next build # produce the production output next start # serve that output, no compilation ``` ## Why this matters at deploy time Every deployment target ultimately runs the output of `next build`. A managed platform runs the build for you and serves the result; a container image runs the build during `docker build` and starts the server in the container. Either way, `next dev` never runs in production, so a workflow where the only place anyone looks at the app is dev will keep discovering problems after deploy: a component that reads request data and quietly turned a whole route dynamic, a heavy library that only shows up in the first-load column, a caching assumption that only holds in production. ## The habit to build Before anything that matters — a performance claim, a caching question, a deploy — build and start locally. It takes seconds on a small app and it is the only local signal that matches what users get. Read the route table each time; treat an unexpected dynamic marker or a jump in first-load JS as a review comment, not a curiosity.