← Strona główna← Home← Startsida← Hjem
Dlaczego Twoja aplikacja działa lokalnie, ale nie na produkcji

Prawdziwe przyczyny i konkretne rozwiązania. AI optymalizuje pod działające demo, nie pod system produkcyjny. Przy 15–30 cichych decyzjach architektonicznych na feature z dokładnością ~70% każdej, szansa że wszystkie są poprawne jest praktycznie zerowa.

⏱ 15 min czytania

Why Your App Works Locally But Fails in Production

Real reasons and concrete fixes. AI optimizes for a working demo, not a production system. With 15–30 silent architectural decisions per feature at ~70% accuracy each, the probability of ALL being correct is practically zero.

⏱ 15 min read
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
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

«Działa na mojej maszynie» to najstarszy żart w inżynierii oprogramowania. Ale przy aplikacjach generowanych przez AI to nie jest żart — to stan domyślny. AI nie myśli o produkcji. Nie wie, czym jest load balancer, connection pool czy secrets manager. Widzi tylko jedno: Twój lokalny kontekst, Twój plik, Twoją próbę uruchomienia.

Kiedy AI buduje feature, podejmuje 15–30 cichych decyzji architektonicznych: jaka baza danych, jak łączyć się z API, gdzie trzymać klucze, jak obsługiwać błędy. Każda z tych decyzji ma mniej więcej 70% szans na bycie poprawną. Ale żeby cały feature działał na produkcji, wszystkie decyzje muszą być poprawne. Prawdopodobieństwo? Przy 20 decyzjach: 0.7^20 = 0.08%. Praktycznie zero.

Ten artykuł opisuje sześć najczęstszych powodów, dla których aplikacje AI działają lokalnie i padają na produkcji — z konkretnymi przykładami i rozwiązaniami. Jeśli budujesz z Cursor, Bolt, Lovable, Replit lub innym narzędziem AI, ten poradnik jest dla Ciebie.

“It works on my machine” is the oldest joke in software engineering. With AI-generated apps, it’s not a joke — it’s the default state. AI doesn’t think about production. It doesn’t know what a load balancer, connection pool, or secrets manager is. It sees only one thing: your local context, your file, your attempt to run it.

When AI builds a feature, it makes 15–30 silent architectural decisions: which database, how to connect to an API, where to store keys, how to handle errors. Each decision has roughly a 70% chance of being correct. But for the entire feature to work in production, all decisions must be correct. The probability? With 20 decisions: 0.7^20 = 0.08%. Practically zero.

This article covers the six most common reasons AI apps work locally and crash in production — with concrete examples and fixes. If you’re building with Cursor, Bolt, Lovable, Replit, or any other AI tool, this guide is for you.

“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, ditt försök att köra den.

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.

«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.

01

Środowisko i konfiguracja Environment & Configuration Miljö och konfiguration Miljø og konfigurasjon

To najbardziej banalny i jednocześnie najczęstszy powód awarii na produkcji: konfiguracja, która działa tylko lokalnie. Twój plik .env na laptopie ma prawdziwe klucze API, poprawne URL-e, działające sekrety. Na produkcji? Placeholdery, brakujące zmienne, albo zupełnie inne adresy.

AI nigdy nie myśli o zarządzaniu konfiguracjami — widzi tylko lokalny kontekst. Kiedy generuje kod, który łączy się z API, wpisuje http://localhost:3000 bezpośrednio w kodzie. Kiedy potrzebuje klucza API, tworzy zmienną z domyślną wartością. Kiedy buduje URL do bazy danych, hardcoduje string połączenia.

