Archiwum

Przez pół roku budowałem rzeczy dla audytorium liczącego mniej więcej zero osób. W dwóch tygodniach maja sześć części systemu przestało być prywatne — i każda zaczęła mówić do kogoś innego.

Do tygodnia temu bot tylko czytał. Teraz pisze — i to do drugiego produktu, nie do tego, w którym mieszka. Linia między asystentem a członkiem zespołu właśnie się przesunęła.

DDD po ludzku — kontekst, agregat, zdarzenie domenowe, Result. Krótkie definicje pojęć, które przewijają się przez cały blog. Wracaj tu, gdy coś zabrzmi obco.

Jestem jedną osobą, ale chcę pracować jak zespół. Buduję bota, który ma być mózgiem firmy — i celowo nie jest przywiązany do Discorda. Oto stan na dziś.

W maju 2026 ekran powitalny mówił starym imieniem produktu, renderował systemowym fontem i odbijał logo gumową animacją — wszystko wbrew temu, co od miesięcy stało w brand booku.

Jedna osoba, siedem repozytoriów, pięć dni roboczych. Brzmi jak chaos. W praktyce to system, w którym każde repo ma jedną robotę i jedno miejsce, w którym ją komuś innemu oddaje.

Nowy użytkownik miał niski poziom zaufania, więc serwer pokazywał mu mniej ogłoszeń. Mniej ogłoszeń = mniej interakcji = niskie zaufanie na dłużej. Pętla ukryta w pozornie sensownej regule.

Mogłem skrócić start drugiego produktu o miesiąc. Trzeba było tylko jednej fikcyjnej spółki na każdego użytkownika. Im dłużej o tym myślałem, tym mniej chciałem ten skrót brać.

Cała platforma stoi na zasadzie: jeden polski numer telefonu = jeden konkretny człowiek. Świetnie dla mieszkańca. Rozsypuje się w weekend, gdy spróbujesz tym uwierzytelnić spółdzielnię.

Wtorek rano: w aplikacji nie ma żadnej mapy. Środa wieczorem: pełen tab z rysowaniem zasięgu, połączeniem z trzema typami treści i testami wizualnymi. Pomiędzy — dwanaście commitów.

Aplikacja ma osobny tryb dla seniorów — 25% naszych przyszłych użytkowników. Animacje powinny być wolniejsze. Token mówił 350 ms. Każdy ekran z osobna wpisywał 150.

Piszę na tym blogu, żeby nie przekombinowywać produktu. A potem przekombinowałem własne zaplecze: maszynę do generowania konfiguracji, której nie potrzebowałem. Cargo cult u jednej osoby.

Przez lata mierzyłem swoją pracę jakością kodu. Budowanie własnej firmy zmusiło mnie do zupełnie innego pytania — i to była trudniejsza zmiana niż każdy framework.

Najpierw startupy, potem świadomie korporacja. Co wziąłem z każdego świata — i czemu to bank, a nie startup, nauczył mnie myśleć o firmie.

Mój zespół AI ma kilka modeli o bardzo różnej cenie. Długo używałem najdroższego do wszystkiego — także do zadań bez krzty myślenia. To był po prostu źle rozstawiony zespół.

W każdym repo powtarzałem ten sam zestaw zasad dla AI. Wyciągnąłem go do osobnego miejsca — nie po to, żeby sprzedać, tylko żeby przestać wymyślać koło na nowo.

Osiem punktów, osiemdziesiąt godzin czyszczenia biblioteki. Gdy w końcu po nie sięgnąłem, prawie nic nie zostało do zrobienia — i to zmieniło sposób, w jaki planuję pracę z AI.

Własną bibliotekę zostawiłem w spokoju na cztery miesiące. W styczniu odżyła — nie dlatego, że tak zaplanowałem, tylko dlatego, że produkt potrzebował zmienić jedno słowo w kontrakcie.

Większość founderów buduje jeden produkt. Ja buduję siedem — bo celem nie jest siedem rzeczy, tylko jeden system do prowadzenia firmy. O tym jest ten blog.

Grudzień 2025: funkcja się nie zmieniła, zmienił się tylko jej tytuł. 'Alerty' brzmiały jak sytuacja kryzysowa. 'Ogłoszenia' brzmiały jak platforma sąsiedzka.

Grudzień 2025: opłata za wystawienie zamiast prowizji od transakcji. Decyzja podjęta bez danych rynkowych — i dlaczego to był właściwy moment.

24 grudnia 2025: bug z wylogowaniem na mobilce. Po wylogowaniu użytkownik wciąż był zalogowany — bo dwa systemy zarządzały sesją i jeden ignorował drugi.

Grudzień 2025: wybrałem polskie centrum danych, choć jest droższe. Decyzja infrastrukturalna motywowana nie techniką, ale tym, co mówi klientowi.

Grudzień 2025: pierwszy projekt moderacji zakładał, że każda treść przejdzie przez AI. To kosztowało zbyt dużo i było zbyt wolne. System zaufania okazał się lepszy.

Grudzień 2025: rejestracja przez email to standard. Dla polskiego rynku lokalnego — to zły standard. Każda polska karta SIM wymaga od 2016 roku podania PESEL.

Listopad 2025: ta sama osoba jest usługodawcą, klientem i moderatorem jednocześnie. Jak zamodelować tożsamość, gdy role nie są wzajemnie wykluczające.

