Excel, Google Forms i moment, w którym wszystko się posypało

Zaczęło się banalnie. Nasza firma, BB8 Studio, zaczęła rosnąć i nagle okazało się, że przysłowiowy Excel przestał być ogarniany. Pierwszy system, który mieliśmy? Formularz Google, w którym można było zgłosić, że nie będzie się tego i tego dnia. Proste, prawda? Problem w tym, że ta informacja nigdzie później nie trafiała. Nie mieliśmy jej automatycznie w kalendarzu, nikt nie myślał o spinaniu tego wszystkiego – za dużo zmiennych, za dużo problemów.

Oczywiście formularz był zintegrowany z Excelem, ale to nie rozwiązywało naszego problemu. Potrzebowaliśmy czegoś lepszego. Czegoś, co będzie działać dla nas, nie przeciwko nam i w końcu ułatwi robotę Pawłowi, a także każdemu, kto z nami pracuje.

„Czemu nie mamy zrobić tego sami?”

Decyzja przyszła w momencie, kiedy szukaliśmy zajęcia na wolne chwile. Wspólną rozmową doszliśmy do wniosku, aby zamiast kupować kolejny kombajn, który będzie wymagał kadrowej z doktoratem z jego obsługi, spróbujmy zrobić to sami. Oferujemy przecież nasze usługi innym – czemu nie mamy zrobić czegoś dla siebie?

Paweł rozpoczął pracę z Kasią i Dajaną nad makietami, i co powinien zawierać taki Intranet – tak, nazwaliśmy go po prostu Intranet BB8, po dziś dzień zresztą pod takim adresem go mamy. Chcieliśmy prosty, dostępny dla każdego system. Bez zbędnych komplikacji.

Ja, jako designer, myślałem, że to będzie proste. Mamy Webflow – zrobimy to tam. Nie zdawałem sobie wtedy sprawy, jak skomplikowane to będzie i że sam stack Webflow kompletnie nie wystarczy. To był dokładnie ten moment, w którym wróciły pytania o wybór technologii, skalowalność i koszt późniejszych zmian - tematy, które opisywałem szerzej w tekście Webflow czy WWX — praktyczny przewodnik po wyborze technologii dla Twojego projektu.

Webflow, Wized, Xano – czyli moje pierwsze zderzenie z rzeczywistością

Przede wszystkim potrzebowaliśmy autentykacji użytkowników. A także bardziej rozbudowanej bazy danych niż ta, którą oferuje Webflow ze swoim CMS. Zacząłem eksplorować YouTube, szukając czegoś, co załata dziury wywołane ograniczeniami Webflow.

Po nitce do kłębka przeszedłem przez twórców Wized do samej tematyki Xano. Wszystkie te narzędzia są no-code, więc jeśli nauczyłem się Webflow, to samo uda mi się z resztą. Tak mi się wydawało na początku. ;)

Było to naprawdę trudne – przestawić się nagle na myślenie jak developer. Masa wiedzy do pochłonięcia, godziny siedzenia na tutorialach, poznanie logiki Xano i Wized. Ten ostatni przysparzał największy problem ze wszystkich – ich content na YouTube był mocno zdezaktualizowany. Z jednej strony mieli tutoriale, które opisywały moje potrzeby, ale były dla wersji legacy a ja pracowałem już na nowej. Nowych nie mieli, więc musiałem przysłowiowo szyć sam, jak te kwestie ze sobą połączyć.

Budowało to masę frustracji. Umówmy się – nadal byłem designerem, który dopiero co zaczął ogarniać Webflow w zadowalający go sposób.

Komfort następował stopniowo, z każdym wybuchem euforii, że coś zadziałało i że niemożliwe, że można to osiągnąć. Myślę, że zajęło mi to jakieś 3 miesiące, kiedy byłem już spokojny, że wiem, jak moje workflow powinno wyglądać. Pamiętajmy, że jednocześnie jeszcze dla relaksu rysowałem projekt w Figmie, a później musiałem go przenieść do Webflow. ;)

