Dedykowane oprogramowanie czy gotowe — jak to rozstrzygnąć w firmie

Dedykowane oprogramowanie nie jest ani lepsze, ani gorsze od gotowego. Jest odpowiedzią na inne pytanie — i większość złych decyzji w tym temacie bierze się z tego, że firma zadaje je raz, dla wszystkiego naraz.

Tymczasem to pytanie rozstrzyga się osobno dla każdej funkcji. Poczta, księgowość czy kalendarz to zupełnie inna kategoria niż proces, który odróżnia Waszą firmę od konkurencji albo spina dane z kilku miejsc. W jednej firmie zwykle jest tak, że część narzędzi warto wynajmować przez lata, a jeden czy dwa elementy — zbudować.

Piszemy to z obu stron tej decyzji. Tworzymy oprogramowanie na zamówienie dla klientów, ale ta strona, którą czytacie, sama jest przykładem takiego podziału: część działa na usługach, za które płacimy abonament, a część napisaliśmy sami. Poniżej pokazujemy, co gdzie trafiło i dlaczego, a potem przekładamy to na kryteria, które możecie zastosować u siebie — z rachunkiem kosztu całkowitego na pięć lat i z tym, jak nie uzależnić się od dostawcy, niezależnie od tego, którą drogę wybierzecie.

Czym jest dedykowane oprogramowanie, a czym gotowe

Gotowe oprogramowanie to narzędzie, które już istnieje i jest sprzedawane wielu firmom naraz — najczęściej jako usługa w abonamencie (SaaS), czasem z licencją jednorazową. Logujecie się i korzystacie. CRM, system do fakturowania, narzędzie do rezerwacji wizyt, platforma sklepowa. O tym, jak się rozwija, decyduje dostawca, a Wy dostajecie to, co dostają wszyscy jego klienci.

Dedykowane oprogramowanie — nazywane też oprogramowaniem na zamówienie, a przy pojedynczych narzędziach po prostu aplikacjami dedykowanymi — to system budowany pod sposób działania jednej firmy. Może to być:

• system przyjmowania zamówień i śledzenia ich realizacji,
• aplikacja do planowania pracy ekip w terenie,
• panel klienta z historią współpracy,
• konfigurator produktu, który upraszcza sprzedaż nietypowych zamówień,
• mały moduł, który robi jedną rzecz, której żadne gotowe narzędzie nie robi tak, jak trzeba.

Między tymi biegunami są dwie drogi pośrednie, o których warto pamiętać od początku. Pierwsza to narzędzia low-code i automatyzacje (Make, Zapier, Airtable), które pozwalają skleić gotowe usługi bez pisania pełnego systemu. Druga to podejście hybrydowe: gotowe narzędzia do tego, co typowe, plus własny moduł tam, gdzie standard się kończy. Do obu wrócimy.

Jedna rzecz, o której oferty mówią rzadko: słowo „dedykowane” nie oznacza automatycznie „Wasze”. To, czy kod będzie należał do Was, zależy od umowy — i to jest osobna sekcja tego tekstu.

Jak sami podzieliliśmy to u siebie

Zaczynamy od własnego przypadku, bo tu znamy nie tylko wynik, ale i powody.

Z tej tabeli widać kryterium, które stosowaliśmy, choć nie od razu umieliśmy je nazwać: wynajmujemy to, co jest takie samo w każdej firmie, a budujemy tam, gdzie łączą się nasze własne dane i procesy. Kalendarz to towar. Ale moment, w którym ktoś rezerwuje rozmowę, jest dla nas częścią historii kontaktu: skąd przyszedł, co wcześniej policzył w kalkulatorze, z jakiej reklamy kliknął. Gotowe narzędzie do rezerwacji dałoby nam termin, a ten rekord trzeba by sklejać ręcznie.

Własny CRM — i czego w nim celowo nie zbudowaliśmy

Własny CRM przechowuje atrybucję — identyfikator kliknięcia reklamy, parametry kampanii, pierwszą i ostatnią wizytę — oraz zgody i ścieżkę usunięcia danych na żądanie. Z niego eksportujemy do Google Ads konwersje, które zdarzyły się poza stroną, na przykład telefon po kliknięciu reklamy. Tego połączenia nie dałoby się zrobić, gdyby dane o kontakcie leżały w cudzym systemie, a dane o kliknięciach — w naszym.

