Lovable-appen virker ikke i produksjon? Slik gjør du den klar

Hvorfor virker Lovable-appen min i forhåndsvisning, men ikke i produksjon?

I forhåndsvisningen er du én bruker, med testdata, som klikker gjennom stiene du har bygget. Produksjon legger til fremmede, ekte penger og tid. Feilene som følger, er sjelden en dårlig kodelinje. De er manglende beslutninger: hvem som får lese hvilken rad, hva som skjer når en betaling går gjennom, men nettleseren lukkes, og hvem som merker det når en e-post slutter å bli sendt.

• Data lekker mellom brukere. Supabase gjør en tabell i et eksponert skjema lesbar og skrivbar for enhver rolle med tilgang til den, med mindre radnivåsikkerhet er slått på og reglene er riktige.
• Hemmeligheter i nettleseren. Den publiserbare (anon) nøkkelen er trygg å levere ut; service role-nøkkelen omgår alle RLS-regler og må aldri nå nettleseren.
• Betalinger som kommer ut av synk. En betaling som sender brukeren tilbake til en suksesside, er ikke bevis på betaling. Serveren må bekrefte den med Stripe.
• Endringer som ødelegger gamle funksjoner. Uten regresjonstester kan hver nye prompt ødelegge noe som virket forrige uke.
• Stille nedetid. Uten overvåking finner kundene feilen før deg.

Ingenting av dette er særegent for Lovable. Enhver rask første versjon, skrevet av et menneske eller av KI, har gjerne de samme hullene, fordi jobben til en prototype er å bevise ideen, ikke å overleve fremmede.

Er en Lovable-app klar for produksjon fra start?

Delvis. Lovables egen dokumentasjon sier at det skriver regler for radnivåsikkerhet for tabeller når du kobler til Supabase, kjører en rask sikkerhetsskanning når du publiserer (en gjennomgang av databasen, som tabeller uten RLS eller regler som slipper alle gjennom, en revisjon av avhengigheter og en sjekk av MCP-servere), og tilbyr en grundigere skanning du starter manuelt. Den sier også rett ut at skanningen ikke kan garantere full sikkerhet og ikke erstatter en grundig sikkerhetsgjennomgang.

Det er en rettferdig beskrivelse. En skanning kan fortelle deg at en regel finnes. Den kan ikke fortelle deg om regelen stemmer med forretningsreglene dine, for eksempel at en teamadministrator kan se fakturaer, men et teammedlem ikke kan. Den vurderingen er det klar for produksjon betyr i praksis.

Hva betyr klar for produksjon for en Lovable-app?

Hvordan legger jeg trygt til Stripe-betalinger i en Lovable-app?

Lovables Stripe-integrasjon går gjennom edge-funksjoner, så den hemmelige nøkkelen din holdes utenfor appen, og engangsbetalinger åpner Stripe Checkout. Ifølge Lovables dokumentasjon setter den ikke opp webhooks som standard: appen sjekker betalings- og abonnementsstatus direkte hos Stripe, og webhooks kan legges til på forespørsel. Den påpeker også at pris-ID-er er forskjellige i testmodus og live-modus, så overgangen til live krever nye.

Å sjekke status ved behov fungerer for en enkel betaling. Når du selger abonnementer, vil du som regel også ha webhooks, fordi fornyelser, avviste kort og oppsigelser skjer når brukeren ikke er på siden. Stripes dokumentasjon er konkret om hvordan du gjør det trygt:

• Verifiser hver webhook med Stripe-Signature-headeren og endepunktnøkkelen din, mot den rå forespørselskroppen.
• Regn med duplikater og hendelser i feil rekkefølge. Lagre ID-ene til hendelsene du har behandlet, slik at hver bare håndteres én gang (idempotens).
• Husk at Stripe prøver mislykkede leveringer i live-modus på nytt i opptil tre dager, så et ødelagt endepunkt kan spille av flere dager med hendelser når det kommer seg.
• Hold test- og live-nøkler adskilt. Objekter i den ene modusen er ikke synlige i den andre.

Bør jeg fikse det selv, leie inn en frilanser eller hente inn et team?

Hvis appen din har en håndfull brukere, ingen betalinger og ingen sensitive data, kan du gå gjennom tabellen over selv med Lovables sikkerhetsskanning og Supabases Security Advisor, som flagger tabeller med RLS slått av og regler som slipper alle gjennom. Det er en god måte å bruke en ettermiddag på.

En frilanser eller en redningssprint til fast pris passer et kjent, avgrenset problem: én ødelagt integrasjon, én revisjon. De er ofte det billigste valget for det. Det en engangsfiks ikke gir deg, er de neste seks månedene: testene, lanseringene, oppgraderingene og hendelsen utenom arbeidstid. Det løpende eierskapet er det vi selger: Plutonapps spesialiserer seg på å ta Lovable-apper i produksjon og drifte dem, og sammenligningen vår av byråer, frilansere, egne ansatte og abonnementer viser når hver av dem passer.

Hva skjer etter lansering, og hvem har beredskap?

Lansering er der arbeidet endrer seg, ikke der det stopper. Noen må følge med på feil, legge inn sikkerhetsoppdateringer, håndtere hendelser og lansere neste funksjon uten å ødelegge den forrige. På Starter-planen vår fortsetter gründerne å skrive prompter i Lovable, og utviklerne våre bygger hver versjon inn i det ekte produktet, kjører regresjonstester og visuelle regresjonstester, kodegjennomgang og sikkerhetssjekker på hver endring, ruller ut til produksjon to ganger i uken og håndterer opptil fem nødhendelser i produksjon i måneden, med support i arbeidstiden. Growth legger til kontinuerlig utrulling og support døgnet rundt. Detaljer og priser står på prissiden vår.