Why does everything work perfectly on localhost?

Because localhost is a perfect environment: same-origin (no CORS), zero network latency, dev mode masks warnings, you're the only user (no race conditions, no load). In production every one of these conditions is different — and any of them can cause a failure.

What's the most common production failure?

Missing environment variables and hardcoded configuration. It's trivial, but it accounts for the majority of "works locally, fails in production" issues. Your .env has keys — the production server doesn't. AI hardcodes URLs in source code instead of using environment variables.

How do I know if my app is production-ready?

Simple question: if you can't answer "what happens when X fails?" for every critical path, your app is not ready. What happens when the database is unavailable? When the Stripe API returns an error? When 100 users click "Buy" at the same second? If you don't have answers — you have work to do.

Should I rewrite from scratch?

Usually no. Start with an audit. Identify critical gaps (security, database, configuration). Fix them point by point. A full rewrite only makes sense when the architecture is fundamentally flawed — but in most cases you can fix existing code iteratively without losing the work done so far.

Can I deploy to Vercel/Netlify and call it production?

Platform doesn't equal production-ready. Vercel and Netlify are great hosting tools, but hosting alone isn't "production." You still need proper CORS configuration, monitoring, error handling, security, a proper database, and load testing. The "Deploy" button is the beginning, not the end.

Hvorfor appen din fungerer lokalt men feiler i produksjon

Ekte årsaker og konkrete løsninger. AI optimaliserer for en fungerende demo, ikke et produksjonssystem. Med 15–30 stille arkitekturbeslutninger per feature med ~70% nøyaktighet hver, er sannsynligheten for at ALLE er korrekte praktisk talt null.

⏱ 15 min lesing

«Det fungerer på maskinen min» er den eldste vitsen innen programvareutvikling. Med AI-genererte apper er det ingen vits — det er standardtilstanden. AI tenker ikke på produksjon. Den vet ikke hva en lastbalanserer, tilkoblingspool eller hemmelighetsbehandler er. Den ser bare én ting: din lokale kontekst, din fil, ditt forsøk på å kjøre den.

Når AI bygger en feature, tar den 15–30 stille arkitekturbeslutninger: hvilken database, hvordan koble til et API, hvor lagre nøkler, hvordan håndtere feil. Hver beslutning har omtrent 70% sjanse for å være korrekt. Men for at hele featuren skal fungere i produksjon, må alle beslutninger være korrekte. Sannsynligheten? Med 20 beslutninger: 0.7^20 = 0.08%. Praktisk talt null.

Denne artikkelen dekker de seks vanligste grunnene til at AI-apper fungerer lokalt og krasjer i produksjon — med konkrete eksempler og løsninger. Hvis du bygger med Cursor, Bolt, Lovable, Replit eller et annet AI-verktøy, er denne guiden for deg.

Miljø og konfigurasjon

Dette er den mest åpenbare og samtidig vanligste årsaken til produksjonsfeil: konfigurasjon som bare fungerer lokalt. .env-filen din på laptopen har ekte API-nøkler, korrekte URL-er, fungerende hemmeligheter. I produksjon? Plassholdere, manglende variabler eller helt andre adresser.

AI tenker aldri på konfigurasjonshåndtering — den ser bare lokal kontekst. Når den genererer kode som kobler til et API, skriver den http://localhost:3000 direkte i koden. Når den trenger en API-nøkkel, oppretter den en variabel med en standardverdi. Når den bygger en database-URL, hardkoder den tilkoblingsstrengen.

Typiske problemer:

Hardkodede URL-er — http://localhost:3000/api i stedet for en miljøvariabel. Fungerer lokalt, peker ingensteds i produksjon.
Manglende miljøvariabler — i produksjon har du ingen .env-fil. Du må sette variabler i hostingpanelet ditt (Vercel, Railway, Render).
HTTP vs HTTPS — lokalt bruker du http://, produksjon krever https://. Å blande protokoller forårsaker nettleserblokkering (mixed content) og CORS-feil.
Ulike API-nøkler — Stripes testnøkkel vs produksjon. Firebase dev-nøkkel vs prod. AI vet ikke at forskjellen finnes.

