Oczywiste pytanie przy siedmiu repo w jednej głowie: jak to nie jest chaos? Najprostsza odpowiedź: nie ogarniam siedmiu projektów. Ogarniam jeden system, którego siedem repozytoriów to są części. To zupełnie inna kategoria pracy.
Dziś chciałem opisać, jak te części się ze sobą gadają — bo to jest sedno, dlaczego to w ogóle daje się robić solo. Bez tego byłaby to siódemka oddzielnych projektów, z których każdy by mnie z osobna pochłaniał.
Co stoi gdzie
Najgrubsze repo to backend platformy — ogłoszenia, autoryzacja, geografia, moderacja, mapa. Mózg domenowy. Obok niego aplikacja mobilna — to, co naprawdę widzi sąsiad, kiedy otwiera juz-ide na telefonie. Te dwa są produktem.
Pod nimi siedzi moja biblioteka domenowa — pisana latem 2025, od maja 2026 udostępniona publicznie. To jest język, w którym produkt mówi: agregatyAgregat (aggregate)Grupa obiektów domenowych traktowana jako całość przy zapisie; pilnuje spójności reguł biznesowych. czytaj więcej → , zdarzenia domenoweZdarzenie domenowe (domain event)Fakt, który zaszedł w domenie (np. „użytkownik zarejestrowany”). Inne części systemu mogą na niego zareagować. czytaj więcej → , kontrakt między warstwami. Bez niej oba produkty pisałyby ten sam kod od zera.
Obok tego — repozytorium ze standardami pracy z AI. To jest mój zestaw zasad: sposób, w jaki definiuję role agentów, reguły kodowania, szablony dla nowych projektów. To samo dla pracy z AI, czym biblioteka domenowa jest dla samej domeny.
Drugi produkt — narzędzie do rozliczania pracy w grantach dla polskich firm. Konsument wszystkiego powyżej: używa mojej biblioteki, zasad ze standardów AI, kopiuje wzorce z backendu juz-ide. Powstaje w dwa dni zamiast dwóch tygodni, bo nie zaczyna od zera.
Bot operacyjny na Discordzie — wirtualny zespół z personami. Dziś czyta z innych repów, niedługo zacznie do nich pisać. Robi to, co normalnie robiłby w firmie ktoś od status-reportów, monitoringu i powtarzalnych operacji.
Company OS — to ostatnie. System operacyjny firmy. Trzyma listę „pracowników” (czyli person AI i moją), decyzje strategiczne, dokumentację ról. To jedyne miejsce, w którym istnieje oficjalna lista ludzi i botów, mających do czegokolwiek dostęp.
Strzałki — kto czyta od kogo
To nie jest siedem niezależnych światów. To jest sieć, w której wiadomo, kto produkuje, kto konsumuje i gdzie jest interfejs między nimi.
Najprostszy łańcuch wygląda tak. Przy pracy nad konkretną funkcją w backendzie juz-ide podejmuję decyzję — na przykład „idempotencja na poziomie HTTP i osobno na poziomie kolejki, bo retry-y mają różne źródła”. Spisuję to jako ADR w repozytorium backendu. Jeśli decyzja jest na tyle ogólna, że zadziała w każdym projekcie, dopisuję ją też jako wzorzec do repozytorium standardów AI — gdzie staje się instrukcją dla agenta, który następnym razem pisze coś podobnego.
Kiedy potem zaczynam pracę nad drugim produktem, nie zaczynam od zera. Klikam w katalog wzorców, biorę wzorzec dwuwarstwowej idempotencji i wpinam go od pierwszego commitu. Z dwóch dni roboty mam dwie godziny — bo nie myślę „jak to zrobić”, tylko „dopasowuję to, co zostało już raz przemyślane”.
Drugi łańcuch idzie przez company OS. Kiedy zatrudniam nową personę AI (powiedzmy „odpowiedzialny za content marketingowy” albo „bot operacyjny do git-monitoringu”), wpisuję ją do listy pracowników w tym repo. Wpis mówi, kim jest, co może, w którym kanale na Discordzie ma głos. Bot — uruchamiany osobno — odczytuje tę listę przy starcie i automatycznie respektuje to, co tam wpisałem. Żadnej drugiej konfiguracji, żadnego synchronizowania. Plik jest jeden, kontrakt jest jeden.
Trzeci łańcuch przechodzi przez bibliotekę domenową. Kiedy coś w niej zmieniam — jak w styczniu przy renamie pola w kontrakcie zdarzeń — produkt dostaje breaking change. Brutalny, namacalny, kompilator krzyczy. Ten ból jest celowy: biblioteka jako jedno źródło prawdy tylko wtedy działa, gdy konsekwencje jej zmian docierają natychmiast tam, gdzie się ją konsumuje.
Dlaczego to system, nie kupa projektów
Trzy rzeczy decydują, czy zestaw repozytoriów jest systemem, czy tylko zbiorem rzeczy.
Pierwsza: każde repo ma jedną robotę. Nie ma repo, które robi „trochę wszystkiego”. Mobile robi aplikację. Biblioteka robi bibliotekę. Repo standardów AI robi standardy pracy. Jeśli się zatrę, w którym repo coś leży — to znaczy, że źle podzieliłem.
Druga: każde repo ma jedno wyjście, którym oddaje pracę innym. Biblioteka oddaje paczkę npm. Repo standardów oddaje pliki konfiguracyjne dla agentów. Company OS oddaje listę „pracowników”. Backend i mobile oddają ADR-y i tasking, z których korzysta drugi produkt. Nigdy nie ma dwóch sposobów, w jaki repo coś komuś przekazuje — bo wtedy zaczynają się dryfy.
Trzecia: konsumpcja zawsze idzie przez gita. Repo A nie woła do repo B po HTTP. Po prostu pulluje. To brzmi prymitywnie i jest prymitywne. Dla jednoosobowej firmy to ogromna oszczędność: nie ma serwisów do trzymania, endpointów do utrzymywania, kontraktów API do wersjonowania między projektami. Wersjonowanie robi git.
Czego ten system nie załatwia
Nie pomaga w jednym: w czasie, którego trzeba na przerzucenie głowy między repami. Jeśli rano siedziałem w backendzie juz-ide nad geo-autoryzacją, a po obiedzie otwieram drugi produkt nad raportowaniem przychodów — to jest mentalna kosztowna transakcja. Te dwa tematy wymagają zupełnie różnego trybu myślenia.
Walczę z tym jedną zasadą: jeden dzień, jedno repo. Nie zawsze się udaje, zwłaszcza gdy coś pilnego wymaga doraźnego skoku. Ale kiedy pilnuję — produktywność podwaja się w stosunku do dni „dzisiaj ogarnę cztery rzeczy”.
Drugi minus: dług dokumentacyjny. System działa, dopóki ja pamiętam, które repo czego się spodziewa po drugim. Jeśli mnie jutro przejedzie tramwaj, ktoś, kto przyjdzie po mnie, nie ma jak tego odtworzyć — bo „wiedza o systemie” jest u mnie w głowie. Pracuję nad tym, ale to praca, która jeszcze trwa.
Po co to wszystko
Skala, na której potrzebuję, żeby ten system zadziałał, nie jest skalą korporacji. To jest skala jednoosobowej firmy, która chce dowieźć aplikację sąsiedzką dla niewielkiego miasta — i ma pas startowy mierzony tygodniami, nie kwartałami.
Każde repo z osobna jest wymówką, żeby pracować jak zespół. Biblioteka nakłada na mnie dyscyplinę bibliotekarza — pisz API, jakby konsumował je ktoś, kogo nie znasz. Repo standardów nakłada dyscyplinę liderską — spisuj to, co inaczej zostałoby w głowie, żeby agent (albo następny ja) miał z czego korzystać. Company OS nakłada dyscyplinę menedżerską — kto co robi, gdzie są kompetencje, kogo o co prosić.
Każdy z tych „pracowników” w teorii jestem ja sam. W praktyce — jestem trochę kim innym w każdym repo. A na końcu, gdy ktoś otworzy aplikację, żeby zobaczyć, czy ktoś z drugiej ulicy oddaje rower dla dziecka, ten ktoś nie wie, że za prostym ekranem stoi siedem osobnych miejsc, w których przez ostatnie pół roku coś się działo. I tak ma być.