Izometryczna ilustracja: platforma z kołami organizacji i osobami, nad którą agenci AI dokładają kolejne elementy aplikacji Circles

Circles. Własne narzędzie zamiast dwóch SaaS-ów. Od pierwszego commita do całej firmy w 6 tygodni

Circles

Nasza rola

Architektura, budowa z agentami AI i utrzymanie – na własnym przykładzie

Pod koniec sierpnia 2026 r. wiedzieliśmy, że narzędzie, na którym opiera się cała organizacja SYZYGY Warsaw, zostanie wyłączone w połowie października. Zamiast migrować na kolejny SaaS, zbudowaliśmy własną aplikację w podejściu AI-native. Pierwsza wersja działała na produkcji po trzech dniach, a po sześciu tygodniach zastąpiła dwa zewnętrzne narzędzia dla około 50 osób. Prowadziła ją jedna osoba – kod w dużej mierze piszą i utrzymują agenci AI.

Sytuacja

Siedem tygodni do wyłączenia narzędzia, na którym stoi cała firma

SYZYGY Warsaw to ok. 50 osób, które nie mają klasycznej hierarchii. Pracujemy w kołach i rolach, a strukturą, celami (OKR) i cyklicznymi spotkaniami zarządzaliśmy w Holaspirit. Urlopy i nieobecności żyły w osobnym narzędziu – Calamari.

Holaspirit ogłosił zamknięcie usługi 16 października 2026 r. Po audycie okazało się, że realnie korzystamy z niewielkiej części funkcji: kół i ról, spotkań prowadzonych według szablonów oraz OKR-ów. Mieliśmy trzy opcje: przejść na następcę z pakietem funkcji, których nie potrzebujemy, szukać innego SaaS-a albo zbudować coś swojego – dokładnie na naszą miarę i pod twardy termin.

Decyzja: budujemy, ale tylko to, czego naprawdę używamy

27 sierpnia zapadła decyzja o budowie lekkiego, własnego zamiennika. Zakres wyznaczyły dane z audytu, a nie lista funkcji dostawcy. Najpierw koła, role i ludzie, potem spotkania z agendą i OKR-y, a w drugim kroku urlopy – żeby przy okazji pozbyć się drugiej subskrypcji. Plan był skromny: 8–10 skupionych dni pracy z AI, a potem dwa tygodnie, w których stare i nowe narzędzie działają równolegle.

Warunek postawił Marcin Stasiak, Head of Tech Solutions, który poprowadził projekt: jeśli przenosimy całą firmę z jej codziennych narzędzi, rozwiązanie musi być w pełni utrzymywalne i wymagać jak najmniej ręcznej obsługi. To klasyczne pytanie Build vs Buy – w podejściu AI-native odpowiedź wyszła inaczej niż jeszcze rok temu.

Jak to zbudowaliśmy: człowiek ustala reguły, agenci AI piszą kod

Człowiek odpowiada za architekturę i za reguły, których aplikacja nie może złamać. Agenci AI wykonują dużą część implementacji. Każda zmiana przechodzi tę samą drogę:

Zgłoszenie. Ktoś z zespołu opisuje problem własnymi słowami, często jednym zdaniem i zrzutem ekranu. Agent zamienia to w specyfikację i test, który dziś nie przechodzi.
Implementacja. Agent pisze poprawkę na osobnej gałęzi.
Weryfikacja. Zmiana musi przejść komplet testów, których agent nie może zmienić. Osobny agent-recenzent uruchamia aplikację i próbuje ją zepsuć.
Wdrożenie. Gdy wszystko jest zielone, zmiana sama trafia na produkcję – często w nocy. 15 października dwie zmiany weszły na produkcję o 3:45 i 4:40, bez udziału człowieka.

Do połowy października w repozytorium powstało 929 commitów: 467 to commity Marcina, około 450 – agentów AI i automatów. Pojedyncze zgłoszenie zamyka się w medianie po 13 godzinach, ale realnej pracy jest w tym ok. godzina. Dla zgłaszającego oznacza to prostą zasadę: opisujesz problem dziś, poprawkę widzisz następnego ranka.

Wdrożenie: od pierwszego commita do całej firmy w niespełna 6 tygodni

27 sierpnia – decyzja i pierwszy commit
30 sierpnia – pierwsze wdrożenie produkcyjne
3 września – start procesu z agentami AI
2 października – dostęp dla całej firmy (wcześniej testy w jednym kole)
8 października – import pełnej historii z obu starych narzędzi; od następnego dnia pracujemy tylko w Circles
16 października – wyłączenie Holaspirit; byliśmy już tydzień po przejściu

Uwagi użytkowników z okresu przejściowego trafiały prosto do kolejki agentów. W pierwszej dużej paczce zgłoszeń droga od jednego zdania napisanego przez osobę nietechniczną do działającej poprawki na produkcji zajęła 75 minut.

6tygodni

od pierwszego commita do pełnego zastąpienia dwóch SaaS-ów w całej firmie

3dni

do pierwszego wdrożenia produkcyjnego

1osoba

prowadząca projekt; prawie połowę z 929 commitów napisali agenci AI i automaty

13h

mediana od zgłoszenia do zamkniętej poprawki, w tym ok. 1 h realnej pracy

~50osób

pracuje dziś w Circles; przenieśliśmy ponad 2800 spotkań i prawie 400 OKR-ów

Rezultat

Mniej subskrypcji, narzędzie szyte na miarę i rozwój, który nie stoi

Zamiast płacić za dwa narzędzia, z których używaliśmy ułamka funkcji, mamy jedno – dokładnie takie, jakiego potrzebujemy.

	Przed	Po
Narzędzia	Holaspirit + Calamari (oraz osobne rozwiązania do parkingu i wiki)	Jedna aplikacja – Circles
Abonamenty	2 subskrypcje SaaS, płatne niezależnie od tego, z ilu funkcji korzystamy	0 subskrypcji SaaS; płacimy za infrastrukturę i pracę agentów
Dopasowanie	Funkcje dostawcy, w tym nieużywane	Tylko to, czego używamy, plus własne reguły (np. nieobecności dla UoP i B2B)
Rozwój	Zgłoszenie do dostawcy i czekanie	Mediana 13 h od zgłoszenia do zamkniętej poprawki; najszybciej 75 minut
Integracje	Ograniczone do tego, co daje dostawca	Jira, kalendarz, asystent Claude, API dla aplikacji mobilnej

Uczciwie: pełny rachunek oszczędności jeszcze się nie domknął. Abonamenty zniknęły, ale sam proces z agentami też kosztuje, a zwrot liczymy w dłuższym okresie. Dlatego zanim cokolwiek obiecamy klientowi, liczymy Build vs Buy na jego danych.

Co z tego wynika dla Twojego projektu

Circles nie jest produktem, który sprzedajemy. Jest dowodem, że to, o czym mówimy klientom, działa u nas na co dzień.

Build vs Buy trzeba policzyć od nowa. Jeśli płacisz za SaaS, z którego używasz części funkcji, własne narzędzie może dziś wyjść taniej – i lepiej pasować do Twoich procesów.
Szybkość nie musi kosztować jakości. Agenci piszą dużą część kodu, ale nic nie trafia na produkcję bez kompletu testów i niezależnego recenzenta.
Utrzymanie przestaje przejadać budżet. Zgłoszenia użytkowników zamieniają się w poprawki automatycznie, więc zespół może zajmować się rozwojem.