Konfigurasjon

Din lokale .env har ekte nøkler. Produksjon kan ha plassholdere, feil URL-er eller manglende hemmeligheter. AI tenker aldri på konfigurasjonshåndtering — den ser bare lokal kontekst.

Slik fikser du det

Eksternaliser ALL konfigurasjon. Hver URL, hver nøkkel, hver hemmelighet bør komme fra en miljøvariabel — aldri fra kildekode. Bruk en hemmelighetsbehandler (f.eks. Doppler, AWS Secrets Manager, Vercel Environment Variables). Opprett en .env.example-fil med navnet på hver påkrevd variabel (uten verdier) og legg den til i repoet som dokumentasjon.

Databaseantakelser

AI elsker SQLite. Den er enkel, krever ingen server, det er bare en fil. Perfekt for en prototype. Problemet? Serverløse plattformer (Vercel, Netlify Functions, AWS Lambda) støtter ikke SQLite fordi hver forespørsel kan treffe en annen instans — det finnes ikke noe delt filsystem.

Men databasen er ikke bare motoren. Det er et helt sett med antakelser AI gjør stille:

Manglende indekser — en spørring fungerer lynraskt på 50 rader. På 50 000? Tar 30 sekunder. AI legger ikke til indekser fordi på små data ser man ingen forskjell.
Ingen tilkoblingspooling — hver HTTP-forespørsel åpner en ny databasetilkobling. Med 100 samtidige brukere har du 100 åpne tilkoblinger. Databaser har grenser — vanligvis 20–100 tilkoblinger. Overskrider du det: krasj.
Skjema som ser bra ut i en demo — ingen relasjoner, ingen begrensninger, ingen typer. Data er inkonsistent, men det syns ikke på 50 rader.
Ingen migreringer — AI oppretter tabeller «i farten». I produksjon kan du ikke droppe databasen og gjenskape den — du har ekte brukerdata.

SQLite

AI bruker SQLite fordi den ikke krever noen server. Men serverløse plattformer bryter SQLite — hver forespørsel kan treffe en annen instans uten delt filsystem. Spørringer som fungerer på 50 rader tar 30 sekunder på 50 000 uten indekser.

Slik fikser du det

Bruk PostgreSQL eller MySQL i produksjon. Konfigurer tilkoblingspooling (PgBouncer, Supabase har det innebygd). Legg til indekser på kolonner brukt i WHERE og JOIN. Planlegg en migrasjonsstrategi — bruk et verktøy som Prisma Migrate, Drizzle eller vanlige SQL-filer med versjonering. Modifiser aldri produksjonsskjemaet manuelt.

Sikkerhet som ikke eksisterer

En Georgetown CSET-studie fant at 45% av AI-generert kode inneholder sikkerhetssårbarheter. Dette er ikke et marginalt problem — det er nesten halvparten av all kode. Og kode som «fungerer» på localhost trenger ikke være sikker.

En skanning av 5 600 vibe-kodede apper avslørte over 2 000 høyrisikobrister og over 400 eksponerte hemmeligheter. Plattformen Moltbook eksponerte 1,5 millioner API-nøkler — Row Level Security på Supabase ble aldri aktivert. Lovable hadde invertert tilgangskontroll over 170 produksjonsapper (CVE-2025-48757): autentiserte brukere ble blokkert mens uautentiserte fikk full tilgang.

Problemer jeg ser regelmessig:

API-nøkler hardkodet i frontend-JavaScript — hvem som helst kan åpne DevTools og kopiere dem. Jeg har sett dette flere ganger i klientapplikasjoner.
Ingen inputvalidering — SQL-injection, XSS, path traversal — AI legger sjelden til validering fordi på localhost prøver ingen å bryte seg inn i applikasjonen din.
Ingen Row Level Security — Supabase uten RLS betyr at hver bruker kan lese og modifisere alle andre brukeres data.
Ingen rate limiting — uten begrensninger kan noen kalle API-et ditt en million ganger per minutt. Resultat: API-regning, DDoS, eller begge.

Sikkerhet

