Przejdź do treści

Czy Państwa aplikacja zbudowana z AI jest gotowa na prawdziwych użytkowników?

Test gotowości produkcyjnej Plutonapps ocenia w skali do 100 aplikację zbudowaną w Lovable lub innym kreatorze AI – w około trzy minuty. Wystarczy odpowiedzieć na 19 pytań o bezpieczeństwo, dane, wydania, monitoring, płatności, prywatność i własność, aby zobaczyć trzy ryzyka do usunięcia w pierwszej kolejności. Test jest bezpłatny, a odpowiedzi pozostają na tej stronie, chyba że poproszą Państwo o pełny raport e-mailem.

Pytania

Bezpieczeństwo i dostęp

Kto może się zalogować i co baza danych pozwala każdemu odczytać.

1.Jak użytkownicy logują się do Państwa aplikacji?

Logowanie to uwierzytelnianie: potwierdzenie, kim ktoś jest.

2.Czy uwierzytelnianie wieloskładnikowe jest włączone na każdym koncie, które może zmienić produkcję – Supabase, hosting, GitHub, Stripe, domena?

Jedno wyłudzone hasło do któregokolwiek z nich otwiera drogę do wszystkiego.

3.Czy zabezpieczenia na poziomie wierszy są włączone dla każdej tabeli z danymi użytkowników, z politykami przetestowanymi z konta drugiego użytkownika?

RLS powstrzymuje zalogowanego użytkownika przed odczytaniem cudzych wierszy przez publiczne API.

4.Gdzie znajduje się klucz service-role (tajny) Supabase?

Klucz service-role całkowicie pomija zabezpieczenia na poziomie wierszy.

5.Gdzie przechowywane są pozostałe sekrety – tajny klucz Stripe, klucze API do e-maili i AI?

Sekret w repozytorium Git zostaje w jego historii nawet po usunięciu.

Bezpieczeństwo danych

Czy dane przetrwają złe wdrożenie, zły prompt albo zły dzień.

6.Gdyby zła zmiana wyczyściła tabelę o 15:00, co dałoby się przywrócić?

Codzienne kopie tracą wszystko od ostatniej kopii; odtwarzanie do punktu w czasie – nie.

7.Czy przywrócili Państwo kopię zapasową w osobnym projekcie, aby sprawdzić, że działa?

Kopia, której nikt nie przywrócił, to nadzieja, a nie plan.

8.Jak zmiany w bazie danych trafiają na produkcję?

Migracja to wersjonowany plik SQL, stosowany wszędzie w ten sam sposób.

Wydania i testy

Jak zmiana jest sprawdzana, zanim zobaczą ją użytkownicy.

9.Czy istnieje środowisko testowe (staging) z własną bazą danych, w którym zmiany są najpierw sprawdzane?

Staging to prywatna kopia produkcji, na której każde wydanie jest sprawdzane przed uruchomieniem.

10.Czy testy automatyczne obejmują kluczowe ścieżki – rejestrację, płatność i główną funkcję aplikacji?

Testy regresji wyłapują funkcję, której Państwo nie ruszali, a która zepsuła się przez tę, którą zmieniono.

11.Jak kod trafia na produkcję?

CI/CD uruchamia te same kontrole przy każdej zmianie i wdraża tylko to, co je przejdzie.

Działanie produkcyjne

Wiedzieć o awarii, zanim powiedzą o niej użytkownicy, i co dzieje się dalej.

12.Gdyby aplikacja właśnie przestała działać, skąd by się Państwo o tym dowiedzieli?

Obserwowalność to wiedza o tym, co robi działający system – z logów, metryk i błędów.

13.Czy rejestracja, logowanie i wszystko, co wysyła e-maile lub wywołuje płatne API (np. model AI), ma limity zapytań?

Bez limitu jeden skrypt może podbić rachunek lub zablokować użytkowników.

14.Gdyby produkcja padła dziś w nocy, czy jest wskazana osoba i spisany plan?

Reagowanie na incydenty to ustalenie z góry, kto działa i jak.

Płatności

Przyjmowanie pieniędzy bez przechowywania danych kart i bez ufania przeglądarce.

15.Jak Państwa aplikacja przyjmuje płatności?

To, kto przechowuje dane kart, decyduje, ile pracy związanej ze zgodnością spada na Państwa.

16.Czy przychodzące webhooki są weryfikowane podpisem i bezpieczne przy dwukrotnym odbiorze?

Dostawcy ponawiają webhooki, więc to samo zdarzenie może przyjść więcej niż raz.

Prywatność i zgodność

Podstawy RODO i zapis tego, kto co zmienił.

17.Czy mają Państwo podstawy RODO: politykę prywatności wymieniającą dostawców, umowę powierzenia przetwarzania danych z każdym z nich i sposób usunięcia danych użytkownika na żądanie?

Jeśli mają Państwo użytkowników w UE lub Wielkiej Brytanii, to obowiązki prawne, a nie dodatki.

