Większość founderów buduje jeden produkt. Ja buduję siedem rzeczy naraz. Backend, aplikację mobilną, bibliotekę, drugą aplikację, bota na Discordzie, zestaw narzędzi do pracy z AI i wiki. Brzmi jak przepis na katastrofę dla jednego człowieka.
A jednak to jest przemyślane. I o tym właśnie jest ten blog.
Siedem części jednej maszyny
Kiedy wymieniam projekty, brzmi to jak chaos. Ale każdy z nich ma swoje miejsce:
- juz-ide.pl — flagowy produkt. Platforma sąsiedzka dla małych polskich miast: zweryfikowani sąsiedzi, lokalne usługi, system zaufania. To backend, aplikacja mobilna i wydzielona biblioteka domenowa.
- drugi produkt — narzędzie do rozliczania pracy w grantach dla polskich firm. Zaczęło jako monitor grantów, a stało się aplikacją do zarządzania projektami i finansami. O tym pivocie napiszę osobno — to ciekawa lekcja.
- bot na Discordzie — moja „prawa ręka”. Asystent, który ma odciążać mnie z powtarzalnej pracy i z czasem stać się czymś w rodzaju wirtualnego zespołu.
- narzędzia do pracy z AI — zestaw wzorców, agentów i konfiguracji, dzięki którym jeden człowiek pracuje jak kilkuosobowy zespół.
- wiki — warstwa wiedzy. Pamięć firmy: i dla mnie, i dla AI.
Pięć pozycji, a mówiłem o siedmiu — bo sam juz-ide.pl to trzy osobne repozytoria (backend, aplikacja mobilna, biblioteka domenowa). Stąd siedem. Każda z tych rzeczy z osobna to projekt. Razem mają być jednym organizmem.
Dlaczego nie jeden produkt na raz
Klasyczna rada brzmi: skup się na jednym. Zwykle słuszna. Ale ja nie buduję „jeszcze jednej apki” — buduję sposób, w jaki firma ma działać.
Jeśli docelowo chcę, żeby AI pomagało mi prowadzić biznes — pisać treści, pilnować decyzji, ogarniać operacje — to mózg (bot), narzędzia i wiedza (wiki) nie są dodatkiem do produktu. Są infrastrukturą, na której wszystko inne stoi. Budowanie produktu bez tej infrastruktury oznaczałoby, że i tak będę musiał ją dorobić później — drożej.
Ale pod tym wszystkim — systemem, botem, siedmioma repozytoriami — jest powód dużo mniej efektowny. Po pandemii sam zaszyłem się w domu i niemal przestałem wychodzić; znam z bliska to dziwne uczucie, gdy chcesz być wśród ludzi, ale nie wiesz już dokąd ani do kogo pójść. Większość tego, co tu buduję, kręci się wokół tego jednego, dość prywatnego problemu.
Po co o tym pisać na żywo
Mógłbym budować po cichu i pokazać wynik. Ale build-in-public ma dla mnie trzy konkretne powody:
- Zmusza do jasności. Jak mam coś wytłumaczyć obcej osobie, muszę najpierw zrozumieć to sam. Pisanie wyłapuje dziury w myśleniu.
- Zostawia ślad decyzji. Za rok nie będę pamiętał, dlaczego wybrałem tak, a nie inaczej. Blog (i AI, które go czyta) będzie pamiętać za mnie.
- Jest uczciwe. Pokazuję też to, co nie wyszło. Bez tego build-in-public to tylko marketing w przebraniu.
Czego się spodziewać
Będę pisał w czterech wątkach:
- Technologia — jak to jest zbudowane (DDD, geo-weryfikacja, bezpieczeństwo, mobile).
- Ekonomia — pricing, granty, jednostkowa ekonomia, pivoty.
- AI — jak buduję AI-first workflow i wirtualnego asystenta.
- Zespół — jak jeden człowiek ogarnia siedem projektów bez wypalenia.
Bez marketingowego bełkotu. Konkrety, kod, prawdziwe liczby. Tam, gdzie czegoś jeszcze nie wiem — powiem, że nie wiem.
Jeśli budujesz solo albo interesuje cię, jak poskładać firmę jak system z AI w środku — zostań. Następne wpisy wchodzą w szczegóły każdej z tych części.