45% av AI-kode inneholder sikkerhetssårbarheter. Skanning av 5 600 vibe-kodede apper: 2 000+ høyrisikobrister, 400+ eksponerte hemmeligheter. Lovable hadde invertert tilgangskontroll over 170 produksjonsapper.

Slik fikser du det

Kjør en OWASP Top 10-gjennomgang. Aktiver Row Level Security på Supabase. Valider alle inputs på serversiden (stol aldri på klienten). Skann repoet ditt etter eksponerte hemmeligheter (bruk gitleaks eller trufflehog). Legg til rate limiting på alle offentlige endepunkter. Flytt API-nøkler fra frontend til backend.

Stille feil og ressurslekkasjer

Applikasjonen din fungerer for de første 100 forespørslene. Forespørsel nummer 1 001 forårsaker en krasj — alle databasetilkoblinger er uttømt. Hvorfor? Fordi AI aldri lukket dem. Hver forespørsel åpnet en ny tilkobling, men ingen frigav den.

Det samme gjelder filhåndtak, WebSocket-lyttere, timere og abonnementer. AI oppretter ressurser men frigir dem ikke. På localhost legger du ikke merke til det fordi serveren startes på nytt hvert par minutt og tilbakestiller alt. I produksjon kjører serveren kontinuerlig — og ressursene tar slutt.

Enda verre er stille feil:

Tomme try/catch-blokker — betaling feiler, webhook avfyres ikke, men brukeren ser ingen feil. Data forsvinner stille.
Race conditions — flere samtidige API-kall løses i tilfeldig rekkefølge. Ingen idempotens betyr duplikater eller inkonsistente data.
Hot reload maskerer feil — i dev-modus viser React advarsler. I produksjonsbygget forsvinner de. En komponent kaster — hele appen blir hvit fordi det ikke finnes noen error boundaries.
Ingen global feilbehandler — et uhåndtert unntak dreper Node.js-prosessen. På localhost er omstart umiddelbar. I produksjon — nedetid.

Ressurslekkasjer

Databasetilkoblinger som aldri lukkes. Filhåndtak som blir stående åpne. WebSocket-lyttere som aldri ryddes opp. Fungerer for de første 100 forespørslene — forespørsel 1 001 krasjer fordi alle tilkoblinger er uttømt.

Slik fikser du det

Legg til error boundaries på frontend (React: ErrorBoundary). Legg til en global feilbehandler på backend (process.on('uncaughtException')). Distribuer strukturert logging (Sentry, LogRocket, Pino). Lukk databasetilkoblinger etter bruk (eller bruk tilkoblingspooling). Rydd opp lyttere og timere i useEffect cleanup. Belastningstest — å sjekke at det fungerer én gang er ikke nok.

Skadene i virkeligheten

Dette er ikke teoretiske trusler. Dette er hendelser som allerede har skjedd:

Amazon — minst fire Sev-1-hendelser fra AI-assistert utvikling, inkludert et 6-timers avbrudd (~6,3 millioner tapte bestillinger).
AWS-regningen traff $8 400/måned — etter å ha distribuert en AI-prototypet tjeneste uten kostnadsoptimalisering. AI vet ikke at t3.micro koster annerledes enn r5.4xlarge. Kostnadsskalering er noe AI aldri tenker på.
Stripe-integrasjon — brukte utdaterte API-parametere (plan i stedet for price), doble belastninger i 2 uker før noen la merke til det.
Undersøkelse av 18 CTO-er — 16 rapporterte produksjonskatastrofer direkte forårsaket av AI-generert kode.
CodeRabbit-analyse — AI-kode har 1,7x flere alvorlige problemer, 2,74x høyere XSS-sårbarheter og 8x flere ytelsesineffektiviteter enn menneskeskrevet kode.

Kostnader

AI lovet 10x-utviklere. I stedet: juniorer ble promptingenjører, seniorer ble kodevaskere. Kostnaden for å fikse AI-kode overstiger ofte kostnaden for å skrive den fra bunnen av.

Mønsteret gjentar seg: AI genererer kode som ser bra ut. Den består kodegjennomgang (fordi den er lesbar). Den består tester (fordi den tester den lykkelige stien). Så eksploderer den i produksjon fordi ingen sjekket ytelse under belastning, feilhåndtering, sikkerhet eller infrastrukturkostnader.

