Varför din app fungerar lokalt men kraschar i produktion

Verkliga orsaker och konkreta lösningar. AI optimerar för en fungerande demo, inte ett produktionssystem. Med 15–30 tysta arkitekturbeslut per feature med ~70% träffsäkerhet vardera, är sannolikheten att ALLA är korrekta praktiskt taget noll.

⏱ 15 min läsning·

“Det fungerar på min maskin” är det äldsta skämtet inom mjukvaruutveckling. Med AI-genererade appar är det inget skämt — det är standardtillståndet. AI tänker inte på produktion. Den vet inte vad en lastbalanserare, anslutningspool eller hemlighetshanterare är. Den ser bara en sak: din lokala kontext, din fil, koden som körs på din maskin just nu.

När AI bygger en feature fattar den 15–30 tysta arkitekturbeslut: vilken databas, hur man ansluter till ett API, var man lagrar nycklar, hur man hanterar fel. Varje beslut har ungefär 70% chans att vara korrekt. Men för att hela featuren ska fungera i produktion måste alla beslut vara korrekta. Sannolikheten? Med 20 beslut: 0.7^20 = 0.08%. Praktiskt taget noll.

Den här artikeln tar upp de sex vanligaste orsakerna till att AI-appar fungerar lokalt men kraschar i produktion — med konkreta exempel och lösningar. Om du bygger med Cursor, Bolt, Lovable, Replit eller något annat AI-verktyg, är den här guiden för dig.

Miljö och konfiguration

Detta är den mest uppenbara och samtidigt vanligaste orsaken till produktionsfel: konfiguration som bara fungerar lokalt. Din .env-fil på din laptop har riktiga API-nycklar, korrekta URL:er, fungerande hemligheter. I produktion? Platshållare, saknade variabler eller helt andra adresser.

AI tänker aldrig på konfigurationshantering — den ser bara lokal kontext. När den genererar kod som ansluter till ett API skriver den http://localhost:3000 direkt i koden. När den behöver en API-nyckel skapar den en variabel med ett standardvärde. När den bygger en databas-URL hårdkodar den anslutningssträngen.

Typiska problem:

  • Hårdkodade URL:er — http://localhost:3000/api istället för en miljövariabel. Fungerar lokalt, pekar ingenstans i produktion.
  • Saknade miljövariabler — i produktion har du ingen .env-fil. Du måste sätta variabler i din hostingpanel (Vercel, Railway, Render).
  • HTTP vs HTTPS — lokalt använder du http://, produktion kräver https://. Att blanda protokoll orsakar webbläsarblockering (mixed content) och CORS-fel.
  • Olika API-nycklar — Stripes testnyckel vs produktionsnyckel. Firebase dev-nyckel vs prod. AI vet inte att skillnaden finns.

Så fixar du det

Externalisera ALL konfiguration. Varje URL, varje nyckel, varje hemlighet bör komma från en miljövariabel — aldrig från källkod. Använd en hemlighetshanterare (t.ex. Doppler, AWS Secrets Manager, Vercel Environment Variables). Skapa en .env.example-fil med namnet på varje krävd variabel (utan värden) och lägg till den i repot som dokumentation.

Databasantaganden

AI älskar SQLite. Den är enkel, kräver ingen server, det är bara en fil. Perfekt för en prototyp. Problemet? Serverlösa plattformar (Vercel, Netlify Functions, AWS Lambda) stödjer inte SQLite eftersom varje förfrågan kan träffa en annan instans — det finns inget delat filsystem.

Men databasen är inte bara motorn. Det är en hel uppsättning antaganden som AI gör tyst:

  • Saknade index — en förfrågan fungerar blixtsnabbt på 50 rader. På 50 000? Tar 30 sekunder. AI lägger inte till index eftersom skillnaden inte syns på små datamängder.
  • Ingen anslutningspoolning — varje HTTP-förfrågan öppnar en ny databasanslutning. Med 100 samtidiga användare har du 100 öppna anslutningar. Databaser har gränser — vanligtvis 20–100 anslutningar. Överskrider du det: krasch.
  • Schema som ser bra ut i en demo — inga relationer, inga begränsningar, inga typer. Data är inkonsekvent, men det syns inte på 50 rader.
  • Inga migrationer — AI skapar tabeller “i farten”. I produktion kan du inte droppa databasen och återskapa den — du har riktig användardata.

Så fixar du det

Använd PostgreSQL eller MySQL i produktion. Konfigurera anslutningspoolning (PgBouncer, Supabase har det inbyggt). Lägg till index på kolumner som används i WHERE och JOIN. Planera en migrationsstrategi — använd ett verktyg som Prisma Migrate, Drizzle eller vanliga SQL-filer med versionering. Modifiera aldrig ditt produktionsschema manuellt.