Równie pouczające jest to, czego nie zbudowaliśmy. Pierwsza wersja miała osobną warstwę firm — i wycofaliśmy ją, bo nic z niej nie korzystało. Wróciła dopiero wtedy, gdy synchronizacja skrzynek pocztowych zaczęła rozpoznawać firmę po domenie adresu e-mail, czyli gdy pojawił się realny powód. Oprogramowanie dedykowane kusi, żeby od razu zbudować wszystko, co może się przydać — i to jest najdroższy sposób, żeby z niego korzystać.

Decyzja, w której cena nie grała roli

Najciekawsza była decyzja o tym, jak podłączyć skrzynki pocztowe do CRM. Na rynku są firmy pośredniczące, które dają jedno API do Gmaila i Outlooka. Przy naszej skali ich abonament byłby pomijalny. Mimo to zbudowaliśmy połączenie sami, a w notatce z tej decyzji zapisaliśmy wprost: cena nigdy nie była argumentem. Argumentami były:

• pośrednik staje się podmiotem przetwarzającym korespondencję z klientami — z umową powierzenia, wpisem w polityce prywatności i, przy dostawcach spoza Unii, oceną transferu danych;
• zasięg dostępu — pośrednik trzyma klucz do całej skrzynki firmowej, z wycenami i negocjacjami, a nie do „trochę metadanych”;
• zależność od małego dostawcy na kluczowej ścieżce systemu;
• sufit na własną logikę — nasze reguły odsiewania automatycznych wiadomości opierają się na nagłówkach, które warstwa pośrednika może po prostu ukryć.

I jeden zapis, który uważamy za najważniejszy: warunek, przy którym decyzję trzeba otworzyć na nowo. Gdybyśmy kiedyś mieli synchronizować skrzynki klientów, a nie własne, każdy z tych argumentów odwraca się na korzyść pośrednika. Dobra decyzja „kupić czy zbudować” ma taki warunek zapisany od początku.

Kiedy gotowe oprogramowanie wystarczy — i jest lepszym wyborem

Gotowe narzędzia mają przewagę, której nic nie zastąpi: działają od razu, ktoś inny dba o aktualizacje, kopie zapasowe i bezpieczeństwo, a jeśli narzędzie się nie sprawdzi, zmieniacie je bez straty inwestycji. I wciąż jest wiele do zrobienia na samych gotowych systemach: według GUS w 2025 roku oprogramowania typu ERP używało 32,9% małych firm (10–49 pracujących), a CRM — 20,0%. Dwie trzecie małych firm nie korzysta więc nawet z gotowego ERP — zanim zaczniecie budować, sprawdźcie, czy nie brakuje Wam po prostu systemu z półki.

W trzech sytuacjach budowanie czegokolwiek własnego to po prostu zły ruch.

Jesteście na bardzo wczesnym etapie. Jeśli oferta zmienia się co kilka miesięcy, a model biznesowy jest jeszcze testowany, własny system zapisze w kodzie założenia, które za pół roku będą nieaktualne.

Wasz proces jest standardowy dla branży. Fakturowanie, prosty CRM, komunikacja w zespole, sprzedaż w typowym sklepie — rynek jest pełen narzędzi, które robią to dobrze i rozwijają się szybciej, niż jakakolwiek pojedyncza firma rozwijałaby własny odpowiednik.

Nie ma kto tego utrzymać, a procesy nie są wypracowane. Własny system potrzebuje opiekuna, w zespole albo u wykonawcy. A jeśli każdy w firmie robi tę samą rzecz trochę inaczej, najpierw trzeba to uporządkować — oprogramowanie na zamówienie utrwala proces, również zły.

W tych sytuacjach zamiast budowy lepiej sięgnąć po:

• zestaw prostych narzędzi: Notion, Google Workspace, Trello, ClickUp,
• automatyzacje, które spinają gotowe usługi: Zapier, Make, Airtable,
• gotowe systemy branżowe — CRM, ERP, systemy rezerwacji dla konkretnej branży,
• prototyp na formularzu i arkuszu, który pozwala sprawdzić przepływ, zanim ktokolwiek napisze linijkę kodu.

