Fungerar inte din Lovable-app i produktion? Så gör du den produktionsklar

Varför fungerar min Lovable-app i förhandsvisningen men går sönder i produktion?

I förhandsvisningen är du en användare, med testdata, som klickar på de flöden du byggt. Produktion lägger till främlingar, riktiga pengar och tid. Felen som följer är sällan en dålig kodrad. De är beslut som saknas: vem som får läsa vilken rad, vad som händer när en betalning går igenom men webbläsaren stängs, och vem som märker när ett mejl slutar skickas.

• Data läcker mellan användare. Supabase gör en tabell i ett exponerat schema läsbar och skrivbar för varje roll med behörighet till den, om inte radnivåsäkerhet är påslagen och dess policyer är korrekta.
• Hemligheter i webbläsaren. Den publicerbara nyckeln (anon) är säker att skicka med; service role-nyckeln kringgår varje RLS-policy och får aldrig nå webbläsaren.
• Betalningar som glider isär. En kassa som går tillbaka till en bekräftelsesida är inget bevis på betalning. Servern måste bekräfta den med Stripe.
• Ändringar som förstör gamla funktioner. Utan regressionstester kan varje ny prompt göra om något som fungerade förra veckan.
• Tysta avbrott. Utan övervakning hittar dina kunder buggen före dig.

Inget av detta är unikt för Lovable. Varje snabb första version, skriven av en människa eller av AI, tenderar att ha samma luckor, eftersom en prototyps uppgift är att bevisa idén, inte att överleva främlingar.

Är en Lovable-app produktionsklar direkt från start?

Delvis. Lovables egen dokumentation säger att den skriver policyer för radnivåsäkerhet för tabeller när du kopplar Supabase, kör en snabb säkerhetsskanning när du publicerar (en databasgenomgång, som tabeller utan RLS eller regler som släpper igenom alla, en granskning av beroenden och en kontroll av MCP-servrar) och erbjuder en djupare skanning som du startar för hand. Den säger också, rakt ut, att skanningen inte kan garantera fullständig säkerhet och inte ersätter en grundlig säkerhetsgranskning.

Det är en rättvis beskrivning. En skanning kan säga att en policy finns. Den kan inte säga att policyn stämmer med dina affärsregler, till exempel att en teamadministratör får se fakturor men en teammedlem inte får det. Det omdömet är vad produktionsklar betyder i praktiken.

Vad betyder produktionsklar för en Lovable-app?

Hur lägger jag till Stripe-betalningar i en Lovable-app på ett säkert sätt?

Lovables Stripe-integration körs via edge functions, så din hemliga nyckel hålls utanför appen, och engångsbetalningar öppnar Stripe Checkout. Enligt Lovables dokumentation sätter den inte upp webhooks som standard: appen kontrollerar betalnings- och abonnemangsstatus direkt med Stripe, och webhooks kan läggas till på begäran. Den noterar också att pris-id:n skiljer sig mellan testläge och liveläge, så att gå live kräver nya.

Att kontrollera status vid behov fungerar för en enkel kassa. När du säljer abonnemang vill du oftast ha webhooks också, eftersom förnyelser, nekade kort och uppsägningar sker när din användare inte är på sidan. Stripes dokumentation är tydlig med hur man gör det säkert:

• Verifiera varje webhook med Stripe-Signature-headern och din endpoint-hemlighet, mot den råa request-kroppen.
• Räkna med dubbletter och händelser i fel ordning. Spara de händelse-id:n du har behandlat så att varje händelse hanteras en gång (idempotens).
• Kom ihåg att Stripe försöker igen med misslyckade leveranser i liveläge i upp till tre dagar, så en trasig endpoint kan spela upp flera dagars händelser när den kommer tillbaka.
• Håll test- och livehemligheter isär. Objekt i det ena läget syns inte i det andra.

Ska jag fixa det själv, anlita en frilansare eller ta in ett team?

Om din app har en handfull användare, inga betalningar och ingen känslig data kan du själv gå igenom tabellen ovan med Lovables säkerhetsskanning och Supabases Security Advisor, som flaggar tabeller där RLS är avslaget och policyer som släpper igenom alla. Det är en bra användning av en eftermiddag.

En frilansare eller en räddningssprint till fast pris passar ett känt, avgränsat problem: en trasig integration, en granskning. De är ofta det billigare valet för det. Det en engångsfix inte ger dig är de kommande sex månaderna: testerna, releaserna, uppgraderingarna och incidenten utanför kontorstid. Det fortlöpande ägandet är vad vi säljer: Plutonapps är specialiserat på att ta Lovable-appar till produktion och drifta dem, och vår jämförelse av byråer, frilansare, egna anställda och abonnemang visar när vart och ett passar.

Vad händer efter lansering, och vem har beredskap?

Lanseringen är där arbetet förändras, inte där det slutar. Någon måste bevaka fel, installera säkerhetsuppdateringar, hantera incidenter och leverera nästa funktion utan att förstöra den förra. På vår Starter-plan fortsätter grundarna att prompta i Lovable, och våra utvecklare bygger in varje version i den riktiga produkten, kör regressionstester och visuella regressionstester, kodgranskning och säkerhetskontroller på varje ändring, driftsätter i produktion två gånger i veckan och hanterar upp till fem akuta händelser i produktion i månaden, med support under kontorstid. Growth lägger till kontinuerlig driftsättning och support dygnet runt. Detaljer och priser finns på vår prissida.