Aplikacja działa u mnie — co sprawdzić przed wpuszczeniem klientów?

Przed uruchomieniem aplikacji sprawdź siedem rzeczy:

1. Główną czynność na nowym koncie, bez Twojej pomocy.
2. Logowanie i reset hasła na prawdziwej skrzynce.
3. Dwa konta testowe — czy nie widzą swoich danych.
4. Płatności: zakup, odmowę i powtórzone powiadomienie od operatora.
5. Odtworzenie kopii bazy w osobnym środowisku.
6. Błędy i powiadomienia — czy dowiesz się o awarii.
7. Pocztę, domenę, regulamin i dane osobowe.

Twoja aplikacja to nowy lokal przed otwarciem. W środku pachnie świeżą farbą i wszystko wygląda dobrze. Zanim wpuścisz gości, sprawdzasz zamki, kasę, sejf, czujnik dymu i kartkę z regulaminem na drzwiach.

Ty znasz każdy kąt i masz klucze do wszystkich drzwi. Klient nie zna niczego i będzie korzystał bez Ciebie obok. Przejdź więc jego drogę.

Lista poniżej pomaga to zrobić. Jej zakres zależy od produktu: aplikacja z kontami, plikami i płatnościami potrzebuje więcej prób niż publiczny kalkulator. Kilka udanych prób to nie pełny audyt bezpieczeństwa — przy poważnym ryzyku poproś o przegląd specjalistę.

Tajemniczy klient: jedna czynność, za którą ktoś płaci

Sieci sklepów wysyłają „tajemniczych klientów”, żeby zobaczyć sklep oczami kupującego. Zrób to samo. Jeśli sprzedajesz narzędzie do ofert, przejdź całą drogę: wejście, wybór pozycji, zapis i ponowne otwarcie oferty.

Zrób to na nowym koncie testowym, nie na koncie administratora. Administrator ma klucz do wszystkiego i nie zobaczy tego, co zablokuje klienta.

Potem poproś kogoś, kto nie zna produktu, żeby zrobił to samo na wymyślonych danych. Nie podpowiadaj. Notuj każdą chwilę, w której się zatrzymuje albo rozumie ekran inaczej, niż myślałeś.

Na koniec sprawdź:

1. błędne dane i pusty formularz,
2. odświeżenie strony,
3. telefon,
4. czy po ponownym wejściu zapisany wynik nadal jest.

Zgubiony klucz: czy klient wróci do swojego konta?

Wyloguj się i zaloguj ponownie. Przejdź reset hasła przez prawdziwą skrzynkę testową. Zobacz, dokąd prowadzi link i co się stanie, gdy klikniesz go drugi raz. Jeśli logowanie działa bez hasła albo przez Google, sprawdź tę ścieżkę.

Wygasła sesja, czyli „wylogowanie po czasie”, nie może zostawić kogoś przed pustym ekranem. Sprawdź też, co dzieje się z rozpoczętą pracą.

To nie dodatek, tylko część usługi. Ktoś, kto zapłacił i nie może wejść, potrzebuje działającej drogi pomocy.

Dwa konta testowe — test, który wyłapuje najgroźniejszy błąd

Załóż dwa konta. Każde tworzy swój dokument. Sprawdź, czy pierwsze konto może odczytać, zmienić albo usunąć dokument drugiego.

To jak sprawdzenie, czy klucz do pokoju 12 nie otwiera pokoju 14. Ukrycie cudzego dokumentu na ekranie nie wystarczy. Blokada musi działać także wtedy, gdy ktoś pyta zaplecze aplikacji bezpośrednio, z pominięciem ekranów.

W Supabase pilnują tego reguły RLS, czyli zamki na poziomie każdego wiersza w bazie. Trzeba je ustawić samemu, wybór dostawcy ich nie zastępuje. Dokumentacja Supabase RLS

Sprawdź też konto administratora i to, co widać bez logowania. Jeśli aplikacja trzyma pliki, sprawdź ich adresy i uprawnienia. Testuj tylko własne środowisko. Gdy nie umiesz ocenić wyników, oddaj ten fragment do niezależnego przeglądu.

Kasa: zakup, odmowa i wszystko pomiędzy

Zacznij w trybie testowym operatora płatności. Sprawdź udany zakup, odrzuconą kartę, przerwanie i powrót do aplikacji po zamknięciu strony płatności. Ustal, co klient ma dostać i na jak długo.

Przy subskrypcji sprawdź jeszcze odnowienie, nieudaną kolejną płatność i rezygnację. Dostęp ma się kończyć dokładnie tak, jak obiecuje oferta. Pierwsze obciążenie karty to dopiero początek.

