"Works on my machine" is a configuration bug until proven otherwise. The application code is identical; what differs is the environment around it. The skill this section trains is listing the differences systematically instead of staring at the code.

Make the failing environment reproducible

Start by running the app the way production runs it: the same settings module, DEBUG off, the same server, the same environment variables. Many bugs appear the moment you do. Then diff the two configurations: settings values, middleware, environment variables, installed packages, files that are generated at build time (collected static files, compiled assets).

Know what serves what

Development conveniences hide dependencies. The development server serves static files by itself only while DEBUG is on; in production something else must: a web server, a CDN, or middleware such as WhiteNoise. The same is true for the database URL (a missing variable should fail loudly, not fall back to a local file), for allowed hosts and CSRF origins behind a proxy, and for cookies over HTTPS. For each feature that "just works" in development, ask who provides it in production.

Fix the configuration, do not switch off the check

The tempting fixes are the ones that hide the difference: turning DEBUG on, adding development-only URL routes, changing a setting on the server by hand. Prefer the fix that makes the environments equivalent in code, keep it in version control, and back it with a test on the settings module so the next change cannot silently remove it.