Ostatni punkt jest niedoceniany. Formularz zamówień połączony z arkuszem, używany przez kilka miesięcy, pokazuje, które kroki są naprawdę potrzebne, a które tylko wydawały się ważne na etapie planowania. Jeśli potem przyjdzie czas na budowę, zlecacie ją z wiedzą, a nie z przeczuciem.

Kiedy gotowe oprogramowanie przestaje wystarczać?

Gotowe oprogramowanie przestaje wystarczać wtedy, gdy więcej czasu i pieniędzy kosztuje obchodzenie jego ograniczeń niż samo korzystanie z niego. Najczęściej widać to po trzech objawach: ktoś ręcznie przepisuje dane między systemami, zespół prowadzi obok systemu arkusze z obejściami, a firma płaci za licencje i funkcje, których nie używa, bo potrzebnej nie ma w żadnym planie.

Rozpisując to na sygnały:

• te same dane wpisuje się w dwóch lub trzech miejscach — zamówienie w sklepie, potem w arkuszu, potem w systemie księgowym,
• zespół obchodzi system, bo proces nie pasuje do założeń narzędzia, i arkusze wracają „na wszelki wypadek”,
• płacicie za niewykorzystane licencje — wyższy plan kupiony dla jednej funkcji albo miejsca dla osób, które logują się raz w miesiącu,
• każdy dział wie co innego, bo sprzedaż pracuje w jednym narzędziu, realizacja w drugim, a klient pisze na trzecim kanale,
• nowy pomysł na usprawnienie odbija się od limitu narzędzia, a nie od budżetu czy czasu.

Typowy obraz to właściciel, który ma „wszystko ogarnięte”: CRM, fakturowanie, system zgłoszeń. Tyle że każde z tych narzędzi jest z innej bajki, jest kilka loginów i kilka miejsc, w których coś może umknąć, a on sam spędza więcej czasu na spinaniu systemów niż na prowadzeniu firmy. To nie jest argument za wyrzuceniem wszystkiego. To jest sygnał, że warto poszukać miejsca, gdzie dane się rozjeżdżają — i właśnie tam zwykle leży pierwszy kawałek, który opłaca się zbudować.

Cztery pytania, które rozstrzygają wybór

Zamiast ogólnego „czy potrzebujemy dedykowanego oprogramowania” zadajcie cztery pytania — osobno dla każdej funkcji, którą rozważacie.

Czy ten proces jest branżowy, czy Wasz?

Jeśli robicie coś tak, jak robi to cała branża, gotowe narzędzie prawie na pewno to obsłuży. Jeśli sposób, w jaki przyjmujecie zamówienie, wyceniacie nietypowy produkt albo obsługujecie klienta, jest tym, co Was wyróżnia — gotowe narzędzie zmusi Was do dopasowania się do przeciętnej. Sprawdzian jest prosty: czy klient zauważyłby różnicę, gdybyście robili to tak jak wszyscy? Jeśli nie, to proces branżowy.

Czy ta funkcja łączy dane z kilku miejsc?

To pytanie u nas rozstrzygało najczęściej. Jeśli funkcja żyje sama dla siebie, wynajmujcie. Jeśli jej wartość polega na tym, że łączy informacje z kilku miejsc — zamówienie z magazynem, lead z reklamą, zgłoszenie z historią klienta — to właśnie to połączenie jest kandydatem do budowy.

Ile będzie kosztował abonament przy zespole, jaki planujecie?

Większość gotowych narzędzi liczy opłatę od użytkownika albo od progu funkcji. Przy pięciu osobach to nieistotne, przy trzydziestu — już tak. Policzcie abonament dla zespołu, jaki planujecie za trzy lata, a nie dla tego, który macie dziś.

Kto to utrzyma — i co zabierzecie, odchodząc?

Własny system wymaga kogoś, kto dba o serwer, aktualizacje i bezpieczeństwo — w zespole albo u wykonawcy. Gotowy system wymaga planu wyjścia: w jakim formacie wyjmiecie dane i co zostanie po stronie dostawcy. Jeśli na to pytanie nikt w firmie nie umie odpowiedzieć, zanotujcie to jako ryzyko — wrócimy do niego przy vendor lock-in.

