TechnicalCollectible prompt

Fix an app that works locally but breaks in production

Find the real difference between your machine and the live site, from env vars to file name case.

Claude CodeCursorCodex

Curated by Nvoka

Nvoka wordmark logo
Nvoka wordmark logoTechnical

Fix an app that works locally but breaks in production

Act as a senior engineer who has shipped many {{tech_stack}} apps. Everything works on my machine, but on the live site this happens: {{error_message}} Where I see it: {{steps_to_reproduce}} Gather evidence before changing anything: - The exact error in the browser console, and the failing request in the network tab: status, URL and response body - The host's build log, and the server or function logs at the moment it fails - Whether a production build run locally (build, then preview or start) fails the same way. If it does, we can debug locally Likely causes for this symptom, most common first. Check each against the evidence: 1. Environment variables missing or different on the host, or added after the last build. Values the browser needs are baked in at build time and need the framework's public prefix; secrets must never have it 2. Build time versus runtime: code that reads window, localStorage or the current date during server rendering or prerendering 3. File name case: imports that work on a case-insensitive Mac or Windows disk but fail on Linux 4. Paths: a subfolder deploy, hard-coded localhost URLs, or API calls still pointing at the dev server 5. A different database: production keys point at a project missing the latest migrations, policies or seed data 6. Auth settings: the live domain missing from allowed redirect URLs or allowed origins 7. Node or dependency versions that differ between my machine and the build image Confirm the root cause with one targeted check before fixing. Then make the smallest fix and add a check that would have caught it: a startup check that fails loudly when a required variable is missing, a case-sensitive import lint rule, or a CI step that runs the production build. Explain in plain words what was different. Never expose a secret to the browser to make it work.
Technicalnvoka.com/library/nvoka-fix-an-app-that-works-locally-but-breaks-in-productionScan to open
Technical

Fix an app that works locally but breaks in production

Find the real difference between your machine and the live site, from env vars to file name case.

Nvoka logo

Curated by Nvoka

Claude CodeCursorCodexWindsurf
Add to my library

Make it yours

Fill in the blanks and change any word. Only your copy changes, never the card.

Fill in the blanks

0 of 3 filled

Your prompt

Act as a senior engineer who has shipped many {{tech_stack}} apps. Everything works on my machine, but on the live site this happens: {{error_message}} Where I see it: {{steps_to_reproduce}} Gather evidence before changing anything: - The exact error in the browser console, and the failing request in the network tab: status, URL and response body - The host's build log, and the server or function logs at the moment it fails - Whether a production build run locally (build, then preview or start) fails the same way. If it does, we can debug locally Likely causes for this symptom, most common first. Check each against the evidence: 1. Environment variables missing or different on the host, or added after the last build. Values the browser needs are baked in at build time and need the framework's public prefix; secrets must never have it 2. Build time versus runtime: code that reads window, localStorage or the current date during server rendering or prerendering 3. File name case: imports that work on a case-insensitive Mac or Windows disk but fail on Linux 4. Paths: a subfolder deploy, hard-coded localhost URLs, or API calls still pointing at the dev server 5. A different database: production keys point at a project missing the latest migrations, policies or seed data 6. Auth settings: the live domain missing from allowed redirect URLs or allowed origins 7. Node or dependency versions that differ between my machine and the build image Confirm the root cause with one targeted check before fixing. Then make the smallest fix and add a check that would have caught it: a startup check that fails loudly when a required variable is missing, a case-sensitive import lint rule, or a CI step that runs the production build. Explain in plain words what was different. Never expose a secret to the browser to make it work.
See all