Ile naprawdę kosztuje własne narzędzie do rejestracji czasu pracy

Byliśmy po obu stronach tej decyzji. Zbudowaliśmy narzędzie do rejestracji czasu i zostawiliśmy je. Hostowaliśmy własny serwer budowania przez 7,6 roku i wyłączyliśmy go w 2026 roku. Oto jak rozpoznać, z którym przypadkiem macie do czynienia.

Budowa własnego narzędzia do rejestracji czasu miała sens, gdy rynek nie miał odpowiedzi. Teraz ją ma i kosztuje $0 dla nieograniczonej liczby użytkowników, więc nie ma abonamentu, który wasza budowa miałaby zwrócić.

  • Sztuczna inteligencja zbiła koszt pierwszej wersji. Pierwsza wersja nigdy nie była tą drogą częścią.
  • Publikowane szacunki umieszczają utrzymanie między 60% a 90% całkowitego kosztu narzędzia w całym cyklu jego życia.
  • W kilku konkretnych przypadkach budowanie wciąż jest słuszne, a są one wymienione niżej.

Za darmo dla nieograniczonej liczby użytkowników. Bez limitu stanowisk, bez blokad wymuszających wyższy plan i z osobną ofertą dla zarejestrowanych organizacji non-profit.

Ale przecież AI zbuduje to w weekend

To zastrzeżenie jest słuszne i z każdym miesiącem coraz bardziej prawdziwe. Zespoły już według niego działają: w badaniu Retool z 2026 roku o budowie kontra zakupie, obejmującym 817 osób budujących oprogramowanie, ponad jedna trzecia zastąpiła już jakieś narzędzie SaaS czymś, co napisała sama.

35%zastąpiło już co najmniej jedno narzędzie SaaS własnym rozwiązaniem
78%planuje zbudować więcej własnych narzędzi w 2026 roku
51%zbudowało oprogramowanie produkcyjne, z którego ich zespół korzysta dziś
60%zbudowało coś poza nadzorem działu IT w ciągu ostatniego roku

Przyjrzyjcie się teraz, jak ci sami twórcy naprawdę pracują. 72% używa AI do pisania pojedynczych fragmentów kodu, które sami wpinają w większy projekt, a tylko 31% dochodzi promptami do kompletnej aplikacji. Zaledwie 8% wdraża kod napisany przez AI bez zmian, a 26% wskazało ciężar utrzymania jako przeszkodę organizacyjną.

Wygenerowany szkic nie jest więc produktem końcowym. Ktoś nadal odpowiada za testy, przegląd bezpieczeństwa, aktualizacje zależności i każdy przypadek brzegowy wymieniony niżej na tej stronie. Sztuczna inteligencja zbiła koszt pierwszej wersji. Pierwsza wersja nigdy nie była tą drogą częścią.

Retool, raport o budowie kontra zakupie, opublikowany w 2026 roku, na podstawie badania 817 osób budujących oprogramowanie, przeprowadzonego pod koniec 2025 roku. Sprawdzono w sierpniu 2026.

Po siedmiu latach wyłączyliśmy własny serwer budowania

7,6lat własnego hostingu CI

Nasz serwer Jenkins działał od 3 stycznia 2019 roku, aż wyłączyliśmy go 10 sierpnia 2026 roku. Był niezawodny, był nasz, a zastąpienie go usługą hostowaną było pod koniec ewidentnie słuszną decyzją.

2776dni na posterunku
15 648zbudowanych commitów
858wydań produkcyjnych Sandtime.io
~2 mlnodpytań repozytorium, co dwie minuty

Odpytywanie działało co dwie minuty przez siedem i pół roku, w większości po to, żeby stwierdzić, że nic się nie zmieniło.

To, co ostatecznie go pogrzebało, nie było rachunkiem za hosting. 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. To jest ten koszt, którego nikt nie wpisuje do wyceny budowy. Dziś wszystko leży w repozytorium, gdzie kolega z zespołu albo agent kodujący może to po prostu przeczytać.

A mimo to własny hosting był w 2019 roku słuszną decyzją. GitHub Actions jeszcze nie istniał. Hostowane CI dopiero raczkowało. Decyzja była trafna, gdy ją podejmowaliśmy, i błędna, gdy ją kończyliśmy, bo rynek w międzyczasie wypełnił lukę.