Od pewnego momentu zacząłem też posiłkować się Perplexity a później Claude, które dodawały mi coraz więcej pewności siebie i wiedzy na ten temat. Zadawałem pytania, kopiowałem błędy, które powstawały w Xano czy Wized. Powoli zacząłem korzystać z Projektów Claude, co pozwalało mi budować całą dokumentację, a sam Claude uczył się tego, co robię. 

BB8 Intranet działa. Co dalej?

Intranet działa po dziś dzień w naszej firmie. To była solidna podstawa. Ale wtedy przyszła myśl w zespole: poza naszą firmą jest milion podobnych, które się rozwijają i na pewno mają taką samą potrzebę. I nie pomyliliśmy się.

To był motor napędowy do zrobienia Time8 – naszego produktu SaaS.

Problem? BB8 Intranet był zrobiony "pod nas". Założenia dla Time8 były zupełnie inne. Chcieliśmy mieć produkt, który ma wiele workspace'ów, musi być wydajny, a przede wszystkim bezpieczny. Użytkownicy muszą w łatwy sposób stworzyć konto, zaprosić innych i działać.

I tutaj wiedziałem: to musi być kod. WWX stack nie wypali na taką skalę.

Skok na głęboką wodę: Next.js, TypeScript, Supabase

Miałem już 100% pewności, że Time8 będzie napisane w kodzie. I przyznam się szczerze – bałem się jak cholera, czy dam radę.

Był to moment, kiedy w internecie szalała magia "zrobię aplikację jednym promptem", a ja, jak to ja, sceptycznie nastawiony obserwowałem. Zakupiłem Claude Code i całą pracę zacząłem ogarniać z pomocą AI.

Pierwsze, co było dla mnie bajką, to odkrycie możliwości MCP. Połączenie biblioteki shadcn z biblioteką figmową, stworzoną przez Matt’a Wierzbickiego, pozwalało mi tworzyć pixel perfect layouty z projektów zrobionych przez Szymona (UI). To wiadomo, liczyło się najbardziej dla mnie jako designera – i czego zawsze nam brakowało od frontendów. ;)

A później mam wrażenie, że tylko odcinałem już kupony kolejnych poznanych narzędzi i pracy z nimi. Supabase, przez pewien czas używanie Cursor, kłótnie z developerami Cursor, (że ściemniają jeśli chodzi o zużycie tokenów). Dużo górek i dołków związanych z szukaniem optymalnego workflow.

„Zrobię aplikację jednym promptem” – czyli największe kłamstwo internetu

Jeśli ktoś mówi Ci, że zrobił aplikację jednym promptem, to tak naprawdę nie zrobił aplikacji – tylko mu się tak wydaje.

Ja prowadziłem ciągłe rozmowy z Claude. Dokumentowaliśmy każdy etap, planowaliśmy kolejne fazy, analizowaliśmy powstające makiety, projekty w Figmie, dogadywaliśmy co i jak ma działać. Obecnie mam już stworzonych customowych agentów w Claude Code, którzy wiedzą, jak analizować i jak przeprowadzać wdrożenie nowych funkcjonalności.

Ale droga do tego wcale nie była jak magiczne napisanie prompta!

RLS Policies były bólem w tyłku – ilekroć udawało się zrobić, chociażby funkcjonalności dodawania nowego urlopu, to okazywał się, że RLS coś blokowało. Integracja z API LemonSqueezy też przysporzyła sporo problemów. Bazy danych były dla mnie czarną magią. Musiałem nauczyć się konfigurowania Google OAuth, podpięcie SendGrid'a, aby wysyłać powiadomienia mailem – to wszystko każdego dnia było dla mnie nowym zestawem lekcji.

I wiesz co? Spojrzałem ostatnio do archiwum chatów Claude i sam się zaskoczyłem. Pierwszy raz zacząłem rozmowę z Claude na temat jeszcze wtedy nie Time8 a saas-leave-system które po dziś dzień się tak nazywa na localu - 6 miesięcy temu! Faktyczna aplikacja zaczęła powstawać 3 miesiące temu i jej pierwsza faza jest już ukończona w 90%!

