Zbudowałem SaaS w 30 dni. Najtrudniejsze wcale nie było kodowanie

Przez długi czas widziałem ten sam problem u ludzi, którzy pracują na swoim: niby są ciągle online, niby mają LinkedIna, Slacka, Discorda i kalendarz zapchany po brzegi, a i tak działają jak samotne wyspy. To nie jest tylko wrażenie. 48% solo-przedsiębiorców w Polsce zgłasza chroniczną samotność. I szczerze? Mnie ta liczba wcale nie dziwi.

Dlatego wziąłem sobie na warsztat pomysł prosty jak konstrukcja młotka: stworzyć narzędzie do szybkiego networkingu online, coś w stylu speed-datingu, tylko dla przedsiębiorców. Krótkie rundy 1:1, sensowne parowanie, profil uczestnika, czat, follow-up po wydarzeniu i wszystko spięte tak, żeby dało się to naprawdę sprzedać, a nie tylko pokazać znajomym na Discordzie.

Najciekawsze było to, że samo napisanie kodu wcale nie okazało się największym wyzwaniem. Najwięcej roboty zjadło mi ogarnięcie rzeczy, które zwykle są zamiatane pod dywan: zgodność z consentem, sensowny deployment, koszty infrastruktury, bezpieczeństwo i pytanie, czy to się w ogóle spina biznesowo. Jeśli chcesz zbudować własne MVP, to właśnie tutaj najłatwiej wpaść do rowu.

W tym tekście pokażę Ci, jak ja do tego podszedłem: od wyboru problemu, przez szybkie budowanie, aż po moment, w którym produkt musi przestać być „fajnym projektem”, a zacząć działać jak normalny biznes.

Nie zaczynam od funkcji. Zaczynam od bólu

Popełniłem kiedyś klasyczny błąd człowieka, który lubi robić rzeczy: najpierw myślałem o funkcjach, a dopiero potem o tym, po co one w ogóle istnieją. To działa mniej więcej tak dobrze, jak kupowanie szafki pod zlew przed wyborem mieszkania.

W moim przypadku zadziałało odwrócenie kolejności. Najpierw zdefiniowałem problem: przedsiębiorcy pracujący solo potrzebują kontaktu z ludźmi, ale nie chcą spędzać trzech godzin na jałowym evencie, z którego pamiętają tylko temperaturę kawy. Dopiero potem dobrałem mechanikę. Krótkie rundy 3-5 minut, szybkie przejścia, preselekcja profili, dopasowanie i prosty follow-up po spotkaniu.

To ważne, bo MVP nie ma imponować listą bajerów. Ono ma usunąć jeden konkretny ból. Jeśli tego nie zrobisz, skończysz z aplikacją, która jest bardzo nowoczesna, bardzo inteligentna i bardzo niepotrzebna.

MVP w 30 dni brzmi sexy. W praktyce to walka z chaosem

Ja zbudowałem ten produkt od pustego folderu do działającego MVP w mniej więcej miesiąc, po godzinach. Wyszły z tego setki commitów, kilka audytów bezpieczeństwa i pięć wyraźnych faz rozwoju. Brzmi romantycznie tylko z daleka.

Rzeczywistość wyglądała bardziej jak remont łazienki w bloku z wielkiej płyty: odkręcasz jedną rurkę, a po chwili pytasz życie, czemu woda leci z sufitu. Im szybciej budujesz, tym bardziej musisz pilnować priorytetów.

Ja trzymałem się jednej zasady: każda funkcja musi bronić się pytaniem „czy bez tego użytkownik dalej rozwiąże swój problem?”. Dzięki temu nie próbowałem robić kosmicznej platformy networkingowej dla całego świata. Skupiłem się na tym, żeby uczestnik wszedł, uzupełnił profil, został sparowany, pogadał i miał prostą drogę do kontaktu po wydarzeniu.

