Build vs. buy vs. blend: jak policzyć, czy custom software w ogóle ma sens

Rozsyłasz zapytanie o współpracę dot. stworzenia customowej aplikacji dla swojego biznesu. Większość firm odpowiada: „Tak, pewnie, zbudujemy wszystko tak jak w wysłanym przez was briefie”. Dobrze? No niekoniecznie. Mogą po prostu chcieć złapać jeszcze jednego klienta. Faktura będzie się zgadzała, a to, czy to, co zaprogramują, będzie miało ręce i nogi pod kątem biznesowym, to już nie ich problem.

Z drugiej strony, w obecnej erze AI wytwarzanie oprogramowania nigdy nie było tak tanie. No to może jednak opłaca się zlecić stworzenie tej customowej platformy mimo wszystko? W dłuższym horyzoncie własne oprogramowanie bywa tańsze niż niedopasowany SaaS. A dostawcy zewnętrzni podnoszą ceny z dnia na dzień, czasem o setki procent, więc nigdy nie wiadomo, ile zapłacisz za abonament za trzy lata.

Bądź tu mądry i pisz wiersze. Sens tego wstępu jest prosty: najważniejsze to pracować z dostawcą, który już na etapie pierwszych konsultacji szczerze powie ci, jakie rozwiązanie będzie dla ciebie najlepsze, i czy będzie to kup, zbuduj, czy połącz oba.

W tym artykule omawiamy plusy i minusy każdej z tych trzech dróg i wyjaśniamy, jak rozpoznać, która ma u ciebie sens.

Kup, zbuduj, połącz oba: trzy opcje

Gdyby decyzja o oprogramowaniu była prosta, nie mielibyśmy tego artykułu. Tyle że w realnym biznesie rzadko wybierasz między „wszystko z półki” a „wszystko od zera”. Gartner od lat opisuje to jako Buy / Build / Blend, i w większości firm właśnie ta trzecia opcja, czyli połączenie obu, zdarza się najczęściej.

Kup: kiedy gotowiec wygrywa

Payroll, wideokonferencje, podstawowe CRM: nikt nie wybiera cię jako klienta dlatego, że macie „elegancki SSO”. Tu sens ma gotowy produkt: szybko wchodzisz, ktoś inny utrzymuje infrastrukturę, a ty nie finansujesz wynajdywania na nowo koła, które rynek ma już dopracowane.

Minus? Gotowiec jest zrobiony pod uśredniony przypadek. Jeśli twój proces jest standardowy, to plus. Jeśli zmusza cię do zmiany tego, co działa, zaczynasz płacić podwójnie: abonamentem i pracą ludzi na obejściach.

Zbuduj: kiedy custom ma sens

Custom software ma sens, gdy proces jest twoją przewagą, a nie tylko narzędziem w tle. Gdy produkt cyfrowy to twój biznes, nie wewnętrzny Excel w ładniejszej skórce. Albo gdy regulacje, dane albo skala użytkowników sprawiają, że SaaS po prostu nie pasuje albo pasuje coraz gorzej z każdym rosnącym abonamentem.

Minus? Zbudowanie customowego oprogramowania to nie jednorazowy rachunek. Licz też utrzymanie w TCO (sekcja poniżej). Jeśli nie wiesz, kto będzie pilnował systemu za trzy lata, tania wycena dziś może zamienić się w drogie legacy jutro.

Połącz oba: najczęściej pomijana opcja

Tu właśnie często leży zdrowy kompromis. Kupujesz CRM albo ERP jako fundament, bo nie ma sensu pisać od zera tego, co rynek ma gotowe, i dokładasz cienką warstwę customowego kodu tam, gdzie standardowy produkt nie “ogarnia” twojego modelu: portal klienta, nietypowy obieg zamówienia, raport pod wymagania audytora.

McKinsey mówi na to „kup fundament, buduj to, co cię wyróżnia”. Prosty test: czy opisałbyś ten proces w ogłoszeniu o pracę jako „standard w branży”, czy „tak wygrywamy”? Standard → kup. Wygrana → zbuduj albo połącz oba.

Jak policzyć TCO, bo pierwsza wycena kłamie

Total Cost of Ownership (TCO) to odpowiedź na pytanie: ile naprawdę kosztuje nas to rozwiązanie przez cały czas, gdy z niego korzystamy, a nie ile kosztuje wdrożenie ani pierwsza faktura. Subskrypcja za 50 zł na użytkownika wygląda tanio w Excelu. Dopiero gdy dodasz liczbę użytkowników tej subskrypcji, podwyżki co rok, integrację z resztą stacku, godziny ludzi na obejściach i koszt migracji za trzy lata, widać pełny obraz.

W decyzji kup vs zbuduj TCO to jedyne porównanie, które ma sens. Wycena developmentu to jednorazowy koszt; abonament SaaS to koszt rozłożony w czasie. Porównujesz je sensownie tylko na wspólnym horyzoncie, zwykle pięciu latach, bo tyle trwa typowy cykl życia systemu w firmie, zanim zaczynasz poważnie rozważać zmianę albo przebudowę.