Typowe problemy:

  • Hardcoded URL-e — http://localhost:3000/api zamiast zmiennej środowiskowej. Działa lokalnie, w produkcji wskazuje na nikąd.
  • Brakujące zmienne środowiskowe — na produkcji nie masz pliku .env. Musisz ustawić zmienne w panelu hostingu (Vercel, Railway, Render).
  • HTTP vs HTTPS — lokalnie używasz http://, produkcja wymaga https://. Mieszanie protokołów powoduje blokowanie przez przeglądarkę (mixed content) i błędy CORS.
  • Różne klucze API — klucz testowy Stripe vs produkcyjny. Klucz dev Firebase vs prod. AI nie wie, że istnieje różnica.
Konfiguracja

Twój lokalny .env ma prawdziwe klucze. Produkcja może mieć placeholdery, błędne URL-e albo brakujące sekrety. AI nigdy nie myśli o zarządzaniu konfiguracjami — widzi tylko lokalny kontekst.

Jak to naprawić

Externalizuj CAŁĄ konfigurację. Każdy URL, każdy klucz, każdy sekret powinien pochodzić ze zmiennej środowiskowej — nigdy z kodu źródłowego. Użyj secrets managera (np. Doppler, AWS Secrets Manager, Vercel Environment Variables). Stwórz plik .env.example z nazwą każdej wymaganej zmiennej (bez wartości) i dodaj go do repozytorium jako dokumentację.

This is the most obvious and simultaneously most common reason for production failures: configuration that only works locally. Your .env file on your laptop has real API keys, correct URLs, working secrets. In production? Placeholders, missing variables, or entirely different addresses.

AI never thinks about configuration management — it only sees local context. When it generates code that connects to an API, it writes http://localhost:3000 directly in the code. When it needs an API key, it creates a variable with a default value. When it builds a database URL, it hardcodes the connection string.

Typical problems:

  • Hardcoded URLs — http://localhost:3000/api instead of an environment variable. Works locally, points to nowhere in production.
  • Missing environment variables — in production you don’t have a .env file. You need to set variables in your hosting panel (Vercel, Railway, Render).
  • HTTP vs HTTPS — locally you use http://, production requires https://. Mixing protocols causes browser blocking (mixed content) and CORS errors.
  • Different API keys — Stripe test key vs production key. Firebase dev key vs prod. AI doesn’t know the difference exists.
Configuration

Your local .env has real keys. Production might have placeholders, wrong URLs, or missing secrets. AI never thinks about config management — it only sees local context.

How to fix it

Externalize ALL configuration. Every URL, every key, every secret should come from an environment variable — never from source code. Use a secrets manager (e.g., Doppler, AWS Secrets Manager, Vercel Environment Variables). Create an .env.example file with the name of every required variable (without values) and add it to the repository as documentation.

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 hardkodar den anslutningssträngen.

Typiska problem:

  • Hardkodade 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.
Konfiguration

Din lokala .env har riktiga nycklar. Produktion kan ha platshållare, felaktiga URL:er eller saknade hemligheter. AI tänker aldrig på konfigurationshantering — den ser bara lokal kontext.

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.

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.

02

Założenia dotyczące bazy danych Database Assumptions Databasantaganden Databaseantakelser

AI kocha SQLite. Jest prosta, nie wymaga serwera, to tylko plik. Idealnie nadaje się do prototypu. Problem? Platformy serverless (Vercel, Netlify Functions, AWS Lambda) nie obsługują SQLite, bo każde zapytanie może trafić na inną instancję — nie ma współdzielonego systemu plików.

Ale baza danych to nie tylko silnik. To cały zestaw założeń, które AI robi cicho:

  • Brak indeksów — zapytanie działa błyskawicznie na 50 rekordach. Na 50 000? Trwa 30 sekund. AI nie dodaje indeksów, bo na małych danych nie widać różnicy.
  • Brak connection poolingu — każde zapytanie HTTP otwiera nowe połączenie z bazą. Przy 100 równoczesnych użytkownikach masz 100 otwartych połączeń. Baza danych ma limit — zwykle 20–100 połączeń. Po przekroczeniu: awaria.
  • Schema, która wygląda dobrze w demo — brak relacji, brak constraintów, brak typów. Dane są niespójne, ale na 50 rekordach tego nie widać.
  • Brak migracji — AI tworzy tabele «w locie». Na produkcji nie możesz dropnąć bazy i stworzyć jej od nowa — masz prawdziwe dane użytkowników.