18.Czy wiedzą Państwo, kto i kiedy co zmienił w panelu administracyjnym?

Dziennik audytu to zapis istotnych działań, do którego można tylko dopisywać.

Własność

Czy aplikację można przenieść, przekazać i utrzymać w działaniu.

19.Czy kod jest w repozytorium Git należącym do Państwa i czy inny zespół mógłby go wdrożyć bez osoby, która go zbudowała?

Jeśli tylko jedno narzędzie lub jedna osoba może to wdrożyć, są Państwo uzależnieni.

0 z 19 z odpowiedzią

Jak liczony jest wynik

Każde pytanie ma stałą wagę, a wagi sumują się do 100. Odpowiedź zdobywa całość, część albo nic z tej wagi; „Nie wiem” nie zdobywa nic. Pytanie, które nie dotyczy Państwa aplikacji, jest pomijane, a pozostałe są przeskalowane do 100. Każda krytyczna luka ogranicza wynik do 49. Zasady są takie same w przeglądarce i na naszym serwerze, a w procesie nie uczestniczy AI.

Waga każdego obszaru, na 100
ObszarPytaniaWaga
Bezpieczeństwo i dostęp525
Bezpieczeństwo danych320
Wydania i testy315
Działanie produkcyjne315
Płatności210
Prywatność i zgodność210
Własność15

Przedziały: 90 i więcej – gotowa na produkcję, 75–89 – prawie gotowa, 50–74 – wymaga pracy, poniżej 50 – niegotowa. Znaczenie każdego terminu wyjaśnia nasz słownik.

Pytania o test

Co mierzy test gotowości produkcyjnej?

19 pytań w siedmiu obszarach, które decydują, czy aplikacja jest bezpieczna dla prawdziwych użytkowników: bezpieczeństwo i dostęp, bezpieczeństwo danych, wydania i testy, działanie produkcyjne, płatności, prywatność i zgodność oraz własność. Każda odpowiedź jest oceniana według stałej wagi, a obszary sumują się do 100.

Jak obliczany jest wynik?

Każde pytanie ma wagę, a wagi sumują się do 100. Odpowiedź zdobywa całość, część albo nic z tej wagi. „Nie wiem” nie zdobywa nic, bo jeśli nie można powiedzieć, że coś jest zrobione, bezpieczniej założyć, że nie jest. Pytanie, które nie dotyczy aplikacji – na przykład płatności, gdy ich Państwo nie przyjmują – jest pomijane, a pozostałe są przeskalowane do 100. Krytyczna luka, taka jak klucz service-role w przeglądarce, ogranicza wynik do 49. Te same zasady działają na naszym serwerze, bez udziału AI.

Jaki wynik oznacza gotowość na produkcję?

90 lub więcej to gotowość na produkcję, 75–89 – prawie gotowa, 50–74 – wymaga pracy przed startem, a poniżej 50 – niegotowa na prawdziwych użytkowników. Każda pojedyncza krytyczna luka utrzymuje aplikację poniżej 50, bez względu na resztę.

Czy przechowujecie moje odpowiedzi?

Nie, chyba że poproszą Państwo o raport e-mailem. Wynik jest obliczany w przeglądarce. Jeśli poproszą Państwo o raport, przechowujemy przez 24 miesiące: adres e-mail, podane imię i adres aplikacji, odpowiedzi, wynik, informację, czy zaznaczono zgodę na aktualizacje, tagi kampanii z linku i stronę, z której Państwo przyszli (żadnego z tych dwóch, jeśli przeglądarka wysyła Do Not Track lub Global Privacy Control), oraz jednokierunkowy skrót adresu IP. Raport wysyłamy raz i informujemy nasz zespół. Cokolwiek innego wysyłamy tylko po zaznaczeniu zgody. Nigdy nie odwiedzamy ani nie skanujemy adresu Państwa aplikacji.

Czy test jest tylko dla aplikacji zbudowanych w Lovable?

Nie. Działa dla każdej aplikacji zbudowanej w kreatorze AI, takim jak Lovable, Bolt, v0 czy Replit, lub napisanej ręcznie. Niektóre pytania wymieniają Supabase, bo działa na nim większość aplikacji zbudowanych z AI, ale te same kontrole dotyczą każdej aplikacji z bazą danych, logowaniem i płatnościami.

Co naprawić najpierw?

Prosimy zacząć od trzech ryzyk, które pokazuje test. Najpierw krytyczne luki, potem odpowiedzi, które straciły najwięcej punktów. Każde z nich prowadzi do prostej definicji w naszym słowniku. Jeśli wolą Państwo, by naprawili je inżynierowie, właśnie to robi plan Plutonapps.

Wolą Państwo, by naprawili to inżynierowie?

Państwo dalej projektują w Lovable. Inżynierowie Plutonapps czynią prawdziwy produkt bezpiecznym, przetestowanym i gotowym na produkcję – w abonamencie.

Zobacz plany