Listopad 2025: pierwsze zlecenia sąsiedzkie i ogłoszenia społeczności gotowe. Pierwsza funkcja biznesowa w systemie — przy zerze prawdziwych użytkowników.

Listopad 2025: system weryfikacji adresu mógłby blokować każdego, kto nie przeszedł pełnej weryfikacji. Zamiast tego — ufam na wejście i weryfikuję stopniowo.

Listopad 2025: weryfikacja adresu w juz-ide opiera się na TERYT — państwowym rejestrze jednostek podziału terytorialnego. Co to jest, dlaczego to wybrałem i jak to działa.

Listopad 2025: Nowe podejście do testów w juz-ide. Specyfikacja-first — najpierw dokument reguły, potem implementacja i test razem.

Listopad 2025: RODO wymaga śledzenia dostępu do danych osobowych. Dlaczego log audytu trafia do osobnej kolejki — i co by się stało, gdyby nie trafiał.

Listopad 2025: jeden obiekt domenowy robił zbyt dużo. Jak rozdzielenie go na dwa poprawiło model — i dlaczego granica powinna odpowiadać granicy zmiany.

7 listopada 2025: system weryfikacji adresu zamieszkania — v1 gotowa. Co się zmieniło od startu, ile zajęło i co oznacza 'gotowe' bez użytkowników.

Październik 2025: odrzuciłem pomysł, który wyglądał jak uproszczenie. Zapis tego 'nie' okazał się ważniejszy niż większość zapisanych 'tak'.

Październik 2025: rdzeń juz-ide — weryfikacja adresu zamieszkania. Dlaczego to jest problem architektoniczny, nie tylko product.

Październik 2025: pierwsze kolejki zadań w juz-ide. Dlaczego nie wszystko powinno dziać się w tej samej chwili — i co to zmienia w sposobie myślenia o aplikacji.

Październik 2025: jak zaprojektowałem integrację AI z budżetem $100/miesiąc i jednym developerem — zamiast pytać 'jak wdrożyć AI', zapytałem 'za ile'.

Bezpieczeństwo, które większość pomija. Październik 2025: mechanizm blokujący złośliwe skrypty w przeglądarce — i dlaczego wdrożenie go zajęło pięć dni.

Październik 2025: system autoryzacji juz-ide zamknięty w jednym, absurdalnie dużym commicie. Co poszło dobrze, co poszło źle, i co z tego wynika dla pracy solo.

Trzy projekty, jeden miesiąc, ten sam wzorzec: AI generuje tysiące linii, człowiek kasuje. To nie jest anty-AI — to o dyscyplinie.

Wrzesień 2025: odkryłem w bibliotece kod, który udawał szybki. Raporty wyglądały świetnie — liczby były sfabrykowane.

Sierpień–wrzesień 2025: dlaczego zacząłem od backendu, kiedy zdecydowałem się na Neo-Brutalist UI, i jak to jest budować dwie aplikacje na raz w pojedynkę.

Dwa repozytoria, 290 i 265 linii każde, i prawie identyczna struktura. Wrzesień 2025: jak jedna abstrakcja usunęła 70% duplikacji.

Email to nie kawałek tekstu. Imię to nie string. Sierpień 2025: jak dane osobowe stały się typami domenowymi, i dlaczego RODO pomogło pisać lepszy kod.

Przez lata sprawdzałem: 'czy to admin?'. Sierpień 2025 to zmieniło — system autoryzacji, który pyta wyłącznie o akcję i obiekt.

Zaplanowałem 21 kontekstów dla aplikacji z zerem użytkowników. Oto dlaczego zredukowałem plan do 6 i czego nauczył mnie over-engineering w solo-startupie.

Zastane zabezpieczenie okazało się przestarzałe. Wymieniłem je. Myślałem, że to zamknięty temat — nie był.

Trzy prototypy umarły tak samo: szybki start, chaos po miesiącu, przepisywanie od zera. Dlatego pierwszy tydzień poświęciłem na fundamenty, których żaden użytkownik nie zobaczy.

W zwykłym NestJS to samo pole API opisujesz trzy razy. Opowiadam, czemu w juz-ide wybrałem jedno źródło prawdy — i co mnie to kosztowało.

W jeden wieczór wrzuciłem do repo 18 agentów AI jako wirtualny zespół. Następnego ranka połowę przeniosłem do „fazy drugiej”. Co z tego zostało.

Zacząłem jako samouk od frontendu. Potem projekt z DDD uderzył jak ściana. Dziś nie buduję inaczej — i piszę własną bibliotekę. Oto jak do tego doszło.

Zamiast kupić gotowy framework albo pisać od zera, wydzieliłem prywatną bibliotekę DDD. Czy to sens dla solo foundera, czy kolejny over-engineering?

Dwa tygodnie po starcie produktu zatrzymałem go na prawie dwa miesiące i zbudowałem osobną bibliotekę. Brzmi jak prokrastynacja. Była najlepszą decyzją tamtego lata.

16 maja: jeden commit-drobiazg. Potem 60 dni nic. 16 lipca: powrót. Build-in-public ma też puste miejsca na wykresie aktywności.

Tego samego dnia co basic setup zmieniłem jeden wiersz w konfiguracji bazy danych. Mała zmiana, duży sygnał o tym, co tak naprawdę buduję.

Poniedziałek: jeden plik README. Piątek: 29 plików, Docker, CI-ready stack. Co wrzucić w pierwszy realny commit, a co odpuścić.