Software house czy dedykowany system, a może gotowy program w abonamencie? Przed tym pytaniem staje prędzej czy później każda firma TSL, w której zlecenia, terminy floty i rozliczenia kierowców przestały mieścić się w arkuszach i kilku niepołączonych programach. Porównania tych dróg, które można znaleźć w sieci, piszą niemal wyłącznie firmy sprzedające jedną z nich. Z 35 wyników wyszukiwania, które przejrzeliśmy na potrzeby tego tekstu, co najmniej 33 pochodziło od software house’u, dostawcy gotowego systemu albo agencji.
RapidLogic buduje systemy trzecią z opisanych dróg, a poniższe porównanie opiera się na innym kryterium niż cena: każda z trzech dróg przerzuca na klienta inne ryzyko, a wybór polega na tym, które ryzyko firma potrafi unieść.
Kolejne sekcje odpowiadają na cztery pytania: ile kosztuje każda droga, jakie ryzyko niesie, co rozstrzyga o wyborze i co zapisać w umowie, niezależnie od tego, którą drogę wybierzesz.
Trzy drogi i ryzyko, które każda przenosi na klienta
Gotowy system w abonamencie (SaaS) to program, z którego korzysta wiele firm jednocześnie. Płacisz miesięczną opłatę, dostawca utrzymuje system i decyduje o jego rozwoju. Dopasowanie ogranicza się do ustawień, które przewidział producent.
System pisany przez software house powstaje od podstaw według Twojej specyfikacji. Płacisz za godziny pracy zespołu albo cenę ustaloną za opisany zakres. Dostajesz system dopasowany do procesów, a jego zakres, termin i własność kodu zależą od umowy.
System dedykowany na gotowej platformie z AI powstaje na platformie, która ma już gotowe moduły biznesowe, takie jak klienci, zamówienia, uprawnienia czy dziennik zmian. Wykonawca dopisuje brakującą część pod procesy firmy i korzysta przy tym z narzędzi AI do pisania i sprawdzania kodu. My budujemy w ten sposób na platformie Open Mercato.
Każda droga ma ryzyko w tych samych trzech obszarach, lecz za każdym razem innego rodzaju.
Ile kosztuje każda droga: rzędy wielkości ze źródłami
Ceny gotowych systemów dla transportu są częściowo jawne. Poniżej przykłady z cenników publicznych, sprawdzone w październiku 2026 roku. Nazwy produktów służą wyłącznie jako źródło ceny, a nie jako ocena produktu.
| Produkt | Cena | Jednostka | Start | Źródło |
|---|---|---|---|---|
| boxTMS | 199–1 799 zł netto/mies. | firma, według liczby zleceń | wdrożenie bezpłatne | cennik i FAQ |
| fireTMS | 89 / 160 / 219 € netto/mies. | pakiet z limitem użytkowników | umowa na 12 miesięcy | cennik, regulamin |
| TMS+ | 179 zł/mies. do 50 dokumentów | według liczby dokumentów | umowa bezterminowa | cennik |
| linkway.TMS | od 390 zł/mies. | pojazdy, użytkownicy, integracje | pełna wersja na zapytanie | strona produktu |
| SPEDTRANS Easy Start | od 2 400 zł netto | licencja na pierwszego użytkownika | 1 600 zł za kolejnego | strona produktu |
Ostatni wiersz pokazuje, że gotowy system nie zawsze oznacza abonament: część dostawców sprzedaje licencję wieczystą. Większe wdrożenia wszyscy wyceniają indywidualnie, więc górnej granicy kosztu gotowego systemu cenniki nie pokazują.
Software house’y cenników nie publikują. Stawki deklarowane na ich stronach mieszczą się w przedziale od 120 do 500 zł za godzinę, najczęściej od 150 do 400 zł. To deklaracje sprzedawców, a nie pomiar rynku: raportu z metodologią, który podawałby stawki dla klienta, nie znaleźliśmy. To samo dotyczy widełek kosztu projektu. Jedna z agencji szacuje prostą aplikację na 30–100 tys. zł i 2–6 miesięcy, a średnią na 100–350 tys. zł i 5–10 miesięcy. Inna, wyceniając dedykowany system TMS, podaje 40–80 tys. zł za wersję minimalną, 80–180 tys. zł za system bazowy i od 180 do ponad 400 tys. zł za pełny TMS. Do tego dochodzi utrzymanie, które sprzedawcy szacują zwykle na 15–20% kosztu wdrożenia rocznie.
Nasze projekty mieszczą się w przedziale od 20 do 150 tys. zł netto. Typowy system na start kosztuje 25–50 tys. zł netto i powstaje w jeden do dwóch miesięcy. Obejmuje podstawową platformę z główną funkcjonalnością, którą da się rozbudowywać o kolejne moduły.
Porównanie kosztu budowy z kosztem abonamentu wymaga przyjęcia okresu, liczby użytkowników i kosztu utrzymania, dlatego nie zestawiamy ich w jednej tabeli. Rachunek na kilka lat zależy od tego, ile osób będzie pracować w systemie i jak bardzo procesy firmy odbiegają od modelu gotowego programu. Taki rachunek na 36 miesięcy, z widełkami każdej pozycji, pokazujemy w tekście o tym, ile kosztuje system dla firmy transportowej.
Gotowy system w abonamencie: ryzyko dopasowania i decyzji dostawcy
Abonament wygrywa, gdy procesy firmy mieszczą się w modelu programu. Start nie wymaga projektu budowy, opłata jest przewidywalna, a utrzymanie, aktualizacje i zgodność z nowymi przepisami należą do dostawcy. Część producentów udostępnia okres próbny: fireTMS daje 14 dni. To najtańszy sposób, aby sprawdzić dopasowanie na własnych zleceniach, a nie na danych z prezentacji. Zanim wybierzesz gotowy system flotowy, sprawdź go na liście dwunastu funkcji z uzasadnieniem.
Ryzyko tej drogi dotyczy dwóch rzeczy, na które klient ma niewielki wpływ. Pierwsza to dopasowanie. Regulamin fireTMS (§ 4 ust. 4 pkt 3) zabrania klientowi wprowadzania jakichkolwiek innych zmian w oprogramowaniu, więc dopasowanie kończy się na konfiguracji. Jeżeli proces firmy nie mieści się w modelu programu, zmienia się proces albo powstaje obok niego arkusz.
Druga to decyzje dostawcy. Ten sam regulamin pozwala raz w roku podnieść opłaty o wskaźnik inflacji GUS bez zgody klienta (§ 7 ust. 9), przy czym umowa zawarta na czas określony utrzymuje dotychczasowy cennik do końca okresu. Cenniki zmieniają się także poza waloryzacją: Trans.eu wprowadził nowy cennik od czerwca 2026 roku, a giełda fireXgo, bezpłatna dla użytkowników fireTMS w 2026 roku, od 1 stycznia 2027 roku będzie kosztować 59 € netto miesięcznie. Zmienia się również właściciel dostawcy. Eurowag ogłosił w październiku 2022 roku przejęcie Inelo, producenta 4Trans i właściciela fireTMS, za ponad 300 mln €, a transakcję zamknięto w marcu 2023 roku. Przejęcie samo w sobie niczego nie przesądza, pokazuje jednak, że plan rozwoju programu, na którym pracuje firma, może zostać ustalony przez kogoś, kogo nie było przy podpisywaniu umowy.
Najmniej widoczny jest moment wyjścia. Regulamin fireTMS daje klientowi 365 dni od końca okresu rozliczeniowego na zalogowanie się, przejrzenie, pobranie i eksport danych, bez możliwości ich edycji (§ 13 ust. 4). Nie określa jednak formatu eksportu. Klauzul o wyjściu z danymi u pozostałych dostawców nie znaleźliśmy w materiałach publicznych, więc o format, termin i opłatę warto zapytać przed podpisaniem umowy.
Od września 2025 roku klienta chroni także unijne rozporządzenie o danych (Data Act, rozporządzenie 2023/2854). Jego przepisy o zmianie dostawcy usług przetwarzania danych obejmują również oprogramowanie w modelu SaaS. Okres wypowiedzenia na rozpoczęcie zmiany dostawcy nie może przekraczać dwóch miesięcy, okres przejściowy trwa najwyżej 30 dni, a po nim klient ma co najmniej 30 dni na pobranie danych (art. 25). Do 12 stycznia 2027 roku dostawca może pobierać za zmianę wyłącznie obniżone opłaty, nieprzekraczające kosztów bezpośrednio z nią związanych, a od tej daty nie może pobierać żadnych (art. 29). Rozporządzenie odróżnia przy tym opłaty za zmianę dostawcy od standardowych opłat za usługę i kar za wcześniejsze rozwiązanie umowy, o których dostawca musi poinformować przed jej zawarciem.
System pisany przez software house: ryzyko budżetu i własności kodu
Software house wygrywa, gdy zakres jest duży i złożony, gdy system ma być produktem sprzedawanym innym firmom albo gdy firma ma własny dział IT, który przejmie kod i będzie go rozwijać. Dostęp do szerokiej puli programistów znających popularne technologie oznacza też, że w razie potrzeby łatwiej zmienić wykonawcę.
Ryzyko budżetu zależy od modelu rozliczenia. W rozliczeniu godzinowym (time and material) ryzyko przekroczenia ponosi zamawiający: każda zmiana i każda nieprzewidziana trudność to kolejne godziny. W cenie stałej ryzyko przejmuje wykonawca, który wkalkulowuje je w cenę, a każda zmiana zakresu wymaga aneksu. Wariant pośredni, czyli cena stała z budżetem na zmiany, dzieli ryzyko między strony. Danych o tym, który model dominuje w projektach dla małych i średnich firm w Polsce, nie znaleźliśmy.
Statystyki przekroczeń budżetu w projektach IT są szeroko cytowane, lecz dotyczą innej skali niż system dla przewoźnika:
- Standish Group, CHAOS 2020: 31% projektów udanych, 50% zagrożonych, czyli dostarczonych z przekroczeniem budżetu, terminu albo z okrojonym zakresem, oraz 19% nieudanych. Raport jest płatny i nierecenzowany, a jego metodologię krytykowali m.in. Eveleens i Verhoef w recenzowanym artykule w IEEE Software (2010).
- McKinsey i Uniwersytet Oksfordzki (2012): ponad 5 400 projektów IT o budżecie powyżej 15 mln dolarów. Średnio 45% ponad budżet, 7% ponad czas i 56% mniej wartości niż planowano.
- Flyvbjerg i Budzier, Harvard Business Review (2011): 1 471 projektów IT, w 92% z sektora publicznego i w 83% z USA. Średnie przekroczenie kosztu wyniosło 27%, lecz co szósty projekt przekroczył koszt średnio o 200%, a harmonogram o prawie 70%.
Żadne z tych badań nie dotyczy projektu za kilkadziesiąt tysięcy złotych w polskiej firmie transportowej, a danych dla takiej skali nie znaleźliśmy. Badanie Flyvbjerga i Budziera pokazuje przy tym ryzyko ogona: średnie przekroczenie jest umiarkowane, lecz co szósty projekt przekracza budżet wielokrotnie. W modelu godzinowym ten koszt ponosi zamawiający.
Drugie ryzyko to własność kodu. Według ustawy o prawie autorskim i prawach pokrewnych (tekst jednolity Dz.U. 2025 poz. 24) umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności (art. 53) i obejmuje wyłącznie pola eksploatacji w niej wymienione (art. 41 ust. 2). W przypadku programu komputerowego wśród tych pól powinna znaleźć się zmiana i przystosowanie programu (art. 74 ust. 4), inaczej rozwój systemu przez innego wykonawcę staje się wątpliwy. Ustawa nie nakłada obowiązku wydania kodu źródłowego, więc wydanie kodu, dokumentacji i dostępów trzeba zapisać w umowie. Prawa do programu napisanego przez pracownika przysługują pracodawcy, natomiast programiści współpracujący z software house’em w formie B2B pracownikami nie są. Zamawiający powinien więc wymagać, aby wykonawca nabył prawa od swoich podwykonawców, zanim przeniesie je dalej. Pytania, które warto zadać software house’owi przed podpisaniem umowy, zebraliśmy w przewodniku AI software house: jak wybrać dostawcę.
System dedykowany na gotowej platformie z AI: ryzyko młodej platformy i młodej metody
Trzecia droga łączy cechy dwóch pozostałych. System powstaje pod procesy firmy, lecz nie od zera: platforma dostarcza moduły, które każdy system biznesowy i tak musi mieć. Open Mercato, na którym budujemy, ma ponad czterdzieści modułów, m.in. klientów, sprzedaż, magazyn, przewoźników, uprawnienia, powiadomienia i dzienniki audytowe. Przedmiotem projektu staje się dopasowanie i dopisanie brakującej części, a nie budowa fundamentów. Narzędzia AI przyspieszają pisanie, testowanie i przegląd tej części. Szerzej opisujemy to w tekście o AI-assisted engineering.
Ta droga wygrywa, gdy procesy firmy nie mieszczą się w gotowym programie, a budżet i czas klasycznego projektu są dla firmy za duże. Przegrywa w trzech sytuacjach. Gdy gotowy TMS obsługuje procesy firmy, abonament będzie tańszy i prostszy. Gdy firma potrzebuje możliwie szerokiej puli wykonawców, którzy przejmą system bez wdrażania się w platformę, bezpieczniejszy jest popularny stos technologiczny bez dodatkowej warstwy. Gdy system ma działać na platformie w wersji stabilnej 1.0 lub wyższej, Open Mercato tego warunku dziś nie spełnia.
Ryzyko platformy wynika z jej wieku. Repozytorium Open Mercato powstało we wrześniu 2025 roku, a ostatnie wydanie, oznaczone jako 0.9.0, ukazało się 9 października 2026 roku. Projekt ma 146 kontrybutorów i 37 wydań od listopada 2025 roku (stan na 15 października 2026 roku). Wersja przed 1.0 oznacza, że aktualizacje mogą wprowadzać zmiany niekompatybilne z wcześniejszymi. Platforma ma spisany kontrakt kompatybilności wstecznej, który to ryzyko ogranicza, lecz go nie usuwa. Rdzeń platformy jest na licencji MIT, która pozwala każdemu używać i modyfikować kod bez opłat i bez zgody autorów. Część funkcji, m.in. wybrane mechanizmy bezpieczeństwa, należy jednak do płatnego pakietu Enterprise na licencji komercyjnej. Jeżeli system z niego korzysta, firma jest związana subskrypcją u twórców platformy. Co zostaje po zakończeniu współpracy i ile kosztuje utrzymanie takiego systemu, opisaliśmy w tekście o stosie technologicznym Open Mercato.
Ryzyko metody dotyczy wpływu AI na tempo pracy. Niezależne pomiary są rozbieżne:
- METR (2025): randomizowane badanie kontrolowane na 16 doświadczonych programistach open source i 246 zadaniach w repozytoriach, które dobrze znali. Z narzędziami AI praca trwała o 19% dłużej. Przed badaniem uczestnicy oczekiwali przyspieszenia o 24%, a po badaniu ocenili, że byli szybsi o 20%. Badanie jest preprintem, a autorzy zastrzegają, że wynik nie opisuje większości sytuacji, w których powstaje oprogramowanie.
- Peng i współautorzy (2023): kontrolowany eksperyment na jednym zamkniętym zadaniu, czyli napisaniu serwera HTTP w JavaScript. Grupa z GitHub Copilot wykonała zadanie o 55,8% szybciej. Wśród autorów są badacze GitHub i Microsoftu, czyli producenta narzędzia.
- DORA 2025 (Google Cloud): ankieta wśród prawie 5 000 profesjonalistów. 90% używa AI w pracy, a wykorzystanie AI wiąże się z wyższą przepustowością dostarczania, lecz także z większą niestabilnością. 30% respondentów ma małe zaufanie albo nie ma go wcale do kodu wygenerowanego przez AI.
Danych o tym, jak AI zmienia koszt i czas całego projektu, łącznie z analizą, testami, odbiorem i utrzymaniem, nie znaleźliśmy. Własne liczby mamy z projektów zbudowanych innym stosem niż Open Mercato i bez grupy kontrolnej. Nasz system finansowy Forteca, zbudowany na AWS metodą AI-assisted engineering, powstał w 20–30 godzinach pracy jednej osoby, od specyfikacji do wdrożenia. Doświadczenie z logistyki pochodzi z systemów, w których zlecenia trafiają do kierowców: panel dyspozytora z rejonizacją zleceń i planowaniem tras oraz aplikacja kierowcy jako jego wycinek, oba w Tidly, a także system dostaw NutriBota, który rósł od listy w telefonie kierowcy do tras wyznaczanych algorytmem.
Ta droga ma jeszcze jedno ryzyko, wynikające z Data Act. Rozporządzenie wyłącza część obowiązków, w tym zakaz opłat za zmianę dostawcy, dla usług, których większość głównych funkcji zbudowano na potrzeby indywidualnego klienta (art. 31). System dedykowany hostowany przez wykonawcę może więc nie korzystać z ochrony, która obejmuje abonament. Warunki wyjścia trzeba wtedy zapisać w umowie.
Wielkość floty nie rozstrzyga wyboru. Rozstrzygają cztery pytania
Rada, że małej firmie wystarczy gotowy program, a dużej potrzebny jest system budowany na zamówienie, nie ma oparcia w źródłach. Nie znaleźliśmy żadnego, które wiązałoby wielkość floty z rodzajem oprogramowania i podawało jakiekolwiek progi. Cenniki gotowych systemów liczą zresztą co innego: zlecenia, dokumenty i użytkowników, a nie pojazdy. Struktura rynku też niewiele tu podpowiada. Na koniec 2025 roku licencję wspólnotową miały 43 924 polskie firmy, z czego 36 131, czyli ponad 82%, miało do dziesięciu pojazdów. Liczby firm z flotą od 20 do 200 pojazdów nie publikuje żadne źródło, do którego dotarliśmy.
Firma z 30 ciężarówkami i nietypowym rozliczeniem kierowców może potrzebować systemu budowanego pod siebie, a firma ze 150 pojazdami i standardowymi zleceniami spedycyjnymi może dobrze pracować w gotowym TMS. O wyborze decydują cztery pytania.
Czy procesy mieszczą się w gotowym systemie? Odpowiedź daje okres próbny na własnych zleceniach, a nie prezentacja. Jeżeli główne procesy przechodzą przez program bez arkusza obok, dalsze pytania tracą znaczenie.
Ile systemów trzeba połączyć? Giełda ładunków, telematyka, program księgowy, KSeF i aplikacja kierowcy. Gotowy TMS zwykle ma część tych integracji, na przykład fireTMS deklaruje współpracę z kilkudziesięcioma dostawcami telematyki. Gdy połączeń potrzeba więcej, niż program przewiduje, rośnie wartość systemu budowanego pod firmę.
Kto po stronie firmy prowadzi projekt? Każdy projekt budowy systemu wymaga osoby, która odbiera prace, zgłasza zmiany i pilnuje zakresu. Firma z działem IT może rozliczać software house godzinowo i sama pilnować zakresu. Firma bez działu IT potrzebuje wykonawcy, który przejmie także analizę i utrzymanie, albo gotowego programu.
Co ma zostać po rozstaniu z dostawcą? W abonamencie zostają dane w formacie, który określi regulamin. W software housie i na platformie zostaje to, co zapisze umowa. To pytanie dotyczy każdej drogi i prowadzi do ostatniej sekcji.
Co zapisać w umowie, niezależnie od drogi
| Droga | Zapis w umowie | Dlaczego |
|---|---|---|
| Abonament | format, termin i koszt eksportu danych po zakończeniu umowy | regulamin, który sprawdziliśmy, formatu nie określa |
| Abonament | zasady zmiany cennika i okres wypowiedzenia | waloryzacja bywa możliwa bez zgody klienta |
| Software house | przeniesienie praw na piśmie, z polami eksploatacji obejmującymi zmianę programu | bez tego dalszy rozwój przez inną firmę jest wątpliwy (art. 41, 53, 74 ustawy) |
| Software house | wydanie kodu źródłowego, dokumentacji i dostępów | ustawa tego nie wymaga |
| Software house | nabycie praw od podwykonawców | programiści na B2B nie są pracownikami wykonawcy |
| Platforma z AI | co działa na licencji MIT, co napisano dla Ciebie, czy system używa modułów Enterprise | od tego zależy, co jest Twoje i za co płacisz po wdrożeniu |
| Platforma z AI | hosting i warunki wyjścia | Data Act może nie obejmować systemu szytego na miarę (art. 31) |
| Każda | zakres praw do kodu wygenerowanego przez AI | kod wygenerowany wyłącznie przez AI ma status wątpliwy |
Ostatni wiersz dotyczy dziś każdej drogi, ponieważ narzędzi AI używają także software house’y i producenci gotowych systemów. Ustawa chroni przejaw działalności twórczej (art. 1 ust. 1), co wiąże ochronę z człowiekiem, dlatego kod wygenerowany wyłącznie przez AI ma status wątpliwy. Polskiego orzeczenia w tej sprawie nie znaleźliśmy. Amerykański U.S. Copyright Office stwierdził w raporcie ze stycznia 2025 roku, że w tamtej jurysdykcji ochrona przysługuje tylko elementom, których ekspresję określił człowiek. Umowa może przenieść prawa w takim zakresie, w jakim istnieją, zobowiązać wykonawcę do ujawnienia narzędzi AI i do gwarancji, że kod nie narusza praw osób trzecich. Nie stworzy natomiast ochrony tam, gdzie prawo jej nie daje. Zapisy umowy warto przed podpisaniem pokazać prawnikowi.
Pytania, które wracają
Czy mała firma transportowa potrzebuje systemu dedykowanego? Zwykle nie. Jeżeli procesy mieszczą się w gotowym programie, abonament będzie tańszy. System budowany pod firmę ma sens wtedy, gdy obok gotowego programu powstają arkusze na procesy, których program nie obsługuje, a takich procesów jest więcej niż kilka.
Czy gotowy TMS da się połączyć z własnym systemem? Tak, jeżeli TMS udostępnia interfejs API. Publicznej dokumentacji API z warunkami dostępu nie znaleźliśmy u żadnego z dostawców, których materiały przejrzeliśmy, dlatego o API, jego zakres i koszt warto zapytać przed podpisaniem umowy.
Ile kosztuje system dedykowany w RapidLogic? Nasze projekty mieszczą się w przedziale od 20 do 150 tys. zł netto. Typowy system na start kosztuje 25–50 tys. zł netto i powstaje w jeden do dwóch miesięcy.
Czy od dostawcy SaaS można odejść bez opłat? Od 12 stycznia 2027 roku dostawca usług objętych Data Act nie może pobierać opłat za zmianę dostawcy. Do tej daty może pobierać tylko obniżone opłaty, nieprzekraczające kosztów bezpośrednio związanych ze zmianą. Rozporządzenie odróżnia je od standardowych opłat za usługę i kar za wcześniejsze rozwiązanie umowy, o których dostawca musi poinformować przed jej zawarciem, dlatego warunki wypowiedzenia warto sprawdzić przed podpisaniem.
Kto jest właścicielem kodu napisanego z pomocą AI? Kod, w którym człowiek określił architekturę, decyzje i ostateczną postać, jest chroniony na zwykłych zasadach. Kod wygenerowany wyłącznie przez AI ma status wątpliwy, a polskie sądy tej kwestii nie rozstrzygnęły. Umowa powinna przenosić prawa do kodu w takim zakresie, w jakim istnieją, oraz zobowiązywać wykonawcę do gwarancji, że kod nie narusza praw osób trzecich.
Od czego zacząć
Od listy procesów, które dziś obsługuje arkusz albo pamięć jednej osoby, i od okresu próbnego gotowego programu na własnych zleceniach. Jeżeli próba wypadnie dobrze, abonament jest najprostszą drogą. Jeżeli obok programu od razu powstaje arkusz, lista procesów, które się w nim nie zmieściły, jest gotowym zakresem systemu budowanego pod firmę. Jak przenieść do niego dane i reguły z arkuszy, opisaliśmy w tekście o wychodzeniu z Excela w zarządzaniu flotą.
Sprawdź, która droga pasuje do procesów Twojej firmy
Bezpłatny audyt cyfrowy kończy się diagnozą procesów, nie ofertą. Pokazuje, które procesy mieszczą się w gotowym systemie, a które wymagają systemu budowanego pod firmę.
Umów bezpłatny audyt →