• Najpierw postawiłem fundamenty: konta użytkowników, logikę eventów, płatności i podstawowy panel klienta.
• Potem dołożyłem rdzeń produktu: parowanie, rundy wideo, czat i profile uczestników.
• Na końcu dopieszczałem rzeczy, które robią różnicę w realnym użyciu: administrację eventem, analitykę uczestnictwa, integracje i kwestie bezpieczeństwa.

Taki układ uratował mnie przed przepaleniem czasu. Zauważyłem, że przy SaaS-ach największym złodziejem energii nie jest trudny kod, tylko nieustanne dokładanie „jeszcze jednej małej rzeczy”, która niby trwa godzinę, a potem zjada pół dnia i kawałek godności.

AI ma pomagać w rdzeniu produktu, a nie robić za świecący brelok

Bardzo nie lubię wciskania AI tam, gdzie zwykły formularz załatwiłby sprawę szybciej i taniej. Jeśli AI jest tylko po to, żeby w pitch decku było modne słowo, to prędzej czy później zacznie Cię kosztować więcej niż daje.

U mnie AI miało sens, bo wspierało sam środek doświadczenia użytkownika. Wykorzystałem je do dopasowania uczestników na podstawie profili i do generowania pytań, które mogą pomóc zacząć rozmowę. To nie jest fajerwerk. To jest smar do mechanizmu. Dzięki temu ludzie nie trafiają w ciemno i nie zaczynają spotkania od niezręcznego „eee, czym się zajmujesz?”.

Ale tu jest pułapka. Każda funkcja AI oznacza też koszty, opóźnienia, edge case’y i konieczność mierzenia, czy to faktycznie działa. Jeśli potem chcesz to sprzedawać w subskrypcji, nie wystarczy powiedzieć „mam AI”. Ja muszę wiedzieć, ile kosztuje obsługa jednego użytkownika, jakie mam szanse na konwersję i czy retencja po 30, 60 i 90 dniach w ogóle daje nadzieję na zdrowy model. Bez tego budżet potrafi się rozjechać szybciej niż hulajnoga na krawężniku.

Najbardziej niedoceniona część MVP: legalność i zgody

Wielu ludzi buduje aplikację tak, jakby prawo było dodatkiem DLC, który można dokupić później. Ja uważam odwrotnie. Jeśli zbierasz dane, używasz analityki, odpalasz reklamy albo planujesz nagrywanie rozmów, to temat zgód i prywatności musisz mieć ogarnięty od początku.

Dlatego wdrożyłem mechanizm cookie consent oparty o Cookiebot by Usercentrics, z consent mode. I to nie było „bo tak trzeba”, tylko dlatego, że bez tego łatwo strzelić sobie w stopę. Skrypty reklamowe i analityczne nie mogą odpalać się przed zgodą użytkownika. Jeśli odpalają, to masz problem. Nie wizerunkowy. Prawdziwy.

Ja przeszedłem przez to dość praktycznie: założenie konta, dodanie domeny, wybór kraju i trybu zgód, ustawienie języków banera, wdrożenie skryptu ręcznie albo przez Tag Manager, a potem weryfikacja, czy wszystko zachowuje się poprawnie na produkcji. Nudne? Trochę. Krytyczne? Bardzo.

Do tego dochodzi temat przechowywania sekretów, logowania zgód i zasad przetwarzania danych przez agentów AI. Im szybciej korzystasz z automatyzacji, tym łatwiej coś przeoczyć. A potem człowiek się budzi z ręką w słoiku po ciasteczkach i tłumaczy, czemu logi są w trzech miejscach, a nikt nie wie, kto miał do nich dostęp.

Serwer za 34 zł to dopiero początek rozmowy o kosztach

Bardzo łatwo jest powiedzieć: „wrzucę to na VPS i temat zamknięty”. Sam lubię takie proste historie, ale życie rzadko chce w nich grać.

Ja postawiłem aplikację na VPS-ie i wykorzystałem Dockera oraz manager hostingu do deploymentu. Taki plan jak KVM2 za 34 zł miesięcznie brzmi rozsądnie na start i faktycznie może wystarczyć do MVP. Do tego dochodzi 30-dniowa gwarancja zwrotu pieniędzy, więc na etapie testów ryzyko jest znośne. Tylko że sama cena serwera mówi niewiele o pełnym koszcie działania.

