Är er app från Lovable, Bolt eller Replit redo för riktiga kunder?

Har ni byggt appen med Lovable, Bolt, Replit, v0 eller Cursor och har den redan användare, är det ärliga svaret på frågan “är vår app redo för kunder?” oftast inte än, men närmare än ni tror. Samma åtta problem dyker upp i nästan varje AI-byggd app vi granskar. De flesta går att kontrollera på en eftermiddag och väldigt få kräver att appen byggs om. Den här checklistan är för grundare och produktägare som vill veta var de står innan kunddata och intäkter börjar hänga på appen. Vill ni hellre lämna över hela granskningen gör vi det inom ramen för räddning av AI-byggda appar.

“Vibe coding” betyder att man bygger mjukvara genom att beskriva vad man vill ha för ett AI-verktyg och sedan använder koden det skriver, ofta utan att läsa den rad för rad. Det är ett snabbt sätt att nå de första användarna. Haken är att AI-genererad kod formas av det man ser i förhandsvisningen, så den hoppar gärna över det man inte ser: åtkomstregler, felhantering, backuper och vad som händer när en främling anropar ert API direkt i stället för att klicka sig fram i gränssnittet.

Vad går fel när AI-byggda appar möter riktiga användare?

Det här är inte teori. Några väldokumenterade, offentliga exempel:

• 2025 granskade säkerhetsforskare 1 645 appar i Lovables publika galleri och hittade 170 projekt, ungefär 10 procent, där databasreglerna lät vem som helst läsa användardata, och i vissa fall skriva: e-postadresser, telefonnummer, betalningsuppgifter och API-nycklar. Sårbarheten registrerades som CVE-2025-48757. Lovable bestred att det var ett fel i plattformen, vilket snarare understryker poängen: att åtkomstreglerna var rätt var varje appägares ansvar.
• Säkerhetsföretaget Escape analyserade mer än 5 600 publikt tillgängliga AI-byggda appar, de flesta byggda med Lovable, och rapporterade över 2 000 allvarliga sårbarheter, fler än 400 exponerade hemligheter och 175 fall av exponerade personuppgifter, bland annat journaluppgifter och IBAN-nummer.
• I februari 2026 rapporterade The Register om en utbildningsapp som Lovable lyft fram, där en forskare hittade 16 brister som exponerade 18 697 användarposter. En kritisk kontroll var omvänd: den stängde ute inloggade användare och släppte in anonyma besökare. Databasen saknade radnivåsäkerhet helt.
• I juli 2025 raderade Replits AI-agent ett projekts databas mitt under ett uttalat kodstopp. Replit svarade med att börja skilja utvecklings- och produktionsdatabaser åt automatiskt.

Mönstret syns också i kontrollerade tester. Veracode lät fler än 100 språkmodeller lösa 80 programmeringsuppgifter och fann att den genererade koden innehöll en känd säkerhetsbrist i 45 procent av uppgifterna. AI-verktyg skriver kod som ser rimlig ut. De skriver inte säker kod på ett tillförlitligt sätt om ingen kontrollerar den.

Är er app redo för kunder? Checklistan

Det här är de åtta områden vi kontrollerar först i varje AI-byggd app. Mittenkolumnen kan ni göra själva, och de flesta kontrollerna tar minuter, inte dagar.

Varför är radnivåsäkerhet det vanligaste hålet?

Lovable och många projekt i Bolt och v0 använder Supabase, där webbläsaren pratar direkt med databasen med en publik nyckel. Det är en fullt legitim design, men den fungerar bara om databasen själv avgör vem som får se vilka rader. Mekanismen för det heter radnivåsäkerhet (row-level security, RLS): regler i Postgres som filtrerar varje fråga utifrån vem som är inloggad. Supabases egen dokumentation är tydlig: slå på RLS för varje tabell i ett exponerat schema. Utan det kan vem som helst som har den publika nyckeln, och den finns i er JavaScript-kod, läsa och skriva i tabellen.

De varianter vi ser oftast:

• RLS är avstängt på tabeller som lagts till senare. De första tabellerna fick regler, men tabellen som AI:n skapade för en ny funktion sex veckor in fick det inte.
• Det finns en regel, men den tillåter allt. En regel som using (true) räknas som “har en regel”, så en skanner som bara kontrollerar att det finns en regel godkänner den. När Lovable införde sin inbyggda säkerhetsskanning kritiserade forskarna bakom CVE-2025-48757 den just för detta: den kontrollerade att regler fanns, inte att de var rätt.
• Skrivning lämnas öppen. Även där läsning är begränsad är det ofta fritt fram att lägga till och ändra rader. I Linkable, den första appen som hittades i granskningen bakom CVE-2025-48757, skrev en forskare in en post med payment_status satt till paid direkt i databasen och gick förbi Stripe helt.
• Service role-nyckeln hamnar i webbläsaren, oftast tillagd “för att få det att fungera” när en regel blockerade en adminfunktion. Den kringgår RLS helt.

Åtgärden är mekanisk men kräver noggrannhet: en regel per tabell och operation, adminfunktioner flyttade till serverfunktioner och ett automatiskt test som loggar in som två olika användare och visar att ingen av dem kommer åt den andras data.

Vilka problem med inloggning och behörighet är lätta att missa?

Själva inloggningen fungerar oftast, eftersom ni använder den varje dag. Det är specialfallen som går sönder:

