Zbudować czy kupić rejestrację czasu: czego nauczyło nas wyłączenie własnego serwera

10 sierpnia 2026 roku wyłączyliśmy serwer budowania, który działał od stycznia 2019. Był niezawodny. Był nasz. Pod koniec jego wyłączenie było oczywiście słuszne, a na początku równie oczywiście słuszne było postawienie go u siebie. Obie te rzeczy są prawdziwe, a przestrzeń między nimi to całe pytanie o to, czy budować, czy kupić.

Właśnie wyłączyliśmy jedno z własnych narzędzi wewnętrznych

Większość tekstów o tym, czy budować, czy kupić, piszą ludzie sprzedający stronę kupna, którzy nigdy nie nieśli strony budowy. My nieśliśmy obie, w przeciwnych kierunkach, i to zestawienie jest najbardziej użyteczną rzeczą, jaką możemy zaoferować.

Ta ostatnia liczba jest tą, przy której warto się zatrzymać. Około dwóch milionów razy, co dwie minuty przez siedem i pół roku, serwer pytał repozytorium, czy coś się zmieniło. Prawie zawsze nic się nie zmieniło.

Rachunek nigdy nie był problemem

O własnym hostingu zwykle spiera się na gruncie kosztów infrastruktury. Nie to zakończyło ten przypadek.

Zakończyło go to, że osoba, która znała ten system, poszła na urlop, a nikt inny nie wiedział, jakie są dostępy, trasy sieciowe ani gdzie właściwie co leży. Budowanie działało dalej, ale nikt nie potrafił pewnie niczego w nim zmienić. To jest ta pozycja, której brakuje w każdej wycenie budowy, jaką kiedykolwiek napisano: nie ile kosztuje utrzymanie, tylko ile kosztuje moment, w którym jedyna osoba trzymająca kontekst jest niedostępna.

Dziś wszystko leży w repozytorium. Kolega z zespołu może to przeczytać. Agent kodujący również, co okazało się ważniejsze, niż się spodziewaliśmy.

Ale przecież AI zbuduje to teraz w weekend

To pierwsze zastrzeżenie, jakie w 2026 roku zgłasza każdy zespół inżynierski, i jest uczciwe. Z miesiąca na miesiąc jest też coraz bardziej prawdziwe, a zespoły nie tylko o tym mówią, ale działają.

Retool, raport o budowaniu i kupowaniu opublikowany w 2026 roku, na podstawie badania 817 twórców przeprowadzonego pod koniec 2025 roku. Nieco ponad jedna trzecia badanych określiła się jako inżynierowie oprogramowania. Przeczytaj raport. Sprawdzono w sierpniu 2026.

Trend jest więc realny. Ale przyjrzyjcie się, jak ci sami twórcy opisują własną pracę, bo szczegóły podważają nagłówek:

• 72% używa AI do pisania pojedynczych fragmentów kodu, które sami wpinają w większy projekt.
• 31% dochodzi promptami do kompletnej aplikacji.
• 8% wdraża kod napisany przez AI bez zmian.
• 44% dokładnie testuje przed jakimkolwiek wdrożeniem.
• 26% wskazuje ciężar utrzymania jako przeszkodę organizacyjną.

Wygenerowany szkic nie jest produktem końcowym. Ktoś nadal go integruje, testuje, sprawdza pod kątem bezpieczeństwa i odpowiada za niego, gdy za osiemnaście miesięcy pęknie jakaś zależność. Sztuczna inteligencja zbiła koszt pierwszej wersji, a pierwsza wersja nigdy nie była tą drogą częścią. Nasz serwer budowania nie kosztował 7,6 roku uwagi dlatego, że napisanie pierwszego Jenkinsfile było trudne.

Ile naprawdę kosztuje pięć lat posiadania

Tu zespoły się mylą. Budowę się szacuje. Kolejnych czterech lat już nie.

Powszechnie przytaczane szacunki inżynierii oprogramowania umieszczają utrzymanie na poziomie 60% do 80% całkowitego kosztu życia systemu i mówią, że w całym okresie eksploatacji utrzymanie sumuje się do dwu- lub czterokrotności pierwotnej inwestycji. Liczby mocno różnią się w zależności od typu systemu, więc traktujcie je jako przedział, a nie prognozę, ale kierunek nie budzi sporu.

Wielkość zespołu ustala nachylenie. Czas ustala sumę, a tego kształtu zespoły sobie nie wyobrażają, gdy zatwierdzają pierwszą wersję:

Poglądowe sumy pięcioletnie przy 500 godzinach inżynierskich na osobę na pierwszą wersję, uśrednionej stawce $100 za godzinę i rocznym utrzymaniu na poziomie 25% kosztu budowy. Wszystkie założenia zmienisz w kalkulatorze budować czy kupić.

Dlaczego okres zwrotu nie istnieje