SQLite

AI używa SQLite, bo nie wymaga serwera. Ale platformy serverless łamią SQLite — każde zapytanie może trafić na inną instancję bez współdzielonego systemu plików. Zapytania, które działają na 50 rekordach, trwają 30 sekund na 50 000 bez indeksów.

Jak to naprawić

Użyj PostgreSQL lub MySQL na produkcji. Skonfiguruj connection pooling (PgBouncer, Supabase ma to wbudowane). Dodaj indeksy na kolumnach używanych w WHERE i JOIN. Zaplanuj strategię migracji — użyj narzędzia jak Prisma Migrate, Drizzle, albo zwykłych plików SQL z wersjonowaniem. Nigdy nie modyfikuj schematu produkcyjnego ręcznie.

AI loves SQLite. It’s simple, requires no server, it’s just a file. Perfect for a prototype. The problem? Serverless platforms (Vercel, Netlify Functions, AWS Lambda) don’t support SQLite because each request can hit a different instance — there’s no shared filesystem.

But the database isn’t just the engine. It’s a whole set of assumptions AI makes silently:

  • Missing indexes — a query works instantly on 50 rows. On 50,000? Takes 30 seconds. AI doesn’t add indexes because on small data there’s no visible difference.
  • No connection pooling — every HTTP request opens a new database connection. With 100 concurrent users, you have 100 open connections. Databases have limits — usually 20–100 connections. Exceed that: crash.
  • Schema that looks fine in a demo — no relations, no constraints, no types. Data is inconsistent, but you can’t tell with 50 rows.
  • No migrations — AI creates tables “on the fly.” In production you can’t drop the database and recreate it — you have real user data.
SQLite

AI uses SQLite because it requires no server. But serverless platforms break SQLite — each request can hit a different instance with no shared filesystem. Queries that work on 50 rows take 30 seconds on 50,000 without indexes.

How to fix it

Use PostgreSQL or MySQL in production. Configure connection pooling (PgBouncer, Supabase has it built-in). Add indexes on columns used in WHERE and JOIN. Plan a migration strategy — use a tool like Prisma Migrate, Drizzle, or plain SQL files with versioning. Never modify your production schema manually.

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 på små data syns ingen skillnad.
  • 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.
SQLite

AI använder SQLite för att den inte kräver någon server. Men serverlösa plattformar bryter SQLite — varje förfrågan kan träffa en annan instans utan delat filsystem. Förfrågningar som fungerar på 50 rader tar 30 sekunder på 50 000 utan index.

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.

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.

03

Bezpieczeństwo, które nie istnieje Security That Doesn’t Exist Säkerhet som inte existerar Sikkerhet som ikke eksisterer

Badanie Georgetown CSET wykazało, że 45% kodu generowanego przez AI zawiera luki bezpieczeństwa. To nie jest marginalny problem — to niemal połowa całego kodu. A kod, który «działa» na localhost, nie musi być bezpieczny.

Skan 5 600 aplikacji zbudowanych metodą vibecoding ujawnił ponad 2 000 luk o wysokim wpływie i ponad 400 ujawnionych sekretów. Platforma Moltbook ujawniła 1,5 miliona kluczy API — Row Level Security na Supabase nigdy nie zostało włączone. Lovable miał odwróconą kontrolę dostępu w 170 aplikacjach produkcyjnych (CVE-2025-48757): uwierzytelnieni użytkownicy byli blokowani, a nieuwierzytelnieni dostawali pełny dostęp.