Jeśli po tych pytaniach nie macie pewności, sprawdźcie się w quizie „Gotowy SaaS czy własne oprogramowanie?”. Siedem pytań o przewagę konkurencyjną, budżet, czas, zespół i integracje prowadzi do jednej z kilku rekomendacji — od gotowego SaaS, przez SaaS z integracjami i podejście hybrydowe, po budowę.

Rachunek na pięć lat, czyli total cost of ownership (TCO)

Najczęstszy błąd w tej decyzji to porównywanie miesięcznego abonamentu z jednorazową ceną budowy. To dwie różne liczby, które opisują różne okresy. Porównywać trzeba total cost of ownership, w skrócie TCO — koszt całkowity posiadania, czyli wszystko, co wydacie na daną funkcję w tym samym horyzoncie, a nie tylko cenę na start.

Po stronie gotowego narzędzia na TCO składają się: abonament pomnożony przez liczbę użytkowników i miesięcy, dopłaty za wyższe plany i moduły, koszt automatyzacji, które łatają braki, oraz koszt wyjścia — przeniesienia danych, gdy narzędzie przestanie wystarczać.

Po stronie oprogramowania dedykowanego: budowa, a potem stałe utrzymanie — serwer, aktualizacje, poprawki — i rozwój, bo system, który ma służyć latami, będzie zmieniany.

720 zł miesięcznie, o których się zapomina

U nas stała część TCO własnej aplikacji webowej to 720 zł miesięcznie: 600 zł utrzymania i 120 zł serwera. W ofertach porównuje się zwykle cenę budowy, a te 720 zł pojawia się dopiero na pierwszej fakturze po wdrożeniu. W pięciu latach to 60 × 720 zł, czyli 43 200 zł — prawie tyle, ile kosztuje samo MVP. Obie pozycje policzycie dla siebie w kalkulatorze kosztu utrzymania.

Nasze ceny i ceny rynku

W naszym kalkulatorze kosztu aplikacji webowej punkt wyjścia dla MVP — pierwszej wersji z jedną kluczową ścieżką — to 50 000 zł, a dla pełnej aplikacji 145 000 zł. Każda integracja z zewnętrznym systemem (CRM, ERP, płatności) to co najmniej 8 000 zł. Rynek wygląda nieco inaczej: w naszym badaniu kosztów aplikacji webowych w Polsce, opartym na 118 obserwacjach, mediana wyceny MVP wynosi 30 000 zł (24 obserwacje), a dla dużych systemów z integracjami — 200 000 zł (43 obserwacje). Różnica mówi o zakresie, jaki różni wykonawcy mieszczą w słowie „MVP”, więc pytajcie o listę funkcji, a nie o nazwę pakietu.

Próg opłacalności

Najprostszy rachunek: koszt budowy podzielony przez miesięczną oszczędność, czyli różnicę między abonamentem a 720 zł utrzymania. Przy budowie za 50 000 zł (wydatek na abonamenty to założenie do podstawienia, nie dane rynkowe):

Dla porównania TCO własnego MVP w tych samych pięciu latach to 50 000 zł plus 43 200 zł, czyli 93 200 zł — bez rozwoju. Przy małym wydatku na abonamenty budowa praktycznie się nie zwraca, nawet jeśli wydaje się „inwestycją na lata”. Opłaca się dopiero wtedy, gdy abonamenty urosły razem z zespołem albo gdy chodzi o coś, czego gotowe narzędzie nie robi w ogóle.

Rachunek ma dwa uproszczenia. Zakłada, że własny system zastępuje całe narzędzie — w praktyce często tylko część. I pomija czas, który zespół odzyskuje, gdy przestaje przepisywać dane; tę wartość wyceniajcie osobno i ostrożnie. Skąd biorą się różnice w wycenach samej budowy, piszemy w tekście ile kosztuje stworzenie aplikacji.

Hybryda: gotowe tam, gdzie standard, własne tam, gdzie przewaga

W praktyce najczęściej wygrywa rozwiązanie pośrednie. Aplikacje dedykowane nie muszą niczego zastępować w całości: zostawiacie gotowe narzędzie do tego, co robi dobrze, a budujecie jeden moduł tam, gdzie standard się kończy. Całość łączycie przez API, automatyzację albo niewielką warstwę pośrednią.

