Od pomysłu SaaS do produkcji bez 502

1. Zakres MVP na papierze

• Jeden główny scenariusz użytkownika (nie pięć półgotowych).
• Lista rzeczy świadomie odłożonych (backlog, nie „może się uda”).
• Kryterium sukcesu po 30 dniach: metryka albo konkretne zachowanie użytkowników.

2. Model danych i migracje

• Schemat w wersjonowanych migracjach, nie „ręcznie na produkcji”.
• Start aplikacji HTTP nie zależy od udanej migracji w tym samym procesie CMD.
• Środowisko staging z osobną bazą (nigdy te same dane co produkcja).

3. Autentykacja i role

• Logowanie działa, reset hasła działa, sesja wygasa przewidywalnie.
• Role: kto widzi panel admina, kto tylko dane własne.
• Brak tajnych kluczy w froncie i w repozytorium Git.

4. Integracje zewnętrzne

• Timeouty i retry przy API partnerów.
• Czytelny status błędu dla operatora (nie tylko 500 w Network).
• Sandbox / tryb testowy przed podpięciem płatności live.

5. Infrastruktura i HTTPS

• Kontener Docker z jasnym start command (np. npm start).
• Nginx reverse proxy, certyfikat Let’s Encrypt, przekierowanie HTTP→HTTPS.
• Domena własna albo subdomena *.devstudioit.app z poprawnym DNS.
• Healthcheck: proces słucha na porcie zanim uznamy deploy za sukces.

6. Kopie zapasowe i odtworzenie

• Backup bazy według harmonogramu.
• Przynajmniej raz przetestowane odtworzenie na stagingu.
• Lista sekretów do odtworzenia środowiska (nie „jest w Slacku sprzed roku”).

7. Obserwowalność

• Logi aplikacji dostępne po deployu.
• Alert przy padnięciu procesu / 502.
• Prosty runbook: co robić, gdy strona nie wstaje.

8. Definicja „możemy ogłaszać premierę”

Dopiero gdy punkty 2–7 są zielone. Marketing i płatny ruch przed tym momentem tylko zwiększa koszt awarii. Na naszej platformie checklista jest częścią procesu: build z GitHub, SSL, sonda HTTP, dopiero potem status „live”.

Szerszy opis procesu: Jak budujemy SaaS. Infrastruktura: Docker, Nginx, SSL. Kontakt: napisz brief.

Wróć do bloga