Problemy, które widzę regularnie:

  • Klucze API hardcoded w JavaScript frontendu — każdy może otworzyć DevTools i je skopiować. Widziałem to wielokrotnie w aplikacjach klientów.
  • Brak walidacji inputów — SQL injection, XSS, path traversal — AI rzadko dodaje walidację, bo na localhost nikt nie próbuje włamać się do Twojej aplikacji.
  • Brak Row Level Security — Supabase bez RLS oznacza, że każdy użytkownik może czytać i modyfikować dane wszystkich innych użytkowników.
  • Brak rate limitingu — bez ograniczeń ktoś może wywołać Twoje API milion razy na minutę. Wynik: rachunek za API, DDoS, albo oba.
Bezpieczeństwo

45% kodu AI zawiera luki bezpieczeństwa. Skan 5 600 vibe-coded aplikacji: 2 000+ luk o wysokim wpływie, 400+ ujawnionych sekretów. Lovable miał odwróconą kontrolę dostępu w 170 produkcyjnych aplikacjach.

Jak to naprawić

Przeprowadź audyt OWASP Top 10. Włącz Row Level Security na Supabase. Waliduj wszystkie inputy po stronie serwera (nigdy nie ufaj klientowi). Przeskanuj repozytorium pod kątem ujawnionych sekretów (użyj gitleaks lub trufflehog). Dodaj rate limiting na wszystkich publicznych endpointach. Przenieś klucze API z frontendu do backendu.

A Georgetown CSET study found that 45% of AI-generated code contains security vulnerabilities. This isn’t a marginal problem — it’s nearly half of all code. And code that “works” on localhost doesn’t have to be secure.

A scan of 5,600 vibe-coded apps revealed over 2,000 high-impact vulnerabilities and over 400 exposed secrets. The platform Moltbook exposed 1.5 million API keys — Row Level Security on Supabase was never enabled. Lovable had inverted access control across 170 production apps (CVE-2025-48757): authenticated users were blocked while unauthenticated users got full access.

Problems I see regularly:

  • API keys hardcoded in frontend JavaScript — anyone can open DevTools and copy them. I’ve seen this multiple times in client applications.
  • No input validation — SQL injection, XSS, path traversal — AI rarely adds validation because on localhost nobody tries to break into your application.
  • No Row Level Security — Supabase without RLS means every user can read and modify every other user’s data.
  • No rate limiting — without limits someone can call your API a million times per minute. Result: API bill, DDoS, or both.
Security

45% of AI code contains security vulnerabilities. Scan of 5,600 vibe-coded apps: 2,000+ high-impact vulnerabilities, 400+ exposed secrets. Lovable had inverted access control across 170 production apps.

How to fix it

Run an OWASP Top 10 audit. Enable Row Level Security on Supabase. Validate all inputs server-side (never trust the client). Scan your repository for exposed secrets (use gitleaks or trufflehog). Add rate limiting on all public endpoints. Move API keys from frontend to backend.

En Georgetown CSET-studie fann att 45% av AI-genererad kod innehåller säkerhetsbrister. Det här är inte ett marginellt problem — det är nästan hälften av all kod. Och kod som “fungerar” på localhost behöver inte vara säker.

En skanning av 5 600 vibe-kodade appar avslöjade över 2 000 högriskbrister och över 400 exponerade hemligheter. Plattformen Moltbook exponerade 1,5 miljoner API-nycklar — Row Level Security på Supabase aktiverades aldrig. Lovable hade inverterad åtkomstkontroll över 170 produktionsappar (CVE-2025-48757): autentiserade användare blockerades medan oautentiserade fick full åtkomst.

Problem jag ser regelbundet:

  • API-nycklar hardkodade 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 för på localhost försöker ingen bryta sig in i din applikation.
  • 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: API-räkning, DDoS, eller båda.
Säkerhet

45% av AI-kod innehåller säkerhetsbrister. Skanning av 5 600 vibe-kodade appar: 2 000+ högriskbrister, 400+ exponerade hemligheter. Lovable hade inverterad åtkomstkontroll över 170 produktionsappar.

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.

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.

04

Ciche awarie i wycieki zasobów Silent Failures & Resource Leaks Tysta fel och resursläckor Stille feil og ressurslekkasjer