To jest ta część warta zapamiętania. Decyzja o budowaniu nie jest wieczna. Ma datę ważności, a prawie nikt nie planuje jej przeglądu. Rynek rejestracji czasu pracy wypełnił się ponad dekadę temu.

Dane z naszego własnego serwera budowania, opublikowane w sierpniu 2026. Zobacz oryginalny wpis

Liczby mówią prawdę

Narzędzia wewnętrzne to większe i dłuższe zobowiązanie, niż większość zespołów wycenia.

33%
czasu inżynierów idzie na budowę narzędzi wewnętrznych
45%
w firmach zatrudniających 5000 lub więcej osób
60-90%
kosztu życia oprogramowania to utrzymanie, a nie pierwsza budowa
15,000+
godzin inżynierskich zainwestowanych w Sandtime.io do tej pory
Nasze własne wyliczenie

Przedział kosztów utrzymania zbiera wieloletnie szacunki z inżynierii oprogramowania, które mocno różnią się w zależności od typu systemu, więc traktuj go jako przedział, a nie prognozę dla waszego kodu. Sprawdzono w sierpniu 2026.

Pięć lat posiadania kontra $0

Budowę zespoły potrafią oszacować. Kolejnych czterech lat już nie.

$0$100k$200k$300kRok 1Rok 2Rok 3Rok 4Rok 5Trzech inżynierów buduje to narzędzieSandtime.io

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. Założenia możesz zmienić poniżej.

Ile kosztowałoby to Twój zespół?

Zmień wartości, aby oszacować, ile naprawdę kosztuje zbudowanie, a potem utrzymanie narzędzia do rejestracji czasu pracy.

Budowa w pierwszym roku$150 000
Utrzymanie, kolejnych lat: 4$150 000
Całkowity koszt posiadania$300 000
Sandtime.io w tym samym okresie$0
Okres zwrotu: nigdy. Alternatywa jest już darmowa.

Zakłada 500 godzin inżynierskich na osobę na pierwszą wersję, a potem roczne utrzymanie wyceniane jako część tego kosztu. Nie obejmuje projektowania produktu, QA, DevOps, przeglądu bezpieczeństwa ani kosztu pracy, której ci inżynierowie w zamian nie wykonali.

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

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

Strefy czasowe i zmiana czasu

Stoper uruchomiony przed zmianą czasu i zatrzymany po niej wciąż musi pokazać właściwy czas trwania, w strefie, w której pracuje dana osoba.

Stawki zmieniające się w czasie

Gdy zmienia się stawka kosztowa albo rozliczeniowa, raporty z zeszłego kwartału muszą nadal używać stawki obowiązującej wtedy, a nie nowej.

Wykrywanie nakładania

Dwa wpisy obejmujące te same minuty po cichu zawyżą fakturę, o ile coś nie wychwyci konfliktu w chwili jego powstania.

Proces zatwierdzania

Przesyłanie, zatwierdzanie, odrzucanie, przypomnienia, blokowanie minionych okresów, tymczasowe odblokowania i zapis tego, kto o co wnioskował i kto to rozpatrzył.

Role i widoczność

Kto może widzieć czyje godziny, komu wyświetlają się które projekty i co może zatwierdzić menedżer. Każda odpowiedź to gdzieś sprawdzenie uprawnień.

Wiele walut

Stawki w różnych walutach dla różnych klientów, raportowane obok kosztów, bez zamieniania każdego raportu w spór o przeliczniki.

Wyciągnięcie danych z powrotem

Eksporty do Excela i CSV, które dział finansowy naprawdę przyjmie, w formie, jakiej oczekują już płace i fakturowanie.

Wszędzie tam, gdzie ludzie rejestrują czas

Aplikacje desktopowe, mobilne, rozszerzenie do przeglądarki, integracja ze Slackiem, REST API i serwer MCP. Każde z nich to osobny proces wydawniczy.

Każdy z tych punktów to jeden weekend. Razem to 15 000 godzin.

Wiemy, bo sami przez to przeszliśmy

Sandtime.io zaczął jako narzędzie wewnętrzne. Zespół potrzebował rejestrować czas na projektach i klientach, nie zgodził się na oprogramowanie nadzorujące i pomyślał to, co myślą wszyscy: jakie to może być trudne?