Dwa przykłady z naszych rozmów z klientami. Firma szkoleniowa korzystała z gotowej platformy kursów, która dobrze obsługiwała materiały i płatności, ale nie wysyłała certyfikatów ani nie przypominała uczestnikom o zadaniach tak, jak tego potrzebowała. Zamiast zmieniać platformę, dobudowano mały moduł, który robił tylko te dwie rzeczy. Sklep na Shopify chciał, żeby każdy klient po zakupie dostawał spersonalizowany plan korzystania z produktu, przygotowany na podstawie krótkiego quizu. Powstała osobna usługa, która generowała taki plan w PDF i wysyłała go mailem — a reszta dalej działała na Shopify.

Nasz własny przypadek jest tego samego rodzaju. Poczta zostaje w abonamencie i jest źródłem prawdy o korespondencji — CRM pobiera z niej tylko metadane, krótki fragment i link do wiadomości, nigdy pełnej treści ani załączników. Kalendarz zostaje w Google, a nasz moduł tylko czyta wolne terminy i zapisuje nowe spotkania.

Hybryda ma największy sens, gdy budżet jest ograniczony, ale jeden proces nie jest obsługiwany dobrze przez nic; gdy chcecie sprawdzić jedną unikalną funkcję, zanim zbudujecie wokół niej więcej; i gdy problemem jest spięcie kilku narzędzi, a nie same narzędzia. W tym ostatnim przypadku zacznijcie od tekstu o automatyzacji procesów biznesowych — często automatyzacja rozwiązuje problem, zanim trzeba cokolwiek budować.

Kod, dane i wyjście — vendor lock-in w obie strony

Vendor lock-in to sytuacja, w której zmiana dostawcy kosztuje tyle, że praktycznie przestaje być możliwa. Zwykle mówi się o nim przy SaaS: dane są u dostawcy, eksport jest ubogi, a cennik rośnie. Tymczasem uzależnienie grozi po obu stronach tej decyzji. Różnica polega na tym, co Was chroni: przed dostawcą SaaS częściowo chroni prawo, przed wykonawcą oprogramowania na zamówienie — tylko umowa.

Od dostawcy SaaS chroni Was Data Act

Od 12 września 2025 roku stosuje się unijny Data Act, rozporządzenie 2023/2854 (art. 50). Obejmuje usługi przetwarzania danych, a motyw 81 wymienia wśród nich wprost oprogramowanie jako usługę (SaaS). Umowa z dostawcą ma zawierać między innymi:

• okres wypowiedzenia rozpoczynający zmianę dostawcy nie dłuższy niż dwa miesiące (art. 25 ust. 2 lit. d),
• okres przejściowy nie dłuższy niż 30 dni kalendarzowych, w którym umowa dalej obowiązuje, a dostawca pomaga w przeniesieniu (art. 25 ust. 2 lit. a),
• szczegółową specyfikację danych, które można przenieść, co najmniej wszystkich danych eksportowalnych (art. 25 ust. 2 lit. e).

Opłaty za samą zmianę dostawcy mogą do 12 stycznia 2027 roku być tylko obniżone, do kosztów dostawcy bezpośrednio związanych ze zmianą, a od tej daty znikają (art. 29). Wyjątek: zasada o opłatach nie dotyczy usług, których większość głównych cech opracowano na zamówienie jednego klienta i których dostawca nie oferuje szeroko z katalogu (art. 31 ust. 1). Jeśli więc system dedykowany jest Wam dostarczany jako usługa w chmurze wykonawcy, warunki wyjścia zapiszcie w umowie sami.

Od software house’u chroni Was tylko umowa

Według ustawy o prawie autorskim program komputerowy automatycznie należy do zamawiającego tylko wtedy, gdy napisał go pracownik w ramach obowiązków ze stosunku pracy (art. 74 ust. 3). Od zewnętrznego wykonawcy prawa same nie przechodzą. Przechodzą na podstawie umowy, która ma formę pisemną pod rygorem nieważności (art. 53) i wymienia wyraźnie pola eksploatacji, bo obejmuje tylko te, które są w niej wymienione (art. 41 ust. 2). Dla oprogramowania kluczowe pole to prawo do przystosowywania i wprowadzania zmian w programie (art. 74 ust. 4 pkt 2). Bez niego inny wykonawca nie może legalnie rozwijać Waszego systemu — i to jest vendor lock-in w czystej postaci, tylko po drugiej stronie.