Twoja aplikacja działa przez pierwsze 100 zapytań. Zapytanie numer 1 001 powoduje awarię — wszystkie połączenia z bazą są wyczerpane. Dlaczego? Bo AI nigdy nie zamknęło połączeń. Każde zapytanie otwierało nowe połączenie, ale żadne go nie zwalniało.

To samo dotyczy uchwytów plików, listenerów WebSocket, timerów i subskrypcji. AI tworzy zasoby, ale ich nie zwalnia. Na localhost nie widać tego, bo restartowanie serwera co kilka minut resetuje wszystko. Na produkcji serwer działa bez przerwy — i zasoby się kończą.

Jeszcze gorsze są ciche błędy:

  • Puste bloki try/catch — płatność nie przechodzi, webhook nie wystrzeliwuje, ale użytkownik nie widzi żadnego błędu. Dane znikają po cichu.
  • Race conditions — wiele równoczesnych wywołań API rozwiązuje się w losowej kolejności. Brak idempotentności oznacza duplikaty lub niespójne dane.
  • Hot reload maskuje błędy — w trybie developerskim React wyświetla ostrzeżenia. W buildzie produkcyjnym znikają. Jeden komponent rzuca błąd — cała aplikacja bieleje, bo nie ma error boundaries.
  • Brak globalnego error handlera — nieobsłużony wyjątek zabija proces Node.js. Na localhost restartowanie jest natychmiastowe. Na produkcji — downtime.
Wycieki zasobów

Połączenia z bazą, które nigdy nie są zamykane. Uchwyty plików, które pozostają otwarte. Listenery WebSocket, które nie są sprzątane. Działa przez pierwsze 100 zapytań — zapytanie 1 001 powoduje awarię.

Jak to naprawić

Dodaj error boundaries na frontendzie (React: ErrorBoundary). Dodaj globalny error handler na backendzie (process.on('uncaughtException')). Wdrażaj strukturalne logowanie (Sentry, LogRocket, Pino). Zamykaj połączenia z bazą po użyciu (albo użyj connection poolingu). Sprzątaj listenery i timery w useEffect cleanup. Testuj pod obciążeniem — nie wystarczy sprawdzić, że działa raz.

Your application works for the first 100 requests. Request 1,001 causes a crash — all database connections are exhausted. Why? Because AI never closed them. Every request opened a new connection, but none released it.

The same applies to file handles, WebSocket listeners, timers, and subscriptions. AI creates resources but doesn’t release them. On localhost you don’t notice because restarting the server every few minutes resets everything. In production the server runs continuously — and resources run out.

Even worse are silent failures:

  • Empty try/catch blocks — payment fails, webhook doesn’t fire, but the user sees no error. Data disappears silently.
  • Race conditions — multiple concurrent API calls resolve in random order. No idempotency means duplicates or inconsistent data.
  • Hot reload masks errors — in dev mode React shows warnings. In the production build they vanish. One component throws — the entire app goes white because there are no error boundaries.
  • No global error handler — an unhandled exception kills the Node.js process. On localhost restarting is instant. In production — downtime.
Resource leaks

Database connections that are never closed. File handles left open. WebSocket listeners never cleaned up. Works for the first 100 requests — request 1,001 crashes because all connections are exhausted.

How to fix it

Add error boundaries on the frontend (React: ErrorBoundary). Add a global error handler on the backend (process.on('uncaughtException')). Deploy structured logging (Sentry, LogRocket, Pino). Close database connections after use (or use connection pooling). Clean up listeners and timers in useEffect cleanup. Load test — checking that it works once isn’t enough.

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 för att servern startas om var några minut och återställer allt. I produktion kör servern kontinuerligt — och resurser 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.
Resursläckor

Databasanslutningar som aldrig stängs. Filhandtag som lämnas öppna. WebSocket-lyssnare som aldrig rensas. Fungerar för de första 100 förfrågningarna — förfrågan 1 001 kraschar för alla anslutningar är uttömda.

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.

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.