Na tyle trudne, że stało się produktem. Miesiące pracy, a potem prośby o funkcje, poprawki błędów, aplikacje mobilne, przeliczanie walut, integracja ze Slackiem, rozszerzenie do przeglądarki. Ponad 15 000 godzin inżynierskich później jesteśmy z tego dumni.

Właśnie dlatego jest darmowy. Nasze dwa narzędzia wewnętrzne poszły w przeciwnych kierunkach: rejestrator czasu stał się produktem, a serwer budowania stał się obciążeniem. Różnicą nigdy nie był wysiłek. Różnicą było to, czy ktoś inny rozwiązał to już dobrze.

Ukryte koszty budowania własnych narzędzi

Pierwsze wdrożenie to dopiero początek. Oto co zespoły często pomijają.

Rozwój

Projekt, architektura, kodowanie, testy i wdrożenie. To, co zaczyna się jako prosty stoper, szybko staje się projektem z przypadkami brzegowymi, których nikt nie ujął w zakresie.

Konserwacja

Poprawki błędów, łatki bezpieczeństwa, aktualizacje zależności, zgodność przeglądarek i wydania mobilne. Po pierwszej wersji ta praca już się nie kończy.

Koszt alternatywny

Każda godzina inżynierska poświęcona na narzędzia wewnętrzne to godzina nie poświęcona na Twój główny produkt. Twoi konkurenci nie budują własnych systemów śledzenia czasu.

Czynnik autobusu

Szkolenie nowych osób, pisanie dokumentacji i utrzymanie ciągłości, gdy twórcy odchodzą. Narzędzia wewnętrzne po cichu stają się długiem organizacyjnym.

Zbudować czy kupić, w skrócie

Śledzenie czasu to już rozwiązany problem. Twój czas inżynierski jest warty więcej gdzie indziej.

Budowanie wewnętrznie

  • Miesiące, zanim będzie naprawdę używalne
  • Ciągłe prośby o nowe funkcje od własnego zespołu
  • Poprawki błędów przychodzą jako pilne zgłoszenia od własnego zespołu
  • Ludzie, którzy to zbudowali, odchodzą i zabierają kontekst ze sobą
  • Brak aplikacji mobilnych, rozszerzeń przeglądarki ani integracji
  • Przegląd bezpieczeństwa i ochrona danych spadają w całości na was

Sandtime.io

  • Zacznij śledzić czas w minuty, nie miesiące
  • Nowe funkcje przychodzą bez waszego własnego wydania
  • Inżynierowie zostają przy pracy, która zarabia
  • Dokumentacja i wsparcie od ludzi już istnieją
  • Desktop, mobile, rozszerzenie do przeglądarki i Slack w komplecie
  • Bezpieczeństwo i ochrona danych to czyjaś praca na pełen etat

Kryterium po kryterium

Jest trzecia opcja, o której się zapomina: kup narzędzie i zbuduj tylko tę warstwę, która naprawdę jest wasza.

Kryterium decyzjiZbudować samodzielnieUżyć Sandtime.ioUżyć i rozszerzyć
Czas do używalnej wersjiMiesiąceMinutyMinuty, plus wasza własna warstwa na wierzchu
Koszt w pierwszym rokuWynagrodzenia inżynierów$0Tylko ta część, którą wybraliście do zbudowania
Koszt w piątym rokuWynagrodzenia inżynierów, ponownie$0Tylko ta część, którą wybraliście do zbudowania
Kto naprawia błąd ze zmianą czasuWasz zespół, kosztem tego, co robi w zamianMyMy, dla wszystkiego pod API
Kto odpowiada za przegląd bezpieczeństwaWasz zespółMyWspólnie, z podziałem na granicy API
Gdy odchodzi osoba, która to zbudowałaNarzędzie przestaje być czyjąkolwiek pracąNic się nie zmieniaTylko wasza własna warstwa potrzebuje opiekuna
Pasuje do procesu, którego nie ma nikt innyDokładnie to, co określiliścieTo, co obsługuje produktWasz proces na naszych danych

Kiedy budowanie naprawdę jest słuszne

Czasem jest. Oto przypadki, w których my też byśmy budowali.

Rejestracja czasu jest tym, co sprzedajecie

Jeśli sprzedajecie rejestrację czasu, to nie jest narzędzie wewnętrzne. To wasz produkt, a wszystko na tej stronie jest waszą mapą drogową, a nie kosztem ogólnym.