Hvordan du faktisk fikser det (produksjonsklar sjekkliste)

Før du ruller ut applikasjonen din, gå gjennom disse punktene. Hvert uoppfylt punkt er en potensiell produksjonsfeil. Denne sjekklisten ble bygd fra dusinvis av AI-apprevisjoner jeg har utført for kunder.

✓All konfigurasjon via miljøvariabler. Ingen hardkodede URL-er, nøkler eller hemmeligheter i kildekoden.
✓Produksjonsdatabase med indekser og tilkoblingspooling. Ikke SQLite. PostgreSQL eller MySQL med PgBouncer eller innebygd pooler.
✓HTTPS overalt, sikkerhetsheadere satt. Ingen blanding av HTTP og HTTPS. CSP, HSTS, X-Frame-Options.
✓Row Level Security / personvernregler aktivert. Hver bruker ser bare sine egne data.
✓Error boundaries på frontend, global feilbehandler på backend. Ingen feil kan stille sluke data.
✓Rate limiting på alle offentlige endepunkter. Beskyttelse mot misbruk og DDoS.
✓CI/CD-pipeline med automatiserte tester. Hver push testes før distribusjon.
✓Overvåkning og varsling (Sentry, CloudWatch). Du vet om feil før brukerne begynner å skrive.
✓Belastningstestet med realistisk trafikk. 100 samtidige brukere, ikke én.
✓Staging-miljø som speiler produksjon. Test på en kopi av produksjon, ikke localhost.
✓Databasemigrasjonsstrategi. Du planlegger skjemaendringer, gjør dem ikke ad hoc.
✓Backup- og katastrofegjenopprettingsplan. Hva skjer når databasen går ned? Har du et svar?

Vanlige spørsmål

Hvorfor fungerer alt perfekt på localhost?

Fordi localhost er et perfekt miljø: same-origin (ingen CORS), null nettverkslatens, dev-modus maskerer advarsler, du er den eneste brukeren (ingen race conditions, ingen belastning). I produksjon er hvert av disse vilkårene annerledes — og hvert av dem kan forårsake en feil.

Hva er den vanligste produksjonsfeilen?

Manglende miljøvariabler og hardkodet konfigurasjon. Det er trivielt, men det står for hoveddelen av «fungerer lokalt, feiler i produksjon»-problemene. .env-filen din har nøkler — produksjonsserveren har det ikke. AI hardkoder URL-er i kildekoden i stedet for å bruke miljøvariabler.

Hvordan vet jeg om appen min er produksjonsklar?

Enkelt spørsmål: hvis du ikke kan svare på «hva skjer når X feiler?» for hver kritisk sti, er appen din ikke klar. Hva skjer når databasen er utilgjengelig? Når Stripe-API-et returnerer en feil? Når 100 brukere klikker «Kjøp» i samme sekund? Hvis du ikke har svar — har du arbeid å gjøre.

Bør jeg skrive om fra bunnen av?

Vanligvis ikke. Start med en revisjon. Identifiser kritiske mangler (sikkerhet, database, konfigurasjon). Fiks dem punkt for punkt. En fullstendig omskriving gir bare mening når arkitekturen er fundamentalt feil — men i de fleste tilfeller kan du fikse eksisterende kode iterativt uten å tape arbeidet som er gjort så langt.

Kan jeg distribuere til Vercel/Netlify og kalle det produksjon?

Plattform er ikke lik produksjonsklar. Vercel og Netlify er flotte hostingverktøy, men hosting alene er ikke «produksjon». Du trenger fortsatt riktig CORS-konfigurasjon, overvåkning, feilhåndtering, sikkerhet, en skikkelig database og belastningstesting. «Deploy»-knappen er begynnelsen, ikke slutten.

//neste steg

Appen din fungerer lokalt men feiler i produksjon?

Vi hjelper deg identifisere og fikse hvert av disse problemene. Revisjon, fiks, distribusjon — fra prototype til produksjon.

Bestill en gratis samtale →

Gratis konsultasjon Helt uforpliktende Svar innen 24t