05

Prawdziwe szkody The Real-World Damage Skadorna i verkligheten Skadene i virkeligheten

To nie są teoretyczne zagrożenia. To incydenty, które już się wydarzyły:

  • Amazon — co najmniej cztery incydenty Sev-1 spowodowane kodem wspomaganym przez AI, w tym 6-godzinna awaria (~6,3 miliona utraconych zamówień).
  • Rachunek AWS $8 400/miesiąc — po wdrożeniu usługi prototypowanej przez AI bez optymalizacji kosztów. AI nie wie, że t3.micro kosztuje inaczej niż r5.4xlarge. Skalowanie kosztów to coś, o czym AI w ogóle nie myśli.
  • Integracja Stripe — używała przestarzałych parametrów API (plan zamiast price), podwójne naliczenia przez 2 tygodnie zanim ktoś zauważył.
  • Ankieta 18 CTO — 16 z nich zgłosiło katastrofy produkcyjne bezpośrednio spowodowane kodem wygenerowanym przez AI.
  • Analiza CodeRabbit — kod AI ma 1,7x więcej poważnych problemów, 2,74x więcej podatności XSS i 8x więcej nieefektywności wydajnościowych niż kod pisany przez ludzi.
Koszty

AI obiecało 10x developers. W praktyce: juniorzy zostali prompt engineerami, seniorzy zostali sprzątaczami kodu. Koszt naprawy kodu AI często przewyższa koszt napisania go od zera.

Wzorzec powtarza się: AI generuje kod, który wygląda dobrze. Przechodzi code review (bo jest czytelny). Przechodzi testy (bo testuje szczęśliwą ścieżkę). A potem wybucha na produkcji, bo nikt nie sprawdził wydajności pod obciążeniem, obsługi błędów, bezpieczeństwa ani kosztów infrastruktury.

These aren’t theoretical threats. These are incidents that have already happened:

  • Amazon — at least four Sev-1 incidents from AI-assisted development, including a 6-hour outage (~6.3 million lost orders).
  • AWS bill hit $8,400/month — after deploying an AI-prototyped service without cost optimization. AI doesn’t know that t3.micro costs differently than r5.4xlarge. Cost scaling is something AI never thinks about.
  • Stripe integration — used deprecated API parameters (plan instead of price), duplicate charges for 2 weeks before anyone noticed.
  • Survey of 18 CTOs — 16 reported production disasters directly caused by AI-generated code.
  • CodeRabbit analysis — AI code has 1.7x more major issues, 2.74x higher XSS vulnerabilities, and 8x more performance inefficiencies than human-written code.
Costs

AI promised 10x developers. Instead: juniors became prompt engineers, seniors became code janitors. The cost of fixing AI code often exceeds the cost of writing it from scratch.

The pattern repeats: AI generates code that looks good. It passes code review (because it’s readable). It passes tests (because it tests the happy path). Then it explodes in production because nobody checked performance under load, error handling, security, or infrastructure costs.

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

  • Amazon — minst fyra Sev-1-incidenter från AI-assisterad utveckling, inklusive ett 6-timmars avbrott (~6,3 miljoner förlorade beställningar).
  • AWS-räkningen träffade $8 400/månad — efter att ha driftsätt en AI-prototypad tjänst utan kostnadsoptimering. AI vet inte att t3.micro kostar annorlunda än r5.4xlarge. Kostnadsskalning är något AI aldrig tänker på.
  • Stripe-integration — använde föråldrade API-parametrar (plan istället för price), dubbeldebiteringar i 2 veckor innan någon märkte.
  • Undersökning av 18 CTO:er — 16 rapporterade produktionskatastrofer direkt orsakade av AI-genererad kod.
  • CodeRabbit-analys — AI-kod har 1,7x fler allvarliga problem, 2,74x högre XSS-sårbarheter och 8x fler prestandaineffektiviteter än människoskriven kod.