Przy „kup” policz: licencje × użytkownicy × 60 miesięcy, wdrożenie, szkolenia, integracje, ręczną pracę przy kopiowaniu danych między systemami i koszt migracji, gdy vendor podniesie ceny. Do „sticker price” subskrypcji dochodzi orientacyjnie 20–40% ukrytych kosztów.

Przy „zbuduj” policz: development (MVP to co innego niż produkcja) – gdy produkt jest budowany, gdy produkt jest gotowy – hosting i migrację w roku pierwszym, utrzymanie 15–25% rocznie przez kolejne lata, oraz infrastrukturę.

• Przykład: (100 użytkowników, pięć lat): SaaS po 200 USD/os./mies. może dać ~1,3 mln USD łącznie; personalizowane rozwiązanie z kosztem zbudowania ~300 tys. USD plus ~60 tys./rok utrzymania to ~590 tys. USD. Wychodzisz na zero po ok. 18–24 miesiącach, ale tylko jeśli development się uda i proces naprawdę wymaga własnego systemu.

Pytanie do CFO brzmi więc nie „ile kosztuje wycena”, tylko: ile kosztuje każda opcja, jeśli zostaniemy z nią pięć lat, włącznie z ludźmi, integracjami i utrzymaniem?

AI jest tańsze, ale nie rozwiązuje zasadniczego problemu

Łatwo wyciągnąć zły wniosek, że skoro AI przyspiesza kodowanie, to zawsze warto budować. Badania na tysiącach developerów pokazują ok. 26% więcej ukończonych zadań z asystentami AI; GitHub raportuje ok. 55% szybsze domykanie typowych zadań. W praktyce to, co kiedyś wymagało pół roku i sześciocyfrowego budżetu, dziś, przy wąskim zakresie, można zrobić w tygodniach albo kilku miesiącach. Stąd blend albo MVP coraz częściej wchodzą do rachunku obok rosnącego SaaS.

Tyle że szybsze kodowanie to nie to samo, co szybszy produkt. Dziś w tym samym oknie czasowym produkujemy cztero- do ośmiokrotnie więcej kodu niż kiedyś, więc decyzje biznesowe i architektoniczne są ważniejsze niż kiedykolwiek, a czasu na nie jest mniej. Błędną decyzję trudniej odwrócić: konsekwencje przychodzą szybciej, a cofanie ich, nawet z AI, kosztuje proporcjonalnie więcej pracy.

Tworzenie nowego produktu to ciągła eksploracja: stawiasz hipotezę, budujesz test, zbierasz dane. AI pozwala ten test szybko zaprogramować, ale walidacja trwa tyle samo co wcześniej. A w tym czasie? Kodujemy dalej, często w oparciu o hipotezy, które jeszcze nikomu nic nie udowodniły. Zanim zdążysz sprawdzić, czy własny moduł w ogóle ma sens, możesz już mieć trzy warstwy kodu do utrzymania albo wyrzucenia.

Do tego dochodzi jakość: demo z AI to nie produkt na pięć lat. PR-y wygenerowane z AI czekają dłużej na review: wąskie gardło przesunęło się z pisania na kontrolę. Według McKinsey State of AI 2025 ok. 88% organizacji używa AI w co najmniej jednej funkcji, ale tylko niewielki odsetek widzi z tego realny zwrot finansowy. Kod bez testów, code review i Definition of Done to ukryty dług, który wybucha za kilka miesięcy.

AI więc nie odpowiada na pytanie „kup czy zbuduj”. Pojawia się inna kwestia: Jak mieć pewność, że budujemy właściwą rzecz?

Pułapki, w które wpada większość firm

1. Buy-and-customize. Wygląda jak blend, ale zaczyna się inaczej. Kupujesz platformę SaaS, bo „prawie pasuje” do procesu. Gdy okazuje się, że nie pasuje wcale, dokupujesz customizacje u vendora albo jego partnera: dodatkowe moduły, konfiguracje, pluginy, obejścia. Płacisz abonament i osobno za każdą kolejną rundę dopasowań.

   Różnica względem blendu jest prosta. Blend planujesz z góry: gotowiec jako fundament tam, gdzie proces jest standardowy, a własny kod tylko tam, gdzie masz przewagę. Wiesz, co zostaje w SaaS, co budujesz, i zwykle jesteś właścicielem tej cienkiej warstwy. Buy-and-customize to reakcja na zły wybór: kupiłeś narzędzie pod proces, którego nie da się w nim sensownie odwzorować, i teraz płacisz za oba światy bez architektury. Customizacje siedzą wewnątrz cudzej platformy, więc przy każdej aktualizacji vendora mogą się psuć, a ty nie masz pełnej kontroli nad kodem.

   Syngnał, że wpadłeś w tę pułapkę: płacisz za licencję, a zespół i tak pracuje w Excelu albo ręcznie przenosi dane między systemami. Często taniej było od początku zrobić blend z własnym modułem albo zmienić proces pod gotowiec, ale nikt ci tego nie powie, bo na customizacji też zarabia się faktury.