78 migracji baz danych. 70+ API endpoints. 92 pliki komponentów. Next.js 15, React 19, TypeScript 5, Supabase, LemonSqueezy, SendGrid – cały stack, który senior developerzy uczą się latami.

Sceptycyzm, wolność i pytanie „czy ma to znaczenie?”

Paweł był sceptyczny. Reszta zespołu wydaje mi się, że też miała podobne odczucia. Nadal pamiętajmy, że wiara w to, że AI potrafi pomóc aż tak, jest mocno ograniczona.

Dla mnie vibe coding to swego rodzaju wolność. W końcu mam moc sprawczą nad wdrażaniem rozwiązań, których potrzebuję na tu i teraz. Nie muszę już odpowiadać zespołowi „nie da się” ani wyjaśniać w wielu kanałach komunikacji, spotkaniach z devami, dlaczego wdrożony front nie zgadza się z flow i zaakceptowaną przez klienta grafiką.

Oczywiście nie wiem, jakiej jakości jest kod, który powstaje. Mogę jedynie ufać agentom, których stworzyłem i oparłem o wiedzę innych twórców takich jak ja, że spełnia standardy.

Ale wiesz, na koniec – czy ma to znaczenie?

Jeśli okaże się, że ten produkt jest tym, czego ludzie potrzebują tak jak my, to czy nie będzie to miarą sukcesu? W tak krótkim czasie? W tak małym budżecie? Ile osób z samego działu developerskiego musiałoby być zaangażowanych do takiego projektu? Jaki musiałby to być koszt? I przede wszystkim – jak długo by trwał?

Wdrożenie frontu, który spełnia oczekiwania designera, to kwestia godzin, nie dni. Nie ma słów "nie da się". Istnieją słowa "pozwól mi to sprawdzić i może znajdziemy rozwiązanie".

Co dalej? Beta, konferencje i nowa definicja pracy

Od stycznia 2026 planujemy wpuścić pierwszych użytkowników do bety naszego produktu. Sami też mamy zamiar zmigrować się z naszego intranetu do Time8.

Wizja na 2026 jest taka, aby wyjść z fazy beta i zacząć promować to najmocniej, jak się da – opowiadać o tym na konferencjach, zrobić z tworzenia takich “szybkich” aplikacji usługę w BB8 Studio. Praca nad rozwojem wyszła poza mały zespół, pracujemy nad nim wspólnie - dołączyła do tego też Asia i Magda - czyli cały BB8 Team ma swój udział w budowaniu tego produktu. Wydawało mi się, że WWX będzie opcją szybkiego MVP, ale to, jak redefiniujemy nasz workflow przeszło moje wszelkie oczekiwania.

Nie wiem, jak zdefiniować swoją rolę teraz. Mam background designera, ale to, co teraz robię, to już nie design. Czuję się trochę jak MacGyver – robię z tego, co mam pod ręką, bez patrzenia na instrukcję. Ale poważnie – nie potrafię określić, kim jestem. ;)

Rada dla każdego, kto myśli „ja też chcę tak móc”

Mindset jest prosty: nie poddawaj się i zacznij to robić.

Eksploruj, ucz się i używaj AI nie jako jedno-promptowe rozwiązanie, a partnera w tworzeniu czegoś większego. Zadaj odpowiednie pytania. Dokumentuj. Nie bój się kodu – ja się bałem i wyszło.

Jeśli ja, designer, który 6 miesięcy temu nie miał pojęcia o TypeScript, RLS policies czy migracjach baz danych, zbudowałem SaaS w 3 miesiące – to znaczy, że bariera wejścia nigdy nie była niższa.

Więc przestań czytać i zacznij budować. Twój własny Time8 czeka.

PS. W momencie pisania tego tekstu właśnie posłałem 580 commit na github ;)