• Behörighet som bara styrs i gränssnittet. Att dölja knappen “Radera” för den som inte är admin hjälper inte om API:et bakom tar emot anropet från vem som helst.
• Omvända eller ofullständiga kontroller, som i utbildningsappen ovan: kod som ser rätt ut, klarar en snabb genomklickning och gör motsatsen till det den ska.
• Flöden som sällan används: länkar för lösenordsåterställning som aldrig går ut, byte av e-post utan ny verifiering, inbjudningslänkar som kan återanvändas och OAuth-inställningar som fortfarande tillåter localhost.
• Sessioner som överlever en ändrad roll eller ett raderat konto.
• Ingen begränsning av antalet försök vid registrering, inloggning eller lösenordsåterställning. Det bjuder in till automatiserade inloggningsattacker och, om registreringen skickar e-post eller gör ett AI-anrop, till en oväntad faktura.

Den generella lösningen är att servern är den enda platsen där behörighet avgörs, och att det finns ett automatiskt test per roll som försöker göra något rollen inte ska få göra.

Vad kräver GDPR och nordiska kunder?

GDPR gäller så fort ni lagrar personuppgifter, oavsett hur stora ni är. Om en tabell med namn och e-postadresser kan läsas av vem som helst är det en personuppgiftsincident, och om den sannolikt innebär en risk för de registrerade ska den normalt anmälas till tillsynsmyndigheten inom 72 timmar. I Sverige är det IMY.

Nordiska B2B-kunder kommer dessutom att fråga i upphandlingen: var lagras data, vem har åtkomst, vilka underbiträden får del av den och finns det personuppgiftsbiträdesavtal? Luckorna vi oftast hittar i AI-byggda appar:

• en databasregion som ingen har valt medvetet;
• analys- eller inspelningsverktyg som sparar formulärfält med personuppgifter;
• kunddata som skickas till ett AI-API utan något avtal som täcker det;
• inget sätt att lämna ut eller radera en enskild användares uppgifter på begäran;
• loggar fulla av e-postadresser och åtkomsttoken.

Inget av detta är svårt att rätta till, men det måste dokumenteras, eftersom era kunders dataskyddsombud kommer att vilja se det.

Måste en AI-byggd app byggas om?

Oftast inte. De flesta appar kan stabiliseras steg för steg medan de är i drift, och en total omskrivning kastar bort det enda appen redan har bevisat: att folk vill ha den. Vi rekommenderar bara att bygga om en del när det blir billigare under det kommande året än att rätta den.

Tecken på att en del kan vara värd att bygga om:

• Datamodellen är fel i grunden, till exempel en B2B-app utan begrepp för organisation eller kund, så att varje fråga måste gissa vems data det är. Vi går igenom isolering mellan kunder och de andra grunderna i SaaS-arkitektur från MVP till skala.
• Samma affärslogik är kopierad till dussintals komponenter, så att varje rättning måste göras tio gånger.
• Koden går inte att bygga eller köra utanför verktyget som genererade den.

Avvägningen mellan att refaktorera och bygga om är densamma som vi beskriver för äldre system i när det är dags att modernisera äldre mjukvara. När vi flyttar delar av en app flyttar vi dem oftast till den TypeScript-stack vi bygger på, som ligger nära det AI-verktygen genererar, så att ert team kan fortsätta använda dem.

I vilken ordning ska ni åtgärda?

Om checklistan visar problem begränsar den här ordningen skadan snabbast:

1. I dag: byt alla exponerade nycklar och slå på RLS för tabeller som saknar det. En öppen tabell är det enda problemet som kan skada er redan den här veckan.
2. Den här veckan: kontrollera att backuperna fungerar genom att läsa tillbaka en till ett separat projekt, och skilj utveckling från produktion.
3. Därefter: flytta behörighetskontroller till servern och täpp till luckorna i inloggningen.
4. Sedan: lägg koden i ett kodförråd som ert bolag äger, med CI/CD och möjlighet att backa.
5. Sedan: tester för de flöden som drar in pengar, så att nästa AI-genererade ändring inte kan förstöra dem i det tysta.
6. Parallellt: GDPR-dokumentationen (kartläggning, avtal med leverantörer, raderingsflöde) och kostnadstak.

När steg 1–5 är på plats blir AI-verktygen betydligt säkrare att fortsätta använda, eftersom en ändring som förstör inloggningen eller öppnar en tabell stoppas i pipelinen i stället för att nå kunderna.

Vad ni kan göra nu

Börja med checklistan ovan; en eftermiddag med den säger mer än någon automatisk skanner. Vill ni hellre att en senior utvecklare gör det börjar vår räddning av AI-byggda appar med en kod- och säkerhetsgenomlysning till fast pris, 1 900 € (ca 21 000 kr) på 3–5 arbetsdagar. Ni får en skriftlig rapport med prioriterade åtgärder och ett fast pris för att genomföra dem, och avgiften räknas av om ni går vidare. Stabiliseringen kostar från 6 000 € (ca 66 000 kr) och tar oftast 2–4 veckor. Därefter kan ni låta oss förvalta appen med Care Lite, vårt förvaltningsavtal till fast månadspris (från 46 000 kr/mån), fortsätta utveckla den med en Start Pod, ett litet team lett av en senior utvecklare till fast månadspris, eller ta över allt själva. Ni tecknar avtal med Smoother Development AB i Sverige, våra utvecklare arbetar från Ukraina och en av grundarna ansvarar för arbetet.