2. SaaS, który rośnie szybciej niż biznes. Per-seat pricing, moduły premium, integracje. Abonament rośnie co rok, zespoł – niekoniecznie.

3. Development bez właściciela i metryki. Według Gartnera tylko 48% inicjatyw cyfrowych dowozi zakładany efekt biznesowy. Custom development bez jednej metryki sukcesu to droższy sposób na ten sam problem: dowieziesz funkcje, nie rozwiązanie. O tym, co warto mierzyć, budując produkty cyfrowe, pisaliśmy w jednym z poprzednim artykułów.

4. Budowanie personalizowanego systemu zamiast integracji. Excel jako baza, ręczne kopiowanie danych, pięć narzędzi bez połączeń: czasem problem leży w stacku, nie w braku własnej platformy. Zanim zlecisz development, sprawdź, czy wystarczy uporządkować to, co masz.

Kiedy odradzamy custom i dlaczego to normalne

U Pragmatic Coders na pierwszych konsultacjach rozmawiasz z konsultantami biznesowymi, którzy regularnie odradzają custom software. Nie dlatego, że nie chcemy projektu, tylko dlatego, że inna opcja jest dla ciebie tańsza, szybsza albo po prostu mądrzejsza.

To ten sam mechanizm, który opisujemy w artykule Dostawca, który mówi „nie”: większość rynku zarabia na podpisaniu umowy. My wolimy zacząć od uczciwej oceny, bo relacja, która zaczyna się od złej decyzji, i tak się nie utrzyma.

Typowe sytuacje, w których mówimy „nie budujcie custom”:

• Gotowiec ma to, czego szukacie. Połowa funkcji z briefu siedzi w ERP albo CRM, który i tak powinniście wdrożyć na wyższym poziomie. Zamiast budować od zera: wdrożenie i integracja.

• Matematyka się nie domyka. Automatyzacja dwóch osób w pięcioosobowym dziale kosztuje więcej niż oszczędność na pensjach.

• Pułapki z sekcji powyżej: integracja zamiast budowania, brak właściciela i metryki.

Kiedy custom ma sens: przykład z praktyki

Przy wąskim zakresie i sensownym discovery MVP może służyć do weryfikacji hipotezy, zanim wydasz sześć cyfr. W jednym z naszych projektów fintechowych inni dostawcy wyceniali pełną platformę na 2–15 mln USD. Po mapowaniu user stories zostawiliśmy ok. 10% zakresu. W ten sposób zbudowaliśmy prototyp za 80 tys. USD w trzy miesiące, który pomógł domknąć rundę finansowania. Warunek: wiesz, co budujesz i po co, i czekasz na wynik, zanim dokładasz kolejną warstwę.

O co zapytać dostawcę na pierwszej rozmowie

Dobry dostawca zada niewygodne pytania, zanim zaproponuje zespół. I powie wprost, gdy wygrywa gotowiec, nawet jeśli przyszedłeś po custom development.

Sprawdź, czy słyszysz coś z poniższej listy. Jeśli nie, pytaj sam:

1. „Czy w ogóle potrzebujemy custom, czy wystarczy gotowiec albo integracja?”

2. „Ile procent naszego procesu pokrywa najlepsze SaaS na rynku?”

3. „Jaki jest TCO na pięć lat dla kup vs zbuduj, włącznie z utrzymaniem i integracjami?”

4. „Kto utrzyma system za trzy lata?”

5. „Jaka jedna metryka biznesowa ma się poprawić w ciągu sześciu miesięcy?”

6. „Co proponujecie, jeśli po analizie okaże się, że custom nie ma sensu?”

Dostawca, który na wszystko odpowiada „zbudujemy”, testuje twój budżet. Dostawca, który mówi „najpierw policzmy”, traktuje cię jak partnera, nie jak kolejnego klienta w pipeline.

Podsumowanie

Większość firm powie „tak” do twojego briefu, bo na tym zarabia. Dostawca rozwiązania SaaS przekona cię, że abonament zawsze wygrywa, dopóki nie zobaczysz rachunku za trzeci rok.

Dlatego: Kup, gdy funkcja nie odróżnia cię od rynku. Połącz oba, gdy większość masz gotową, a reszta to przewaga. Zbuduj, gdy proces albo produkt jest tą przewagą i masz plan utrzymania.

Szukaj dostawcy, który wyjaśni ci wszystkie trzy warianty, zanim zaproponuje zespół. I takiego, który odradzi custom, gdy wygrywa gotowiec, bo to najsilniejszy sygnał, że traktuje twój budżet poważniej niż własny pipeline.

Zanim podpiszesz umowę: wiesz, czy w ogóle potrzebujesz custom software?

Checklista kondycji produktu to 25 pytań w pięciu obszarach: strategia, discovery, delivery, współpraca i odpowiedzialność. Przejdź przez nią przed rozmową z dostawcą i wejdź w nią z diagnozą, nie z listą funkcji.

Pobierz checklistę