Licencja na oprogramowanie czy przeniesienie praw

Jeśli umowa nie mówi wyraźnie o przeniesieniu praw, ustawa przyjmuje, że wykonawca udzielił licencji (art. 65). Licencja na oprogramowanie bez innych zapisów uprawnia do korzystania przez pięć lat, na terytorium kraju Waszej siedziby, a potem wygasa (art. 66). Licencję na czas nieoznaczony twórca może wypowiedzieć, w braku terminów umownych na rok naprzód, na koniec roku kalendarzowego (art. 68 ust. 1). Licencja wyłączna też wymaga formy pisemnej pod rygorem nieważności (art. 67 ust. 5).

Licencja nie musi być zła — bywa tańsza i wystarcza przy module, który ma działać, a nie się rozwijać. Ale wybierajcie ją świadomie. Żądajcie w umowie: przeniesienia praw albo licencji z wymienionymi polami eksploatacji i okresem, prawa do zmian, przekazania kodu źródłowego, dokumentacji i dostępów do repozytorium i serwerów. Biblioteki open source, na których stoi każdy system — nasz na przykład na Payload CMS, Next.js i React, na licencji MIT — zostają na swoich licencjach; wykonawca powinien umieć je wymienić.

Jak zacząć, jeśli wychodzi Wam budowa

Wybierzcie najmniejszy moduł, który łączy dane — jedną funkcję, która rozwiązuje najważniejszy problem, zamiast pełnego systemu. Najlepszy kandydat to zwykle miejsce, w którym dziś ktoś przepisuje dane ręcznie: tam efekt widać od pierwszego dnia, a ryzyko jest najmniejsze. Jak wyznaczyć taki zakres, piszemy w tekście o MVP aplikacji.

Spiszcie wymagania po ludzku i przetestujcie dwa lub trzy gotowe narzędzia. Lista tego, czego w nich brakuje, jest najlepszą specyfikacją dla wykonawcy.

Spiszcie wyjście w umowie, zanim zaczniecie. Prawa albo licencja, pola eksploatacji, kod źródłowy, dokumentacja — i warunek, przy którym wrócicie do decyzji.

Poproście o wycenę z listą wymagań, nie „ile kosztuje aplikacja”. Bez zakresu dostaniecie liczby, których nie da się porównać. Orientacyjny koszt policzycie w kalkulatorze aplikacji webowej, a cały proces opisujemy w tekście jak wygląda proces tworzenia aplikacji krok po kroku.

Jeśli szukacie wykonawcy, zobaczcie, jak tworzymy oprogramowanie na zamówienie dla firm — systemy wewnętrzne, integracje, panele klienta. A jeśli brakuje kogoś, kto weźmie odpowiedzialność za same decyzje, pomagamy w ramach doradztwa technologicznego.

Skąd te liczby

• Ceny budowy i utrzymania — nasze własne, z konfiguracji kalkulatorów kosztu aplikacji webowej i kosztu utrzymania, stan na 22 września 2026 roku; kalkulator podaje wynik z rozrzutem ±15%.
• Mediany rynku — nasze badanie kosztów aplikacji webowych w Polsce, edycja 2026: 118 obserwacji cenowych, liczba obserwacji podana przy każdej medianie.
• Próg opłacalności i TCO — arytmetyka na przyjętych wydatkach abonamentowych, opisanych w tekście jako założenia, nie dane rynkowe.
• Odsetek firm z ERP i CRM — GUS, „Społeczeństwo informacyjne w Polsce w 2025 r.”, przedsiębiorstwa małe (10–49 pracujących).
• Przepisy — ustawa o prawie autorskim i prawach pokrewnych (tekst jednolity Dz.U. 2025 poz. 24) oraz rozporządzenie (UE) 2023/2854, czytane u źródła 22 września 2026 roku.
• Nasz podział narzędzi — stan systemu, na którym działa ta strona, i notatki z decyzji projektowych.