Säkerhet som inte existerar

Veracodes rapport ”2025 GenAI Code Security Report” fann att LLM:er införde en OWASP Top 10-sårbarhet i 45% av testfallen. Georgetown-institutet CSET fick ett liknande resultat: nästan hälften av de kodsnuttar deras utvärdering producerade innehöll utnyttjbara buggar. Det här är inte ett marginellt problem. Och kod som “fungerar” på localhost behöver inte vara säker.

En skanning av 5 600 vibe-kodade appar, gjord av Escape.tech, avslöjade över 2 000 högriskbrister och över 400 exponerade hemligheter. Agentplattformen Moltbook exponerade 1,5 miljoner API-tokens genom en felkonfigurerad Supabase-databas utan effektiv Row Level Security. Och en skanning av Lovable-byggda appar fann 170 projekt — ungefär en av tio analyserade — som exponerade sina databaser genom saknad RLS (CVE-2025-48757): vem som helst oautentiserad kunde läsa och skriva godtyckliga tabeller.

Problem jag ser regelbundet:

  • API-nycklar hårdkodade i frontend-JavaScript — vem som helst kan öppna DevTools och kopiera dem. Jag har sett det här många gånger i klientapplikationer.
  • Ingen inputvalidering — SQL-injection, XSS, path traversal — AI lägger sällan till validering, eftersom ingen försöker bryta sig in i din applikation på localhost.
  • Ingen Row Level Security — Supabase utan RLS innebär att varje användare kan läsa och modifiera alla andra användares data.
  • Ingen rate limiting — utan begränsningar kan någon anropa ditt API en miljon gånger per minut. Resultat: en skyhög API-räkning, en DDoS, eller båda.

Så fixar du det

Kör en OWASP Top 10-granskning. Aktivera Row Level Security på Supabase. Validera alla inputs på serversidan (lita aldrig på klienten). Skanna ditt repo efter exponerade hemligheter (använd gitleaks eller trufflehog). Lägg till rate limiting på alla publika endpoints. Flytta API-nycklar från frontend till backend.

Tysta fel och resursläckor

Din applikation fungerar för de första 100 förfrågningarna. Förfrågan nummer 1 001 orsakar en krasch — alla databasanslutningar är uttömda. Varför? För att AI aldrig stängde dem. Varje förfrågan öppnade en ny anslutning, men ingen frigav den.

Samma sak gäller filhandtag, WebSocket-lyssnare, timers och prenumerationer. AI skapar resurser men frigör dem inte. På localhost märker du inte det, eftersom servern startas om med några minuters mellanrum och återställer allt. I produktion kör servern kontinuerligt — och resurserna tar slut.

Ännu värre är tysta fel:

  • Tomma try/catch-block — betalning misslyckas, webhook avfyras inte, men användaren ser inget fel. Data försvinner tyst.
  • Race conditions — flera samtidiga API-anrop löses i slumpmässig ordning. Ingen idempotens innebär dubbletter eller inkonsekvent data.
  • Hot reload maskerar fel — i dev-läge visar React varningar. I produktionsbygget försvinner de. En komponent kastar — hela appen blir vit för att det inte finns några error boundaries.
  • Ingen global felhanterare — ett ohanterat undantag dödar Node.js-processen. På localhost är omstart omedelbar. I produktion — nedtid.

Så fixar du det

Lägg till error boundaries på frontend (React: ErrorBoundary). Lägg till en global felhanterare på backend (process.on('uncaughtException')). Driftsätt strukturerad loggning (Sentry, LogRocket, Pino). Stäng databasanslutningar efter användning (eller använd anslutningspoolning). Rensa lyssnare och timers i useEffect cleanup. Belastningstesta — att kontrollera att det fungerar en gång räcker inte.

Skadorna i verkligheten

Det här är inte teoretiska hot. Det här är incidenter som redan har hänt:

  • Amazon — fyra Sev-1-incidenter i detaljhandeln på en enda vecka, inklusive ett sex timmars kassaatbrott som interna dokument knöt till ungefär 6,3 miljoner förlorade beställningar. Bevakningen kopplade trenden till GenAI-assisterade ändringar; Amazon bestrider att AI-skriven kod var inblandad. Hur som helst: även Amazon kräver nu extra granskning av AI-assisterade produktionsändringar.
  • Okontrollerade molnräkningar — AI-prototypade tjänster som driftsätts utan kostnadskontroll överraskar regelbundet sina ägare. AI vet inte att t3.micro kostar annorlunda än r5.4xlarge. Kostnadsskalning är något AI aldrig tänker på.
  • Stripe-integrationer — webhookhanterare byggda mot föråldrade API-format har skeppat dubbeldebiteringar i veckor innan någon märkte det.
  • Final Round AIs undersökning av 18 CTO:er — 16 rapporterade produktionskatastrofer direkt orsakade av AI-genererad kod.
  • CodeRabbits analys av 470 open source-PR:er — AI-medförfattad kod hade ~1,7x fler problem totalt, ungefär 2,7x fler XSS-klassade fynd och ~8x fler prestandaproblem av typen överdrivna I/O-operationer än människoskriven kod.