Ten proces to wasza prawdziwa przewaga

Jeśli sposób, w jaki rejestrujecie pracę, jest naprawdę tym, za co płacą klienci, gotowe narzędzie zetrze wam tę przewagę.

Twarde wymagania co do miejsca przechowywania danych

Sieci odizolowane i ścisłe wymogi co do lokalizacji danych to realne ograniczenia. Jeśli żaden dostawca ich nie spełnia, decyzja już zapadła.

Trafia do waszego produktu

Jeśli rejestracja czasu ma żyć wewnątrz oprogramowania, które dostarczacie swoim klientom, budujecie funkcję, a nie wdrażacie narzędzie.

Rynek nie ma jeszcze odpowiedzi

Własny hosting CI w 2019 roku był słuszny, bo GitHub Actions nie istniał. Gdy rynek nie ma odpowiedzi, budowanie jest jedyną odpowiedzią.

Jeśli któryś z tych przypadków was dotyczy, budujcie. A potem wpiszcie do kalendarza datę sprawdzenia, czy nadal dotyczy, bo ten przegląd to krok, który prawie wszyscy pomijają.

Pytania o budowanie i kupowanie

Czy taniej zbudować, czy kupić narzędzie do rejestracji czasu pracy?

Kupno wygrywa tu z nietypowego powodu: Sandtime.io jest darmowy dla nieograniczonej liczby użytkowników, więc nie ma abonamentu, który budowa miałaby zwrócić. W typowym porównaniu zestawiasz jednorazową budowę z cyklicznymi opłatami licencyjnymi. Przy $0 budowa nigdy się nie zwraca.

Czy AI może nam teraz po prostu zbudować narzędzie do rejestracji czasu?

Potrafi szybko napisać działający licznik i to jest realna nowość. Nie zmienia to jednak tego, kto odpowiada za testy, przegląd bezpieczeństwa, aktualizacje zależności i przypadki brzegowe, które pojawią się później. W badaniu Retool z 2026 roku tylko 8% zespołów wdrożyło kod napisany przez AI bez zmian, a 72% używało go do pojedynczych fragmentów, które same integrowały.

Ile trwa zbudowanie narzędzia do rejestracji czasu pracy?

Prosty stoper to kwestia dni. Narzędzie, z którego dział finansowy wystawi fakturę, zajmuje znacznie dłużej, bo najtrudniejsze są zmiany czasu, stawki historyczne, nakładające się wpisy, zatwierdzenia i eksporty, a nie sam stoper. Sandtime.io pochłonął dotąd ponad 15 000 godzin inżynierskich.

Co jest najtrudniejsze w budowaniu rejestracji czasu pracy?

Poprawność w czasie. Stoper obejmujący zmianę czasu, stawka zmieniona w marcu, która nie może przepisać raportów z lutego, i dwa wpisy na te same minuty - każdy z nich łatwo popsuć i drogo odkryć dopiero na fakturze.

Kiedy budowanie własnego narzędzia naprawdę ma sens?

Gdy rejestracja czasu jest produktem, który sprzedajecie, gdy sam proces jest waszą przewagą konkurencyjną, gdy wymogi co do lokalizacji danych nie zostawiają żadnego dostawcy, gdy musi trafić do waszego własnego produktu albo gdy rynek naprawdę nie ma jeszcze odpowiedzi. Poza tymi przypadkami rynek wypełnił się dawno temu.

Czy Sandtime.io naprawdę jest darmowe dla nieograniczonej liczby użytkowników?

Tak. Działający produkt jest darmowy dla nieograniczonej liczby użytkowników i projektów, bez opłat za stanowiska, bez karty kredytowej i bez blokad wymuszających wyższy plan. Zarejestrowane organizacje non-profit mogą otrzymać osobną ofertę.

Czy możemy używać Sandtime.io i mimo to zbudować własną warstwę na wierzchu?

Tak i często jest to właściwa odpowiedź. Rejestrujcie czas w Sandtime.io, odczytujcie zapisy przez REST API lub serwer MCP i budujcie tylko tę warstwę, która jest specyficzna dla was. Żaden z tych interfejsów nie ma jeszcze opublikowanej polityki wersjonowania, więc planujcie zmiany i miejcie eksporty pod ręką.