Virker din Lovable-app ikke i produktion? Sådan gør du den produktionsklar

Hvorfor virker min Lovable-app i preview, men går i stykker i produktion?

I preview er du én bruger med testdata, der klikker rundt på de veje, du selv har bygget. Produktion tilføjer fremmede, rigtige penge og tid. De fejl, der følger, skyldes sjældent en dårlig kodelinje. Det er manglende beslutninger: hvem må læse hvilken række, hvad sker der, når en betaling lykkes, men browseren lukkes, og hvem opdager det, når en e-mail holder op med at blive sendt.

• Data, der lækker mellem brugere. Supabase gør en tabel i et eksponeret skema læsbar og skrivbar for enhver rolle med en grant på den, medmindre row-level security er slået til, og politikkerne er korrekte.
• Hemmeligheder i browseren. Den publicerbare (anon) nøgle er sikker at sende med; service role-nøglen omgår alle RLS-politikker og må aldrig nå browseren.
• Betalinger, der kommer ud af trit. En checkout, der vender tilbage til en bekræftelsesside, er ikke bevis for betaling. Serveren skal bekræfte den hos Stripe.
• Ændringer, der ødelægger gamle funktioner. Uden regressionstests kan hver ny prompt ødelægge noget, der virkede i sidste uge.
• Stille nedbrud. Uden overvågning finder dine kunder fejlen før dig.

Intet af dette er særligt for Lovable. Enhver hurtig første version, skrevet af et menneske eller af AI, har som regel de samme huller, fordi en prototypes opgave er at bevise idéen, ikke at overleve fremmede.

Er en Lovable-app produktionsklar fra start?

Delvist. Lovables egen dokumentation siger, at den skriver row-level security-politikker for tabeller, når du forbinder Supabase, kører en hurtig sikkerhedsscanning, når du udgiver (en databasegennemgang, for eksempel tabeller uden RLS eller regler, der lukker alle ind, en gennemgang af afhængigheder og et tjek af MCP-servere), og tilbyder en grundigere scanning, som du starter manuelt. Den siger også ligeud, at scanningen ikke kan garantere fuld sikkerhed og ikke erstatter en grundig sikkerhedsgennemgang.

Det er en rimelig beskrivelse. En scanning kan fortælle dig, at en politik findes. Den kan ikke fortælle dig, om politikken passer til dine forretningsregler, for eksempel at en teamadministrator kan se fakturaer, men et teammedlem ikke kan. Den vurdering er, hvad produktionsklar betyder i praksis.

Hvad betyder produktionsklar for en Lovable-app?

Hvordan tilføjer jeg Stripe-betalinger sikkert til en Lovable-app?

Lovables Stripe-integration kører gennem edge functions, så din hemmelige nøgle holdes ude af appen, og engangsbetalinger åbner Stripe Checkout. Ifølge Lovables dokumentation sætter den ikke webhooks op som standard: appen tjekker betalings- og abonnementsstatus direkte hos Stripe, og webhooks kan tilføjes efter anmodning. Den bemærker også, at pris-id'er er forskellige i testtilstand og live-tilstand, så det kræver nye, når du går live.

At tjekke status efter behov fungerer til en simpel checkout. Når du sælger abonnementer, vil du som regel også have webhooks, fordi fornyelser, afviste kort og opsigelser sker, når din bruger ikke er på siden. Stripes dokumentation er præcis om, hvordan det gøres sikkert:

• Verificér hver webhook med Stripe-Signature-headeren og din endpoint-hemmelighed mod den rå request-body.
• Forvent dubletter og hændelser i forkert rækkefølge. Registrér de hændelses-id'er, du har behandlet, så hver af dem håndteres én gang (idempotens).
• Husk, at Stripe forsøger mislykkede leveringer i live-tilstand igen i op til tre dage, så et endpoint, der er nede, kan få flere dages hændelser afspillet igen, når det kommer op.
• Hold test- og live-hemmeligheder adskilt. Objekter i den ene tilstand er ikke synlige i den anden.

Skal jeg rette det selv, bruge en freelancer eller hente et team ind?

Hvis din app har en håndfuld brugere, ingen betalinger og ingen følsomme data, kan du selv arbejde dig gennem tabellen ovenfor med Lovables sikkerhedsscanning og Supabases Security Advisor, som markerer tabeller med RLS slået fra og politikker, der lukker alle ind. Det er en god måde at bruge en eftermiddag på.

En freelancer eller en redningssprint til fast pris passer til et kendt, afgrænset problem: én integration, der ikke virker, én gennemgang. De er ofte det billigste valg til det. Hvad en engangsrettelse ikke giver dig, er de næste seks måneder: testene, lanceringerne, opgraderingerne og hændelsen uden for arbejdstid. Det løbende ejerskab er det, vi sælger: Plutonapps er specialiseret i at tage Lovable-apps i produktion og drive dem, og vores sammenligning af bureauer, freelancere, egne ansatte og abonnementer viser, hvornår hver af dem passer.

Hvad sker der efter lanceringen, og hvem er på vagt?

Lanceringen er dér, hvor arbejdet ændrer sig, ikke dér, hvor det stopper. Nogen skal holde øje med fejl, installere sikkerhedsopdateringer, håndtere hændelser og levere den næste funktion uden at ødelægge den forrige. På vores Starter-plan bliver iværksættere ved med at prompte i Lovable, og vores udviklere bygger hver version ind i det rigtige produkt, kører regressionstest og visuel regressionstest, kodegennemgang og sikkerhedstjek ved hver ændring, udruller til produktion to gange om ugen og håndterer op til fem akutte produktionshændelser om måneden, med support i arbejdstiden. Growth lægger løbende udrulning og support døgnet rundt oveni. Detaljer og priser står på vores prisside.