Jeśli masz aplikację z wideo, czatem, analityką i logiką parowania, to infrastruktura zaczyna żyć własnym życiem. Dochodzi ruch, stabilność połączeń, konfiguracja DNS, klucze SSH, bezpieczeństwo, backupy, monitoring i moment, w którym musisz się zastanowić, czy ten setup dalej wytrzyma, gdy liczba wydarzeń wzrośnie. Właśnie dlatego lubię deploy zautomatyzowany agentami i uporządkowany przez kontenery. To nie jest fanaberia. To jest sposób, żeby nie zamienić wdrożenia w wieczną improwizację.

W moim przypadku sprawdziło się też podejście „najpierw działająco, potem pięknie”. Nie budowałem od razu fortecy na milion użytkowników. Zbudowałem sensowny start, a jednocześnie zostawiłem sobie przestrzeń na późniejsze porządki i przepisywanie miejsc, które pod obciążeniem mogłyby zacząć skrzypieć.

Test użytkowników mówi prawdę szybciej niż Twoje ego

Moment prawdy przychodzi wtedy, gdy prawdziwi ludzie zaczynają klikać w Twoją aplikację bez instrukcji i bez taryfy ulgowej. U mnie bardzo ważny był test na żywo z około 80 uczestnikami. Taki sprawdzian błyskawicznie pokazuje, czy mechanika rund, parowanie i flow wydarzenia faktycznie mają sens.

I właśnie wtedy wychodzą rzeczy, których nie zobaczysz w samotnym testowaniu. Ktoś nie wie, gdzie kliknąć. Ktoś nie rozumie, co zrobić po zakończonej rundzie. Ktoś chce szybciej wrócić do kontaktu z rozmówcą. Ktoś inny oczekuje lepszych danych o uczestnictwie. To jest złoto, nawet jeśli chwilami boli.

Ja nauczyłem się jednej rzeczy: nie przywiązuję się do wersji kodu, tylko do problemu, który chcę rozwiązać. Jeśli feedback pokazuje, że coś trzeba uprościć, wyciąć albo przepisać, to robię to bez sentymentów. MVP nie jest pomnikiem. To jest narzędzie do uczenia się, za które czasem płacisz własnym weekendem.

Co teraz powinieneś zrobić?

Jeśli miałbym wyciągnąć z tego jedną lekcję, to brzmiałaby tak: zbudowanie MVP jest dziś szybsze niż kiedykolwiek, ale zrobienie z niego sensownego produktu dalej wymaga myślenia jak przedsiębiorca, nie tylko jak wykonawca. Kod to dopiero początek. Potem wchodzą koszty, zgody, retencja, testy i cała ta mniej seksowna część, od której zależy, czy projekt przeżyje dłużej niż pierwszy zachwyt.

Ja bym nie zaczynał od pytania „jaką aplikację zbudować?”, tylko od pytania „jaki problem boli na tyle, że ludzie naprawdę chcą go rozwiązać?”. Reszta to już rzemiosło. Trudne, ale do ogarnięcia.

• Najpierw znajdź konkretny ból rynku, dopiero potem wymyślaj funkcje.
• MVP ma działać, a nie zachwycać liczbą bajerów.
• Consent, bezpieczeństwo i infrastruktura to część produktu, nie dodatek na później.
• AI ma wzmacniać rdzeń wartości, a nie robić marketingowy dym.
• Test z prawdziwymi użytkownikami szybciej niż Twoje opinie pokaże, co jest do poprawy.

Next Step: wypisz dziś jeden problem, który widzisz u swojej grupy klientów, i dopisz pod nim tylko trzy funkcje, bez których rozwiązanie nie ma prawa działać. Nic więcej.

A Ty jaki problem najchętniej zamieniłbyś w małe, konkretne MVP zamiast odkładać go na kiedyś?