Kostnader

AI lovade 10x-utvecklare. Istället: juniorer blev promptingenjörer, seniorer blev kodstädare. Kostnaden för att fixa AI-kod överstiger ofta kostnaden för att skriva den från början.

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 den lyckliga vägen). Sedan exploderar den i produktion för att ingen kontrollerade prestanda under belastning, felhantering, säkerhet eller infrastrukturkostnader.

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.

06

Jak to naprawdę naprawić (checklista produkcyjna) How to Actually Fix It (Production-Ready Checklist) Hur du faktiskt fixar det (produktionsklar checklista) Hvordan du faktisk fikser det (produksjonsklar sjekkliste)

Zanim wdrożysz swoją aplikację, przejdź przez te punkty. Każdy niespełniony punkt to potencjalna awaria na produkcji. Ta checklista powstała na podstawie dziesiątek audytów aplikacji AI, które przeprowadziłem dla klientów.

  • ✓Cała konfiguracja przez zmienne środowiskowe. Żadnych hardcoded URL-i, kluczy ani sekretów w kodzie źródłowym.
  • ✓Produkcyjna baza danych z indeksami i connection poolingiem. Nie SQLite. PostgreSQL lub MySQL z PgBouncer lub wbudowanym poolerem.
  • ✓HTTPS wszędzie, nagłówki bezpieczeństwa ustawione. Żadnego mieszania HTTP i HTTPS. CSP, HSTS, X-Frame-Options.
  • ✓Row Level Security / reguły prywatności włączone. Każdy użytkownik widzi tylko swoje dane.
  • ✓Error boundaries na frontendzie, globalny error handler na backendzie. Żaden błąd nie może cicho połknąć danych.
  • ✓Rate limiting na wszystkich publicznych endpointach. Ochrona przed nadużyciem i DDoS.
  • ✓Pipeline CI/CD z automatycznymi testami. Każdy push jest testowany przed wdrożeniem.
  • ✓Monitoring i alerty (Sentry, CloudWatch). Wiesz o błędach zanim użytkownicy zaczną pisać.
  • ✓Testy obciążeniowe z realistycznym ruchem. 100 równoczesnych użytkowników, nie jeden.
  • ✓Środowisko staging odzwierciedlające produkcję. Testuj na kopii produkcji, nie na localhost.
  • ✓Strategia migracji bazy danych. Planujesz zmiany schematu, nie robisz ich ad hoc.
  • ✓Plan backupu i disaster recovery. Co się stanie, jak baza padnie? Masz odpowiedź?

Before you deploy your application, go through these points. Every unmet point is a potential production failure. This checklist was built from dozens of AI app audits I’ve conducted for clients.

  • ✓All config via environment variables. No hardcoded URLs, keys, or secrets in source code.
  • ✓Production database with indexes and connection pooling. Not SQLite. PostgreSQL or MySQL with PgBouncer or built-in pooler.
  • ✓HTTPS everywhere, security headers set. No mixing HTTP and HTTPS. CSP, HSTS, X-Frame-Options.
  • ✓Row-level security / privacy rules enabled. Every user sees only their own data.
  • ✓Error boundaries on frontend, global error handler on backend. No error can silently swallow data.
  • ✓Rate limiting on all public endpoints. Protection against abuse and DDoS.
  • ✓CI/CD pipeline with automated tests. Every push is tested before deployment.
  • ✓Monitoring and alerting (Sentry, CloudWatch). You know about errors before users start writing.
  • ✓Load tested with realistic traffic. 100 concurrent users, not one.
  • ✓Staging environment mirroring production. Test on a copy of production, not localhost.
  • ✓Database migration strategy. You plan schema changes, not do them ad hoc.
  • ✓Backup and disaster recovery plan. What happens when the database goes down? Do you have an answer?

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 hardkodade 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 vet om fel innan användare börjar skriva.
  • ✓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?

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?

