Kompletna lista kontrolna przed uruchomieniem produktu cyfrowego. Obejmuje testy techniczne, bezpieczeństwo, analitykę, aspekty prawne i marketing. Użyj minimum 2 tygodnie przed planowanym launch date.
🚨 Wszystkie krytyczne ścieżki użytkownika przetestowane end-to-end
Rejestracja → onboarding → core feature → płatność → wylogowanie. Testuj jako nowy użytkownik, nie jako developer znający system.
🚨 Testy na różnych urządzeniach i przeglądarkach
iOS Safari, Android Chrome, Desktop Chrome/Firefox/Safari/Edge. Różne rozdzielczości: 375px, 768px, 1280px, 1920px. Używaj BrowserStack lub Sauce Labs.
Testy regresji — nic co działało wcześniej nie jest zepsute
Zautomatyzowane testy E2E (Playwright, Cypress) lub ręczna regression suite. Uruchom przed każdym deploy.
Error handling działa poprawnie
Celowo wywołaj błędy: brak internetu, timeout serwera, nieprawidłowe dane. Użytkownik widzi sensowny komunikat i wie co zrobić.
Formularze walidują dane po stronie klienta i serwera
Wymagane pola, formaty (email, telefon, NIP), limity długości. Walidacja frontendowa to UX — backendowa to bezpieczeństwo.
Płatności przetestowane w trybie sandbox
Stripe/Przelewy24 test mode: udana płatność, odrzucona karta, 3DS, refund, webhook. Sprawdź czy faktury/potwierdzenia są wysyłane.
Emaile transakcyjne działają i wyglądają poprawnie
Rejestracja, reset hasła, potwierdzenie płatności, powiadomienia. Testuj na Gmail, Outlook, Apple Mail. Sprawdź spam score (mail-tester.com).
Dostępność (accessibility) — WCAG 2.1 AA
Kontrast kolorów min. 4.5:1, alt texty dla obrazów, nawigacja klawiaturą, ARIA labels. Sprawdź: axe DevTools, Lighthouse.
Load testing — aplikacja wytrzyma 10x oczekiwany ruch
k6, Artillery, Locust. Symuluj ruch launch day: nagły spike użytkowników. Znajdź bottleneck zanim znajdą go użytkownicy.
Core Web Vitals w zieleni (LCP <2.5s, FID <100ms, CLS <0.1)
Google PageSpeed Insights, Lighthouse. Wpływa na SEO i UX. LCP = Largest Contentful Paint, FID = First Input Delay, CLS = Cumulative Layout Shift.
Czas odpowiedzi API <200ms dla 95. percentyla
Mierz p50, p95, p99 — nie tylko średnią. Średnia ukrywa problemy. Użyj Datadog, New Relic lub własnego monitoringu.
Obrazy zoptymalizowane (WebP, lazy loading, odpowiednie rozmiary)
Niezoptymalizowane obrazy to najczęstsza przyczyna wolnych stron. Squoosh, ImageOptim, next/image.
CDN skonfigurowany dla statycznych zasobów
Cloudflare, AWS CloudFront, Vercel Edge Network. Zmniejsza latency dla użytkowników z różnych lokalizacji.
Baza danych ma indeksy na często używanych kolumnach
EXPLAIN ANALYZE w PostgreSQL. Brak indeksów = pełny table scan przy każdym zapytaniu = wolna aplikacja przy skali.
🚨 Automatyczne backupy bazy danych skonfigurowane i przetestowane
Codzienne backupy, retencja min. 30 dni. Przetestuj restore — backup bez testu restore = brak backupu. RTO i RPO zdefiniowane.
Środowisko produkcyjne oddzielone od staging i dev
Osobne bazy danych, osobne klucze API, osobne zmienne środowiskowe. Nigdy nie testuj na produkcji.
Skalowanie automatyczne skonfigurowane
Auto-scaling na AWS/GCP/Azure lub serverless (Vercel, Firebase). Aplikacja nie padnie przy nagłym spike ruchu.
Health check endpoints działają
/health lub /ping zwraca 200 OK z informacją o stanie serwisu. Używany przez load balancer i monitoring.
Graceful shutdown zaimplementowany
Aplikacja kończy aktywne requesty przed wyłączeniem. Ważne przy rolling deployments.
Rollback plan przygotowany
Jak szybko cofniesz deploy jeśli coś pójdzie nie tak? Blue-green deployment, feature flags, wersjonowane obrazy Docker.
🚨 Analytics skonfigurowane i zweryfikowane
Mixpanel, Amplitude, PostHog lub GA4. Sprawdź czy eventy faktycznie trafiają do systemu — nie zakładaj, że działają.
🚨 Error tracking włączony (Sentry, Bugsnag, Rollbar)
Każdy nieobsłużony błąd trafia do systemu z pełnym stack trace, kontekstem użytkownika i środowiskiem. Alert na email/Slack.
🚨 Uptime monitoring skonfigurowany
UptimeRobot (darmowy), Pingdom, Better Uptime. Sprawdzaj co 1 minutę. Alert SMS/email gdy strona padnie.
Kluczowe eventy biznesowe są trackowane
sign_up, activation, first_payment, churn. Bez tych eventów nie wiesz czy produkt działa.
Dashboard z kluczowymi metrykami gotowy
DAU, signups, activation rate, revenue. Przeglądaj codziennie przez pierwsze 30 dni po launch.
Alerty na anomalie skonfigurowane
Nagły spadek signupów, wzrost błędów, spadek revenue. Grafana, Datadog, CloudWatch Alarms.
🚨 Polityka prywatności — RODO-compliant, dostępna na stronie
Co zbierasz, jak używasz, jak długo przechowujesz, prawa użytkownika. Link w footerze i przy rejestracji. Skonsultuj z prawnikiem.
🚨 Regulamin (Terms of Service / Terms of Use)
Zakres usługi, odpowiedzialność, warunki rozwiązania, prawo właściwe. Wymagany przy rejestracji (checkbox, nie pre-checked).
🚨 Cookie consent zgodny z RODO
Banner z możliwością odrzucenia. Nie trackuj przed zgodą. Kategorie: niezbędne, analityczne, marketingowe. Osmoze, Cookiebot, Axeptio.
Dane kontaktowe i informacje o firmie widoczne
Wymagane przez prawo: nazwa firmy, NIP/KRS, adres, email. W footerze lub na stronie "O nas".
Jeśli SaaS: regulamin subskrypcji i polityka zwrotów
Warunki anulowania, polityka refundów (wymagana przez prawo konsumenckie UE — 14 dni na zwrot).
Jeśli zbierasz dane dzieci: dodatkowe zabezpieczenia (COPPA/RODO art. 8)
Weryfikacja wieku, zgoda rodziców. Jeśli produkt nie jest dla dzieci — wyraźnie to zaznacz w ToS.
Landing page z jasnym value proposition gotowy
Odpowiada na: co to jest, dla kogo, jaką wartość daje, co mam zrobić teraz. Testuj copy z prawdziwymi użytkownikami przed launch.
Lista 20–50 pierwszych kontaktów do powiadomienia
Personalizowane emaile, nie masowy newsletter. "Hej [imię], pamiętasz jak rozmawialiśmy o X? Właśnie uruchomiliśmy..."
Social media profiles aktywne i spójne z brandem
LinkedIn (B2B), Twitter/X, Instagram (B2C). Zaplanuj 3–5 postów na launch week.
Plan na Product Hunt (jeśli B2C/developer tools)
Przygotuj: tagline, description, gallery, first comment. Zbierz "hunters" z dużą liczbą followersów. Launch we wtorek–czwartek.
Support channel gotowy (email, chat, FAQ)
Użytkownicy będą mieć pytania. Intercom, Crisp, Freshdesk lub prosty email. FAQ z 10 najczęstszymi pytaniami.
Plan komunikacji na pierwsze 30 dni po launch
Onboarding emails (dzień 1, 3, 7, 14, 30), check-in z pierwszymi użytkownikami, iteracje na podstawie feedbacku.
