Spring til indholdet

Er din AI-byggede app klar til rigtige brugere?

Plutonapps' produktionsklar-tjek giver en app bygget med Lovable eller en anden AI-appbygger en score ud af 100 på omkring tre minutter. Svar på 19 spørgsmål om sikkerhed, data, lanceringer, overvågning, betalinger, privatliv og ejerskab, og se de tre risici, du skal rette først. Det er gratis, og dine svar bliver på denne side, medmindre du beder om den fulde rapport på e-mail.

Spørgsmålene

Sikkerhed og adgang

Hvem der kan logge ind, og hvad databasen lader hver af dem læse.

1.Hvordan logger folk ind i din app?

Login er autentificering: at bevise, hvem nogen er.

2.Er multifaktorgodkendelse slået til for alle konti, der kan ændre produktion – Supabase, hosting, GitHub, Stripe, dit domæne?

Én phishet adgangskode på en af dem er en vej ind til det hele.

3.Er row-level security slået til for alle tabeller med brugerdata, med politikker, du har testet som en anden bruger?

RLS er det, der forhindrer én indlogget bruger i at læse en andens rækker gennem dit offentlige API.

4.Hvor ligger din Supabase service role-nøgle (den hemmelige nøgle)?

Service role-nøglen springer row-level security helt over.

5.Hvor opbevares dine andre hemmeligheder – Stripes hemmelige nøgle, API-nøgler til e-mail og AI?

En hemmelighed i et Git-repository bliver i historikken, selv efter du har slettet den.

Datasikkerhed

Om dine data overlever en dårlig udrulning, en dårlig prompt eller en dårlig dag.

6.Hvis en dårlig ændring slettede en tabel klokken 15, hvad kunne du så gendanne?

Daglige backups mister alt siden den seneste; point-in-time recovery gør ikke.

7.Har du gendannet en backup i et separat projekt for at bevise, at den virker?

En backup, som ingen har gendannet, er et håb, ikke en plan.

8.Hvordan når databaseændringer frem til produktion?

En migrering er en versioneret SQL-fil, der køres på samme måde overalt.

Lanceringer og test

Hvordan en ændring bliver tjekket, før dine brugere ser den.

9.Findes der et staging-miljø med sin egen database, hvor ændringer tjekkes først?

Staging er en privat kopi af produktion, hvor hver lancering afprøves, før den går live.

10.Dækker automatiske tests dine kerneflows – oprettelse, betaling og det vigtigste, din app gør?

Regressionstests fanger, når den funktion, du ikke rørte, går i stykker på grund af en, du rørte.

11.Hvordan kommer kode i produktion?

CI/CD kører de samme tjek på hver ændring og udruller kun det, der består.

Drift

At vide, at noget er gået i stykker, før dine brugere fortæller dig det – og hvad der så sker.

12.Hvis appen gik i stykker for brugerne lige nu, hvordan ville du så finde ud af det?

Observability er at vide, hvad det kørende system laver, ud fra dets logs, målinger og fejl.

13.Er oprettelse, login og alt, der sender e-mail eller kalder et betalt API (for eksempel en AI-model), begrænset med rate limiting?

Uden en grænse kan ét script få din regning til at løbe løbsk eller låse dine brugere ude.

14.Hvis produktion gik ned i nat, er der så en navngiven person og en skriftlig plan?

Hændelseshåndtering er at beslutte, før det sker, hvem der handler og hvordan.

Betalinger

At tage imod penge uden at opbevare kortdata eller stole på browseren.

15.Hvordan tager din app imod betalinger?

Hvem der opbevarer kortoplysningerne, afgør, hvor meget compliance-arbejde der lander hos dig.

16.Bliver indkommende webhooks tjekket via signatur, og er det sikkert at modtage dem to gange?

Udbydere sender webhooks igen, så den samme hændelse kan komme mere end én gang.

Privatliv og compliance

Det grundlæggende i GDPR og et spor af, hvem der ændrede hvad.

17.Har du det grundlæggende i GDPR på plads: en privatlivspolitik, der nævner dine udbydere, en databehandleraftale med hver af dem og en måde at slette en brugers data på efter anmodning?

Hvis du har brugere i EU eller Storbritannien, er det lovkrav, ikke ekstrating.