Często zadawane pytania Frequently Asked Questions Vanliga frågor Vanlige spørsmål

Dlaczego wszystko działa idealnie na localhost?

Dlatego, że localhost to idealne środowisko: same-origin (brak CORS), zerowa latencja sieciowa, tryb developerski maskuje ostrzeżenia, Ty jesteś jedynym użytkownikiem (brak race conditions, brak obciążenia). Na produkcji każdy z tych warunków jest inny — i każdy może spowodować awarię.

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.

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 varje ett av dessa villkor annorlunda — och något av dem kan orsaka ett fel.

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.

Co jest najczęstszym powodem awarii na produkcji?

Brakujące zmienne środowiskowe i hardcoded konfiguracja. To banalne, ale odpowiada za większość awarii «działa lokalnie, nie działa na produkcji». Twój .env ma klucze — serwer produkcyjny nie. AI hardcoduje URL-e w kodzie źródłowym zamiast używać zmiennych środowiskowych.

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.

Vad är det vanligaste produktionsfelet?

Saknade miljövariabler och hardkodad 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 hardkodar URL:er i källkoden istället för att använda miljövariabler.

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.

Skąd wiem, czy moja aplikacja jest gotowa na produkcję?

Proste pytanie: jeśli nie potrafisz odpowiedzieć «co się stanie, kiedy X padnie?» dla każdej krytycznej ścieżki, Twoja aplikacja nie jest gotowa. Co się stanie, kiedy baza danych będzie niedostępna? Co się stanie, kiedy API Stripe zwróci błąd? Co się stanie, kiedy 100 użytkowników kliknie «Kup» w tej samej sekundzie? Jeśli nie masz odpowiedzi — masz pracę do zrobienia.

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.

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 ner?” för varje kritisk väg, ä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.

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.

Czy powinienem przepisać aplikację od zera?

Zazwyczaj nie. Najpierw zrób audyt. Zidentyfikuj krytyczne luki (bezpieczeństwo, baza danych, konfiguracja). Napraw je punkt po punkcie. Przepisanie od zera ma sens tylko wtedy, kiedy architektura jest fundamentalnie błędna — ale w większości przypadków można naprawić istniejący kod iteracyjnie, bez utraty dotychczasowej pracy.

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.

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.

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.

Czy mogę wdrożyć na Vercel/Netlify i nazwać to produkcją?

Platforma nie równa się produkcji. Vercel i Netlify to świetne narzędzia do hostingu, ale sam hosting to nie jest «produkcja». Nadal potrzebujesz poprawnej konfiguracji CORS, monitoringu, obsługi błędów, bezpieczeństwa, właściwej bazy danych i testów obciążeniowych. Przycisk «Deploy» to początek, nie koniec.

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.

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.

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.

// następny kroknext stepnästa stegneste steg

Twoja aplikacja działa lokalnie, ale nie na produkcji? Your app works locally but fails in production? Din app fungerar lokalt men kraschar i produktion? Appen din fungerer lokalt men feiler i produksjon?

Pomożemy Ci zidentyfikować i naprawić każdy z tych problemów. Audyt, naprawa, wdrożenie — od prototypu do produkcji. We’ll help you identify and fix every one of these issues. Audit, fix, deploy — from prototype to production. Vi hjälper dig identifiera och fixa vart och ett av dessa problem. Granskning, fix, driftsättning — från prototyp till produktion. Vi hjelper deg identifisere og fikse hvert av disse problemene. Revisjon, fiks, distribusjon — fra prototype til produksjon.

Zarezerwuj bezpłatną rozmowę → Book a free call → Boka ett gratis samtal → Bestill en gratis samtale →
Bezpłatna rozmowa Bez zobowiązań Odpowiedź w 24h
Free consultation No obligation Reply within 24h
Gratis konsultation Utan förpliktelser Svar inom 24h
Gratis konsultasjon Helt uforpliktende Svar innen 24t