Informacja o płatności przychodzi do aplikacji osobną drogą, niezależnie od powrotu klienta. To webhook — powiadomienie, które operator wysyła sam. Stripe uprzedza, że takie powiadomienia mogą przyjść dwa razy i w innej kolejności, niż zakładasz. Stripe — obsługa webhooków

Poproś o dowód, że powtórzone powiadomienie nie nada dostępu podwójnie. Sprawdź też, czy aplikacja weryfikuje, że powiadomienie naprawdę pochodzi od operatora. Prawdziwa płatność to osobny etap — z małym zakresem i porównaniem danych operatora z danymi w aplikacji.

Sejf: kopia, którą naprawdę odtworzyłeś

Panel dostawcy może mówić, że kopie robią się same. Musisz jeszcze wiedzieć, co w nich jest i jak przywrócić z nich działający produkt. Kluczyk do sejfu, którego nigdy nie próbowałeś, może nie pasować.

Zrób próbę w osobnym środowisku:

1. Przywróć dane testowe z kopii.
2. Otwórz aplikację i sprawdź kilka rekordów.
3. Zapisz, z jakiej chwili pochodzi kopia i ile pracy wymagało odtworzenie.

Nigdy nie rób tej próby przez nadpisanie bazy z prawdziwymi klientami.

Uważaj na pliki. Supabase wyjaśnia, że kopia bazy nie zawiera samych plików z Storage, tylko informacje o nich. Załączniki trzeba zabezpieczyć osobno. Supabase — Database Backups

Czujnik dymu: dowiesz się o błędzie przed następnym klientem?

W bezpiecznym środowisku wywołaj kontrolowaną awarię: wyłączoną usługę testową, nieudaną wysyłkę maila, odrzucony zapis. Sprawdź, co widzi klient i gdzie Ty zauważysz problem.

Komunikat dla klienta ma mówić, czy się udało i co zrobić dalej. Dziennik błędów ma pomagać Ci znaleźć przyczynę, ale bez haseł, kluczy i zbędnych danych klientów.

Wyślij wiadomość przez formularz kontaktowy i sprawdź, czy dochodzi.

Poczta i domena: czy maile w ogóle dochodzą?

Mail z resetem hasła albo potwierdzeniem zakupu musi dojść i nie trafić do spamu. Wbudowana poczta niektórych usług służy tylko do testów — w Supabase wysyła domyślnie 2 maile na godzinę i tylko do Twojego zespołu. Przed startem podłącz własnego dostawcę poczty, ustaw dla domeny rekordy, które potwierdzają nadawcę, i wyślij próbne maile na kilka różnych skrzynek. Sprawdź też, czy domena ma ważny certyfikat (kłódka w przeglądarce) i czy strona otwiera się szybko na słabszym telefonie.

Kartka na drzwiach: czy oferta mówi to samo, co robi aplikacja?

Cena, okres dostępu, odnawianie i rezygnacja muszą być jasne przed zakupem i zgodne z tym, jak działa produkt. Przy sprzedaży konsumentom sprawdź obowiązki informacyjne dla swojej usługi. Unijny portal Your Europe opisuje wymagania sprzedaży na odległość. Informacje dla sprzedawców

Spisz, jakie dane osobowe zbierasz, po co, gdzie trafiają i jak odpowiesz, gdy ktoś zapyta o swoje dane. Sam checkbox nie załatwia sprawy. Your Europe — ochrona danych

W Polsce warto znać nazwy przepisów: ustawę o prawach konsumenta (m.in. prawo odstąpienia od umowy przy treściach i usługach cyfrowych), RODO oraz ustawę o świadczeniu usług drogą elektroniczną, która wymaga regulaminu. To nie porada prawna — tylko lista tematów do sprawdzenia.

Nie kopiuj regulaminu z cudzej aplikacji, jeśli nie opisuje Twojej. W razie wątpliwości przygotuj prosty opis działania i skonsultuj go.

Notuj wynik, nie ptaszka

Przy każdej próbie zapisz wersję aplikacji, środowisko, scenariusz, oczekiwany i faktyczny wynik. Używaj trzech stanów: „sprawdzone”, „nie działa”, „nie wiem”. Próba, której nie zrobiłeś, ma zostać widoczna — nie zamieniaj jej na zielony ptaszek.

Tak samo sprawdzamy własną pracę. Ograniczenia i poprawki opisaliśmy w historii testu code2saas.

Chcesz przygotować własną aplikację do sprzedaży w ten sposób? Wyślij zgłoszenie do Buildera i opisz, co budujesz i na czym teraz utknąłeś. Zakres, termin i cenę omawiamy na rozmowie.

Jeszcze nie teraz? Zostaw e-mail na liście — napiszemy, gdy ruszy kolejny nabór.