Updated September 5, 2026
Identify the project
Read the README and package.json. Plain HTML and images may be published as static files. A build-tool project needs generated output. Login, databases, and server APIs require compatible runtime services. A screenshot cannot tell you which hosting model the project needs.
Record the runtime contract
Document the package manager, runtime version, install command, build command, start command, and output directory. Use the existing project scripts rather than copying commands from an unrelated tutorial. The build script in package.json describes what this project actually runs.
Test a production build
A working development server is not proof of a successful production build. For a trusted project, run its build script, capture the first error with context, fix it, and repeat. Check the production startup procedure as well. Do not disable checks just to hide an unexplained failure.
Document names, not secrets
List each variable, its purpose, whether it is required, and whether it belongs in the browser or on the server. Keep preview and production values separate. Next.js embeds NEXT_PUBLIC_ variables in browser build output: never put private keys there. Changing these values generally requires a rebuild. Never commit .env files or share real keys in screenshots.
Verify a preview before connecting the domain
Check the home page, direct visits to inner pages, images, mobile layout, and interactions. Use test accounts and a test environment for payments or data writes. Connect the domain only after the preview works, following current platform instructions. Preserve DNS records used by email and other services.
Completion criteria
You can explain how to build the project, which configuration belongs to production, where a working preview lives, and which version you can restore. Keep a secret-free deployment record with the date, commit, build settings, preview URL, and test results.
Official reference: Next.js: Environment Variables