Mönstret upprepas: AI genererar kod som ser bra ut. Den klarar kodgranskning (för den är läsbar). Den klarar tester (för den testar det lyckade scenariot). Sedan exploderar den i produktion för att ingen kontrollerade prestanda under belastning, felhantering, säkerhet eller infrastrukturkostnader.

Hur du faktiskt fixar det (produktionsklar checklista)

Innan du driftsätter din applikation, gå igenom dessa punkter. Varje ouppfylld punkt är ett potentiellt produktionsfel. Denna checklista byggdes från dussintal AI-appgranskningar jag genomfört för kunder.

  • All konfiguration via miljövariabler. Inga hårdkodade URL:er, nycklar eller hemligheter i källkoden.
  • Produktionsdatabas med index och anslutningspoolning. Inte SQLite. PostgreSQL eller MySQL med PgBouncer eller inbyggd pooler.
  • HTTPS överallt, säkerhetsheaders inställda. Ingen blandning av HTTP och HTTPS. CSP, HSTS, X-Frame-Options.
  • Row Level Security / sekretessregler aktiverade. Varje användare ser bara sin egen data.
  • Error boundaries på frontend, global felhanterare på backend. Inget fel kan tyst svälja data.
  • Rate limiting på alla publika endpoints. Skydd mot missbruk och DDoS.
  • CI/CD-pipeline med automatiserade tester. Varje push testas innan driftsättning.
  • Övervakning och larm (Sentry, CloudWatch). Du får reda på fel innan dina användare gör det.
  • Belastningstestad med realistisk trafik. 100 samtidiga användare, inte en.
  • Stagingmiljö som speglar produktion. Testa på en kopia av produktion, inte localhost.
  • Databas-migrationsstrategi. Du planerar schemaändringar, gör dem inte ad hoc.
  • Backup- och katastrofåterställningsplan. Vad händer när databasen går ner? Har du ett svar?

Vanliga frågor

Varför fungerar allt perfekt på localhost?

För att localhost är en perfekt miljö: same-origin (ingen CORS), noll nätverkslatens, dev-läge maskerar varningar, du är den enda användaren (inga race conditions, ingen belastning). I produktion är vart och ett av dessa villkor annorlunda — och vilket som helst av dem kan orsaka ett fel.

Vad är det vanligaste produktionsfelet?

Saknade miljövariabler och hårdkodad konfiguration. Det är trivialt, men det står för majoriteten av “fungerar lokalt, misslyckas i produktion”-problemen. Din .env har nycklar — produktionsservern har det inte. AI hårdkodar URL:er i källkoden istället för att använda miljövariabler.

Hur vet jag om min app är produktionsklar?

Enkel fråga: om du inte kan svara på “vad händer när X går fel?” för varje kritiskt flöde, är din app inte klar. Vad händer när databasen är otillgänglig? När Stripe-API:et returnerar ett fel? När 100 användare klickar “Köp” samma sekund? Om du inte har svar — har du arbete att göra.

Borde jag skriva om från början?

Vanligtvis inte. Börja med en granskning. Identifiera kritiska brister (säkerhet, databas, konfiguration). Fixa dem punkt för punkt. En fullständig omskrivning är bara meningsfull när arkitekturen är fundamentalt felaktig — men i de flesta fall kan du fixa befintlig kod iterativt utan att förlora det arbete som gjorts hittills.

Kan jag driftsätta på Vercel/Netlify och kalla det produktion?

Plattform är inte lika med produktionsklar. Vercel och Netlify är utmärkta hostingverktyg, men hosting ensamt är inte “produktion”. Du behöver fortfarande korrekt CORS-konfiguration, övervakning, felhantering, säkerhet, en riktig databas och belastningstester. Knappen “Deploy” är början, inte slutet.

// nästa steg

Din app fungerar lokalt men kraschar i produktion?

Jag hjälper dig identifiera och fixa vart och ett av dessa problem. Granskning, fix, driftsättning — från prototyp till produktion.

Boka ett gratis samtal →
Gratis konsultation Utan förpliktelser Svar inom 24h