18.Kan du se, hvem der ændrede hvad i dit administrationsområde, og hvornår?

En revisionslog er et register over væsentlige handlinger, som der kun kan tilføjes til.

Ejerskab

Om appen er din at flytte, overdrage og holde kørende.

19.Ligger koden i et Git-repository, du ejer, og kunne et andet team udrulle den uden den person, der byggede den?

Hvis kun ét værktøj eller én person kan udgive den, er du låst fast.

0 af 19 besvaret

Sådan beregnes scoren

Hvert spørgsmål har en fast vægt, og vægtene giver tilsammen 100. Dit svar giver hele, en del af eller intet af vægten; »Ved ikke« giver intet. Et spørgsmål, der ikke gælder for din app, udelades, og resten skaleres tilbage til 100. Enhver kritisk mangel begrænser scoren til 49. Reglerne er de samme i din browser og på vores server, og der er ingen AI involveret.

Hvert områdes vægt, ud af 100
OmrådeSpørgsmålVægt
Sikkerhed og adgang525
Datasikkerhed320
Lanceringer og test315
Drift315
Betalinger210
Privatliv og compliance210
Ejerskab15

Niveauer: 90 og derover er produktionsklar, 75 til 89 næsten der, 50 til 74 kræver arbejde, under 50 ikke klar. Hvad hvert begreb betyder, står i vores ordliste.

Spørgsmål om tjekket

Hvad måler produktionsklar-tjekket?

19 spørgsmål inden for syv områder, der afgør, om en app er sikker for rigtige brugere: sikkerhed og adgang, datasikkerhed, lanceringer og test, drift, betalinger, privatliv og compliance samt ejerskab. Hvert svar vurderes mod en fast vægt, og områderne giver tilsammen 100.

Hvordan beregnes scoren?

Hvert spørgsmål har en vægt, og vægtene giver tilsammen 100. Dit svar giver hele, en del af eller intet af den vægt. »Ved ikke« giver intet, for hvis du ikke kan sige, at det er gjort, er den sikre antagelse, at det ikke er. Et spørgsmål, der ikke gælder for din app – for eksempel betalinger, hvis du ikke tager imod nogen – udelades, og resten skaleres tilbage til 100. En kritisk mangel, for eksempel en service role-nøgle i browseren, begrænser scoren til 49. De samme regler kører på vores server, uden AI.

Hvilken score tæller som produktionsklar?

90 eller derover er produktionsklar, 75 til 89 er næsten der, 50 til 74 kræver arbejde før lancering, og under 50 er ikke klar til rigtige brugere. En enkelt kritisk mangel holder en app under 50, uanset hvad der ellers er på plads.

Gemmer I mine svar?

Ikke medmindre du beder om rapporten på e-mail. Scoren beregnes i din browser. Hvis du beder om rapporten, gemmer vi din e-mail, det navn og den app-adresse, du angiver, dine svar, din score, om du har sat kryds for opdateringer, kampagnetags i linket og den side, der sendte dig hertil (ingen af delene, hvis din browser sender Do Not Track eller Global Privacy Control), samt en envejs-hash af din IP-adresse, i 24 måneder. Vi sender rapporten én gang og giver vores team besked. Vi sender dig kun andet, hvis du sætter kryds. Vi besøger eller scanner aldrig din apps adresse.

Er det kun til apps bygget med Lovable?

Nej. Det virker for enhver app bygget med en AI-appbygger som Lovable, Bolt, v0 eller Replit, eller bygget i hånden. Nogle spørgsmål nævner Supabase, fordi de fleste AI-byggede apps kører på det, men de samme tjek gælder for enhver app med en database, login og betalinger.

Hvad skal jeg rette først?

Start med de tre risici, tjekket viser dig. Kritiske mangler kommer først, derefter de svar, der mistede flest point. Hver af dem linker til en letforståelig definition i vores ordliste (på engelsk). Vil du hellere have udviklere til at rette dem, er det præcis, hvad en Plutonapps-plan gør.

Vil du hellere have udviklere til at rette det for dig?

Du bliver ved med at designe i Lovable. Plutonapps' udviklere gør det rigtige produkt sikkert, testet og klar til produktion – som et abonnement.

Se planerne