Pirxey przestał
dopasowywać firmę
do narzędzia.
Zamiast szukać kolejnego SaaS-a, firma ok. 150 osób zaczęła budować własny system operacyjny. Pierwszy moduł to time tracking w miejsce Clockify. Ale projekt od początku był pomyślany szerzej: jako fundament pod raporty, profile ludzi, estymacje, wyceny, tickety i pracę z agentami AI.
AI-native software house z Gdańska, zespół ok. 150 osób, produkty cyfrowe od 2018. pirxey‑os to ich wewnętrzny system operacyjny, wdrożony na produkcji.
pirxey.com
Przez lata własny software był zarezerwowany dla największych firm. Drogi, długi we wdrożeniu, ryzykowny. Dlatego małe i średnie firmy wybierały SaaS-y. Nawet jeśli nie pasowały idealnie, były szybsze i prostsze na start.
Pirxey, firma licząca ok. 150 osób, korzystała z Clockify. Z czasem pojawił się klasyczny problem SaaS-ów: narzędzie nie rozwijało się pod potrzeby firmy, część funkcji była zbędna, a tych naprawdę ważnych brakowało. Proces musiał dopasowywać się do narzędzia, a nie odwrotnie.
Łukasz spojrzał na to szerzej niż „trzeba wymienić Clockify”. Jego intuicja była prosta: jeśli firma ma własny sposób pracy, powinna mieć też software, który ten sposób pracy wspiera.
Była w tym też druga, równie ważna stawka: chciał sprawdzić, czy z pomocą AI da się dziś faktycznie zbudować realnie działający software: nie prototyp i nie demo, ale system, który udźwignie codzienny proces firmy.
Tak powstał pirxey‑os. Od pierwszego dnia chodziło o coś większego niż wymiana jednego narzędzia.
Własny software przestał być luksusem. Pirxey przestał dopasowywać firmę do narzędzia i zaczął budować narzędzie dopasowane do firmy.
Dzięki AI i nowoczesnym narzędziom firma 100–200 osób może dziś budować własny system operacyjny: dopasowany do ludzi, procesów i klientów, rozwijany razem z organizacją i wolny od ograniczeń gotowych SaaS-ów. Finanse tylko wspierają tę tezę. Cała reszta strony to argumenty, które jej bronią.
SaaS działa szybko na start. Ale potem firma zaczyna dopasowywać się do narzędzia.
Clockify rozwiązywało podstawowy problem time trackingu, ale nie mogło rozwijać się zgodnie z potrzebami Pirxey. Firma płaciła za funkcje, których nie potrzebowała, a jednocześnie brakowało tych ważnych dla jej własnego procesu. Największa frustracja była prosta:
„Muszę robić to inaczej, niż potrzebuję. To nie działa tak, jak działa nasza firma.”
I to nie był problem jednej brakującej funkcji. Firmy rzadko mają jeden SaaS. Zaczynają od jednego narzędzia, potem dokładają kolejne, aż proces przestaje żyć w systemie, a zaczyna żyć w integracjach, eksportach i arkuszach.
Dane to potwierdzają. Według raportu Okta „SMBs at Work 2024” ↗, firmy używają średnio ok. 93 aplikacji; mniejsze firmy ok. 58, a nawet te do 50 osób, ok. 36. Jeden SaaS to żaden problem. Kłopot zaczyna się wtedy, gdy firma ma 6 narzędzi, 12 integracji i nikt już nie wie, gdzie naprawdę żyje proces.
Time tracking jako pierwszy moduł własnego systemu operacyjnego.
Zamiast szukać kolejnego SaaS-a albo budować jednorazowy replacement, Pirxey potraktował time tracking jako pierwszy moduł większego systemu. To zmienia kategorię projektu: z aplikacji do logowania godzin w fundament wewnętrznego OS-a firmy.
AI zmieniło przy tym ekonomikę budowania software'u. Custom system można dziś dowieźć szybciej i taniej niż kilka lat temu. Wniosek jest praktyczny: jeśli proces jest krytyczny, powtarzalny i kosztowny w SaaS-ach, warto policzyć, czy nie powinien stać się własnym systemem.
Sześć powodów, dla których własny system wygrywa z kolejnym SaaS-em: od dopasowania, przez AI, po rachunek.
Decyzja Pirxey nie była przeczuciem. Stoi za nią sześć konkretnych argumentów: od dopasowania do procesu, przez własność i gotowość na agentów AI, po rachunek build vs buy. Każdy kolejny rozdział rozwija jeden z nich, a projekt go broni.
- 01 Dopasowanie do firmy System działa według procesu Pirxey, a nie odwrotnie. ↓ rozdział
- 02 Jeden system zamiast wielu Konsolidacja kilku SaaS-ów sklejonych integracjami. ↓ rozdział
- 03 Własność, bez vendor lock-in Software zostaje w firmie jako asset, nie jako najem. ↓ rozdział
- 04 Rośnie razem z firmą Roadmapa wynika z potrzeb Pirxey, nie z decyzji vendora. ↓ rozdział
- 05 Gotowy na agentów AI API i MCP, nie tylko interfejs dla ludzi. ↓ rozdział
- 06 Rachunek się spina Build vs buy: własny asset zamiast powtarzalnego najmu. ↓ rozdział
Software, który dopasowuje się do firmy.
W SaaS-ie firma musi zaakceptować gotowy model pracy. Jeśli proces jest inny, pojawiają się obejścia, ręczna praca i frustracja. W pirxey‑os logika jest odwrotna: time tracking działa tak, jak pracuje Pirxey, raporty są skrojone pod rozliczenia z klientami, a funkcje, których Clockify nie oferował, po prostu są.
Największą wartością własnego software'u jest to, że działa dokładnie tak, jak działa Twoja firma, a niższy koszt to już tylko efekt uboczny.
Jeden system zamiast wielu SaaS-ów.
pirxey‑os idzie w przeciwnym kierunku niż „kolejne narzędzie”. Zamiast sklejać sześć aplikacji integracjami, buduje jeden spójny system. Mniej chaosu, mniej punktów awarii, jedno źródło prawdy, prostsze dostępy, lepsze bezpieczeństwo i mniej przełączania się między aplikacjami.
Własność i brak vendor lock-in.
SaaS jest wygodny, ale oznacza zależność. Vendor może podnieść ceny, zmienić pakiety, ograniczyć funkcje, zmienić API albo rozwijać produkt w innym kierunku niż potrzeby klienta. Własny software jest inny: jest assetem firmy. Zostaje w organizacji jako część jej wartości, wiedzy i majątku.
Jeśli proces jest krytyczny dla firmy, warto zadać pytanie: czy chcemy go wynajmować od vendora, czy posiadać jako własny asset?
System rozwija się razem z firmą.
SaaS rozwija się według roadmapy vendora. Własny system rozwija się według roadmapy firmy. pirxey‑os zaczął od time trackingu, ale może rosnąć dalej: profile ludzi, raportowanie, estymacje, wyceny, tickety, agentic workflows. To daje firmie opcjonalność. Zamiast każdą nową potrzebę rozwiązywać kolejnym SaaS-em, można rozwijać własny system.
Największą przewagą własnego software'u jest to, że rośnie razem z firmą — kolejne procesy stają się kolejnymi modułami.
System otwarty na agentów AI: przez API i MCP, nie tylko przez interfejs.
- Pirxey Dashboard · 18h 10m
- Med4You · 9h 30m
- Wewnętrzne · 3h 20m
- Spotkania · 1h 40m
Wpis przez zwykłą rozmowę, nie przez formularz.
Pracownik pisze na Telegramie tak, jak do kolegi z zespołu. Agent rozumie intencję, zapisuje czas przez MCP i odpowiada naturalnym podsumowaniem, bez logowania się do panelu i klikania w pola.
A pod spodem działa to samo API i MCP, z których korzystają inni agenci ↓
# Dodanie wpisu bez otwierania UI POST https://os.pirxey.tech/api/v1/time-entries Authorization: Bearer <api_key> { "project": "Pirxey Dashboard", "description": "Code review PR #42", "duration": "1:30", "tags": ["coding"] }
// Pirxey jako narzędzie agenta { "mcpServers": { "pirxey‑os": { "url": "https://os.pirxey.tech/mcp", "apiKey": "<api_key>" } } } // → "zaloguj 1.5h na code review" // agent wykonuje zapis przez MCP
pirxey‑os ma publiczne REST API i MCP server. Wpisy mogą powstawać przez Claude Desktop, terminal, Telegram czy innego agenta, bez klikania w interfejsie. W erze AI dobry system firmowy ma nie tylko UI dla ludzi, ale też API i warstwę dla agentów.
To samo podejście agentic-first prowadzę dalej w case study BR-Budget: aplikacji finansowej, w której głównym użytkownikiem nie jest człowiek, tylko agent AI działający w jego imieniu przez API.
A liczby spinają się szybciej, niż można się spodziewać.
Finanse nie są główną tezą, ale mocno ją wspierają. Dla firmy 150-osobowej SaaS time tracking po ok. 80 zł miesięcznie za użytkownika to rząd ~144 000 zł rocznie, koszt powtarzalny. Budowa pirxey‑os zamknęła się w rzędzie ~50 000 zł i ok. 20 dni roboczych.
- Koszt powtarzalny co roku
- Roadmapa po stronie vendora
- Ograniczona kontrola nad procesem
- Po roku zostaje opłacona subskrypcja
- Własny system, nie najem
- Własna roadmapa i kolejne moduły
- Pełna kontrola nad danymi i procesem
- Po roku zostaje asset, który dalej rośnie
Za podobny budżet firma może przestać wynajmować cudzy proces i zacząć budować własny asset, a oszczędność jest tu tylko dodatkiem.
Tak wygląda pirxey‑os w produkcji.
Własny design system projektowany pod Pirxey: z kolorami, komponentami i trybem jasnym oraz ciemnym. Poniżej kilka realnych ekranów: tracker, grafik, kalendarz i raporty. Ten sam system, różne konteksty pracy.
Rzeczywisty stack
Skoro wiemy dokładnie, jak działa Pirxey, to dlaczego mamy dopasowywać się do generycznego narzędzia? Chcieliśmy sprawdzić, czy możemy zbudować system, który działa po naszemu: najpierw dla time trackingu, a później jako fundament pod kolejne procesy firmy.
Dowiezione jako pełny produkt — od architektury po wdrożenie.
To nie był szybki prototyp, tylko realny software obsługujący realny proces w realnej firmie: architektura, aplikacja, API, import danych historycznych, bezpieczeństwo, testy i wdrożenie produkcyjne. Wszystko bez software house'a — w jednej parze rąk.
- 01Discovery i analiza procesuZrozumienie, jak naprawdę działa time tracking w 150-osobowej firmie.
- 02Architektura i model danychFundament projektowany od razu pod cały system kolejnych modułów.
- 03Design i front-endWłasny system kolorów, komponentów, tryb jasny i ciemny.
- 04Back-end i import danychLogika systemu oraz migracja historii z Clockify.
- 05API i MCPPubliczne REST API, MCP server, warstwa dla agentów AI.
- 06Bezpieczeństwo i wdrożenieUprawnienia, RLS, Sentry, testy, środowiska produkcyjne.
Bez przekazywania między PM, analitykiem, designerem i developerem. Jedna osoba, która zna ten system od pierwszego dnia: każda kolejna iteracja jest tańsza i szybsza, bo nikt nie musi uczyć się kontekstu od nowa.
pirxey‑os jest dziś używany przez kilka osób w testach produkcyjnych. Pełny rollout firmowy jest planowany od 1 lipca.
System ma być dalej rozwijany jako operacyjny fundament firmy, obejmując kolejne procesy: ludzi, profile technologiczne, estymacje, wyceny i tickety. To dopiero pierwszy moduł większej całości.
Custom software wraca jako realna opcja dla małych i średnich firm.
Przy pewnej skali warto policzyć, które procesy są zbyt ważne, żeby wynajmować je od zewnętrznego vendora. I czy nie lepiej je po prostu mieć.
Pirxey przestał dopasowywać firmę do narzędzia i zaczął budować narzędzie dopasowane do firmy.
Zainteresowany własnym systemem?
Jeśli płacisz za SaaS, który wymusza obejścia, sprawdźmy, czy własny moduł nie będzie tańszy i lepiej dopasowany do Twojego procesu.