Typowe porównanie budować czy kupić zestawia jednorazową budowę z cyklicznym abonamentem. Dzielisz, dostajesz punkt wyjścia na zero w miesiącach i spierasz się o stopę dyskontową.

Ta arytmetyka wymaga abonamentu po drugiej stronie. Sandtime.io jest darmowy dla nieograniczonej liczby użytkowników i projektów, bez opłat za miejsca i bez blokad wymuszających wyższy plan. Podzielcie dowolny koszt budowy przez $0 zaoszczędzonych opłat licencyjnych, a nie znajdziecie punktu wyjścia na zero. Budowa nie zwraca się wolno. Ona się nie zwraca.

To nietypowe i jest to najmocniejszy argument na tej stronie. To także argument, który wyparowałby, gdyby zmienił się nasz cennik, co warto powiedzieć wprost zamiast ukrywać.

Do zbudowania czego naprawdę byście się zobowiązali

To nie jest lista hipotetyczna. To lista, przez którą przeszliśmy przez ponad 15 000 godzin inżynierskich, a każdy punkt jest tu dlatego, że trafił na niego prawdziwy użytkownik.

Każdy pojedynczy wiersz to jeden weekend. Lewa kolumna to to, co trafia do zakresu. Prawa to to, co ostatecznie zostaje dowiezione, po trzecim sporze o fakturę.

Kiedy budowanie naprawdę jest słuszne

Czasem jest, a tekst, który udawałby inaczej, nie byłby wart czytania. Oto przypadki, w których my też byśmy budowali.

Jeśli któryś z tych przypadków was dotyczy, budujcie. A potem wpiszcie do kalendarza datę sprawdzenia, czy nadal dotyczy. Rynki się wypełniają. Nasz wypełnił się w siedem lat, gdy nikt nie patrzył. Ten przegląd to krok, który prawie wszyscy pomijają, i to właśnie jego pominięcie zamienia dobrą decyzję w obciążenie.

Opcja, o której się zapomina: kup i zbuduj tę cienką część

Większość zespołów, które chcą budować, wcale nie chce stopera. Chcą jednego konkretnego raportu, własnej logiki rozliczeń albo pulpitu w kształcie swojego biznesu. To wszystko można mieć bez dziedziczenia błędów ze zmianą czasu.

REST API i serwer MCP są obecnie oznaczone jako wersja zapoznawcza dla deweloperów. Nie ma jeszcze opublikowanych limitów zapytań, polityki wersjonowania ani gwarancji poziomu usług, więc planujcie zmiany i trzymajcie eksporty w obiegu. To realne ograniczenie i warto je rozważyć, zanim powierzycie któremuś z tych interfejsów krytyczny proces.

Jeszcze jedno, jeśli działacie w Unii Europejskiej

Ewidencja czasu pracy nie jest tam wyłącznie wewnętrznym udogodnieniem. W sprawie CCOO przeciwko Deutsche Bank (C-55/18, 14 maja 2019) Trybunał Sprawiedliwości Unii Europejskiej orzekł, że państwa członkowskie muszą zobowiązać pracodawców do wprowadzenia obiektywnego, wiarygodnego i dostępnego systemu pozwalającego mierzyć dobowy czas pracy każdego pracownika.

Zbudujcie własne narzędzie, a ten obowiązek i każda jego przyszła zmiana staną się czymś, co wasz zespół utrzymuje i weryfikuje na nowo. To kontekst, a nie porada prawna, i Sandtime.io nie deklaruje certyfikowanej zgodności w żadnej jurysdykcji. Możecie przeczytać wyrok bezpośrednio.

Jak zdecydować w jedno popołudnie

Zadajcie trzy pytania, w tej kolejności.

1. Czy rejestracja czasu to coś, co sprzedajemy, czy coś, czego używamy? Jeśli sprzedajecie, przestańcie czytać. Jeśli używacie, czytajcie dalej.
2. Czy cokolwiek na rynku to rozwiązuje? W przypadku rejestracji czasu uczciwa odpowiedź brzmi: tak, i to od ponad dekady. W przypadku waszego naprawdę nietypowego problemu być może nie, i to jest realny powód, żeby budować.
3. Jeśli to zbudujemy, kto będzie za to odpowiadał w trzecim roku? Wskażcie osobę. Jeśli nie potraficie, właśnie znaleźliście tryb awarii, który wyłączył nasz serwer budowania.

Wniosek

Nie powiemy wam, że budowanie oprogramowania jest błędem. Zbudowaliśmy narzędzie do rejestracji czasu i stało się naszym produktem. Zbudowaliśmy własne CI i stało się obciążeniem. Wysiłek był podobny. Różnicą było to, czy ktoś inny rozwiązał już ten problem dobrze.

W przypadku rejestracji czasu pracy ktoś to zrobił. Kosztuje $0 dla nieograniczonej liczby użytkowników i możecie zacząć z tego korzystać dzisiaj, zamiast planować kick-off.