Budować czy kupić oprogramowanie enterprise: Neutralny framework (z 12-punktową rubryką oceny, 2026)

Budować czy kupić oprogramowanie enterprise: Neutralny framework (z 12-punktową rubryką oceny, 2026)

We wrześniu zeszłego roku klient SaaS z ARR 50M USD zadał nam pytanie, na które błędna odpowiedź kosztuje firmy miliony: zostać na kolejne pięć lat przy stacku Salesforce + Tableau + Outreach za 487K USD, czy zbudować własną platformę revenue-ops za 312K USD? „Taniejsza" odpowiedź była błędna. Oto framework, którego użyliśmy, żeby to ustalić: 12-punktowa rubryka oceny, model TCO na 5 lat i trójpodział Buy/Build/Blend od Gartnera, którego żaden z top-10 poradników build-vs-buy w Google nie raczy nawet nazwać. I tak, jesteśmy agencją inżynieryjną, więc powiemy wam, kiedy kupić SaaS zamiast nas zatrudniać.

Kluczowe wnioski (TL;DR):

• Większość porad build-vs-buy pochodzi od vendorów, którzy zarabiają na jednej odpowiedzi. Nazwij stronniczość źródła, zanim mu zaufasz.
• Framework Buy/Build/Blend Gartnera obejmuje dziś 76% wydatków na oprogramowanie enterprise. Czyste build lub czyste buy to w 2026 roku mniejszość.
• Oceniaj decyzję na 12 ważonych kryteriach, nie na przeczuciu. Custom build wygrywa przy wyniku >45; SaaS wygrywa poniżej 30.
• Agenty AI do kodowania (Cursor, Claude Code) skracają czas senior inżyniera na funkcję o 40–60% w 2026 roku. Matematyka builda się zmieniła.

Czym jest decyzja Build vs Buy w oprogramowaniu enterprise?

Decyzja build vs buy to wybór między licencjonowaniem istniejącego oprogramowania SaaS lub COTS (buy), tworzeniem własnego oprogramowania in-house (build) albo zleceniem agencji partnerskiej budowy dedykowanego oprogramowania (partner). Gartner rozszerza to do modelu Buy/Build/Blend, a 76% wydatków na oprogramowanie enterprise trafia dziś do kombinacji standardowych produktów i dedykowanych rozszerzeń, nie do czystego build ani czystego buy.

Decyzja sprowadza się do trzech pytań:

• Czy dana funkcjonalność jest przewagą konkurencyjną, czy towarem?
• Jaki jest真实ny 5-letni TCO każdej ścieżki?
• Czy jesteś w stanie utrzymać zespół senior inżynierów, który będzie to rozwijał długoterminowo?

Uwaga: Techsy jest agencją inżynieryjną. Zarabiamy, kiedy budujesz. Dlatego powiemy ci wszystkie przypadki, w których powinieneś kupić SaaS i nas nie zatrudniać, bo długoterminowo takie teksty działają tylko wtedy, gdy matematyka jest uczciwa. Na dole wskazaliśmy nasz cel lejka; wszystko pomiędzy to framework, nie pitch.

Większość poradników build-vs-buy piszą ludzie, którzy zarabiają na jednej z dwóch odpowiedzi. Marketplace'y SaaS chcą, żebyś kupował. Agencje dev chcą, żebyś budował. Vendorzy COTS chcą, żebyś robił cokolwiek chroni ich odnowienie. Przeczytaj trzy, a dostaniesz trzy pewne siebie, sprzeczne rekomendacje, każda zakopana pod haczykiem sprzedażowym. Jeśli oceniasz konkretnie build voice-AI, napisaliśmy pionową wersję tego frameworka, która stosuje tę samą logikę do węższej decyzji. Reszta tego tekstu to ogólny framework procurementowy, który realnie przeprowadzisz na spotkaniu.

Co naprawdę mówi Gartner: Framework Buy / Build / Blend

Framework procurementowy Gartnera odrzuca binarną kwestię build-vs-buy i zastępuje ją decyzją trójstronną: Buy (licencjonowanie COTS lub SaaS), Build (wewnętrzna development dedykowany) lub Blend (połączenie SaaS dla commodity workflows z dedykowanym kodem dla zróżnicowanych procesów). Według modelu Buy/Build/Blend Gartnera, 76% wydatków na oprogramowanie enterprise trafia dziś do blended stacków. Czyste build lub czyste buy to mniejszość.

Buy = Licencjonuj to, co jest commodity

Kupuj, gdy funkcjonalność jest rozwiązanym problemem i ktoś już dostarczył rozwiązanie na skalę. CRM, payroll, email, zarządzanie wydatkami, observability. Ekonomia kupowania jest najlepsza, gdy masz <100 użytkowników na danym workflow, potrzebujesz go w <90 dni, a SaaS rozwiązuje >80% twoich potrzeb out of the box.

Build = Posiadaj to, co jest zróżnicowane

Buduj, gdy funkcjonalność jest twoją fosą. Tym, za co klienci ci płacą. Stripe nie licencjonował stacku płatności. Figma nie licencjonowała silnika renderowania. Build wygrywa też, gdy SaaS dosłownie nie jest w stanie zamodelować twojej struktury danych (pomyśl o złożonej wielopodmiotowej finansowości albo nietypowych reżimach compliance) albo gdy twój 5-letni rachunek SaaS na skalę przekracza TCO custom build o 2x lub więcej.

Blend = Matematyka, na której ląduje większość firm

Blend oznacza, że trzymasz COTS dla nudnych 80% i budujesz dedykowane 20%. Klasyczny wzorzec: Salesforce jako system of record + cienka warstwa custom dla workflow, których Salesforce nie umie zamodelować. Thoughtworks nazywa to Buy/Build/Partner; Gartner nazywa to Buy/Build/Blend. Ten sam pomysł, nieco inne słownictwo. Trójpodział sięga do Make-or-Buy Matrix McKinseya z lat 90., ale era chmury uczyniła trzecią opcję dominującą.

12-punktowa rubryka oceny (Skopiuj to do arkusza)

Oceń każde kryterium 1–5 w zależności od tego, jak mocno pasuje do twojej sytuacji. Pomnóż przez wagę. Zsumuj. Legenda progów na dole mówi, którą ścieżkę wskazuje matematyka. Użyj tego na realnym spotkaniu procurementowym, a skrócisz debatę z dwóch godzin do dwudziestu minut.

Legenda progów:

• Suma <30 → Kup SaaS
• Suma 30–45 → Blend
• Suma >45 → Build

Przykład z życia, na naszym kliencie z case study (tym, którego szczegółowo omawiamy w H2 #8): uzyskali 38 punktów. Przewaga konkurencyjna na 3 (revenue ops jest ważne, ale nie jest ich fosą), zespół na 2 (nie mogli dedykować inżynierów długoterminowo), luka pokrycia SaaS na 4 (Salesforce nie pokrywał ok. jednej trzeciej ich workflow), redukcja kosztu przez AI na 5. Wynik: solidnie w strefie Blend, i tam wylądowała rekomendacja.

Jedno zastrzeżenie. Rubryka to narzędzie wspierające decyzję, nie decydent. Jeśli twój wynik jest graniczny (28–32 lub 43–47), uruchom model TCO z następnej sekcji, zanim się zobowiążesz. Liczby przesuwają werdykt.

Modelowanie TCO: Jak uczciwie policzyć 5-letni koszt

Według badań Gartnera nad analizą kosztów oprogramowania, firmy pomijają 50–70% TCO przy kalkulacji własności oprogramowania. Najczęściej pomijane pozycje: integracja, FTE administracyjne i koszt wyjścia. Cena z pierwszego roku to najmniejsza część rachunku, a prawie każde demo vendora podaje ci dokładnie tę liczbę.

Oto jak uczciwie policzyć 5-letni TCO dla każdej ścieżki.

Pozycje Buy (SaaS): licencja × użytkownicy × lata, wdrożenie i konfiguracja, szkolenia, alokacja FTE administracyjnych (typowo 0,5–2 FTE na skalę enterprise), integracja z istniejącymi systemami i koszt wyjścia, gdy w końcu migrujesz.

Pozycje Build (Custom): inżynieria początkowa (miesiące inżynierskie × pełna stawka loaded), utrzymanie rocznie (branżowa reguła: 15–20% początkowego kosztu build), infrastruktura i narzędzia oraz koszt alternatywny mocy inżynieryjnej, którą angażujesz.

Pozycje Blend: subskrypcja SaaS dla warstwy commodity, plus koszt dedykowanej integracji/rozszerzenia, plus utrzymanie warstwy custom. Niższy koszt początkowy niż pełny build, niższy koszt bieżący niż pełny buy.

Przyjmij 230K USD jako pełny koszt inżyniera na wybrzeżu USA: mediana BLS wynosiła 130 160 USD w maju 2024, dodaj ~30% na benefity i ~25% na overhead. Skoryguj ±30% dla swojej geografii. Zespoły europejskie typowo wychodzą 20–30% taniej; zespoły poza wybrzeżem USA 15–20% taniej.

Generyczne zakresy ilustracyjne. Twoje liczby będą inne; kategorie nie.

Kiedy BLEND (Środkowa ścieżka, którą wybiera większość firm)

Blend wygrywa, gdy ani czyste buy, ani czyste build nie mapuje się czysto na twój workflow. Trzymasz COTS dla warstw commodity (CRM, billing, tożsamość, observability) i budujesz dedykowanie dla workflow, które są albo twoją przewagą konkurencyjną, albo po prostu niemożliwe do zamodelowania w SaaS. Klejem między nimi są API, serwery MCP lub silniki workflow low-code.

Cztery konkretne wzorce blend, które widzimy regularnie:

1. Salesforce + dedykowana warstwa RevOps. Salesforce zostaje jako system of record. Warstwa custom obsługuje wieloetapowe workflow revenue, których process builder Salesforce nie zamodeluje czysto. Case study klienta poniżej to dokładnie ten wzorzec.
2. SAP/NetSuite + dedykowana warstwa danych. Trzymasz ERP dla księgi głównej i procurementu. Budujesz hurtownię + dedykowane dashboardy dla analiz finansowych, których twój CFO naprawdę potrzebuje.
3. HubSpot + dedykowany pipeline enrichment. Używasz HubSpot do sekwencji i CRM, ale budujesz własny enrichment, gdy vendorzy danych komercyjnych nie są wystarczająco dokładni dla twojego ICP.
4. COTS HR + dedykowana automatyzacja workflow. BambooHR lub Rippling na rekordy, n8n lub dedykowany kod na orkiestrację onboardingu + offboardingu, której nikt dobrze nie pakuje.

Blend stał się istotnie tańszy w 2026, bo dodawanie funkcji AI inkrementalnie do istniejącego SaaS nie wymaga już zespołu badawczego, a serwery MCP pozwalające zszywać SaaS i kod dedykowany kompresują podatek integracyjny, który historycznie czynił blend drogim. Blend to nie kompromis. To odpowiedź dla 76% firm, według Gartnera.

Kiedy BUDOWAĆ (3 scenariusze, w których custom wygrywa)

Build wygrywa w trzech jasnych scenariuszach. Jeśli żaden nie opisuje twojej sytuacji, prawdopodobnie nie powinieneś budować.

1. Funkcjonalność jest twoją przewagą konkurencyjną

Jeśli klienci kupują cię ze względu na tę konkretną funkcjonalność, nie możesz jej licencjonować od vendora, którego inni klienci są twoją konkurencją. Stripe nie licencjonował stacku płatności. Notion nie licencjonował silnika dokumentów. Funkcjonalność musi być fosą, nie tylko featurem, którego akurat używasz.

2. SaaS nie zamodeluje twojej unikalnej struktury danych

Jeśli twoje dane mają strukturę, której istniejący SaaS dosłownie nie jest w stanie reprezentować (złożona wielopodmiotowa finansowość, nietypowe schematy regulacyjne, stan multiplayer w czasie rzeczywistym), wydasz więcej na opłaty za customizację i godziny konsultingowe niż na build od zera. Przetestuj to, zlecając dwóm vendorom SaaS płatne POC. Jeśli oba zawiodą — buduj.

3. 5-letni TCO SaaS przekracza custom build o 2x+

Matematyka się odwraca przy wolumenie. 500 użytkowników na SaaS za 200 USD/miejsce/mies. = 1,2M USD/rok = 6M USD w 5 lat. Skoncentrowany custom build dla tego samego workflow może wynieść 400K USD początkowo + 80K USD/rok utrzymania = 800K USD w 5 lat. Gdy wielokrotność to 2x lub więcej i workflow jest stabilny — buduj.

Uczciwe ostrzeżenie o ryzyku: build oznacza posiadanie ryzyka projektowego. Raport CHAOS Standish Group pokazuje, że 69% projektów IT kończy się częściowym lub całkowitym niepowodzeniem. Build nie jest darmowy, nawet gdy matematyka tak mówi. Mityguj dyscypliną zakresu, realnym product ownership i wczesnym MVP. Dla wewnętrznych narzędzi AI konkretnie, self-hosted enterprise AI tooling to wzorzec build, który widzimy działający w 2026, gdy gotowe opcje nie spełniają wymogów rezydencji danych.

Kiedy KUPOWAĆ (I ukryte koszty, o których nikt nie mówi)

Buy wygrywa, gdy funkcjonalność jest commodity, potrzebujesz jej szybko, a SaaS rozwiązuje większość twoich potrzeb out of the box. Trzy scenariusze:

1. Funkcjonalność jest commodity

CRM, email, księgowość, observability, tożsamość, zarządzanie wydatkami. To rozwiązane problemy. Vendorzy SaaS dostarczyli tysiące edge case'ów, które inaczej sam byś odkrył. Budowanie czegokolwiek z tego od zera w 2026 jest prawie zawsze błędem.

2. Potrzebujesz tego w <90 dni

Jeśli workflow blokuje revenue i nie masz wolnej mocy inżynieryjnej — kupuj. Koszt alternatywny 6-miesięcznego build vs 6-tygodniowego wdrożenia SaaS przytłacza opłatę licencyjną w prawie każdym przypadku.

3. SaaS rozwiązuje >80% out of the box

Jeśli dług customizacji ostatnich 20% kosztuje mniej niż całkowita premia SaaS — po prostu kup. Przetestuj to, spisując listę luk przed podpisaniem. Jeśli luki są lekkie workflowowo (ustawienia, integracje, lekki reporting) — jest OK. Jeśli są ciężkie workflowowo — nie jest.

Ukryte koszty, których nikt nie kładzie na slajdzie demo:

Ceny SaaS pełzają. Zylo 2025 SaaS Management Index pokazuje, że przeciętne enterprise marnuje ok. 21M USD rocznie na nieużywane lub zduplikowane miejsca SaaS. Opłata licencyjna to pierwszy koszt, nie całkowity.

Przykład z życia: Pomogliśmy klientowi SaaS z ARR 50M zdecydować — stack Salesforce za 487K vs custom build za 312K

W Q3 2025 klient B2B SaaS z ARR 50M USD zapytał nas, czy rozszerzać istniejący stack Salesforce + Tableau + Outreach (szacowany 5-letni TCO 487K USD), czy budować dedykowaną platformę revenue-ops na Next.js + Postgres + własnym narzędziu pipeline (szacowany 5-letni TCO 312K USD). Oto rzeczywista matematyka pozycja po pozycji, którą z nimi przeszliśmy, dlaczego „tańsza" opcja za 312K była dla nich błędna i co zamiast tego dostarczyli.

Nagłówkowe pytanie wyglądało binarnie: dalej płacić premie SaaS czy zbudować coś tańszego. Pozycje kosztowe opowiedziały inną historię.

Na papierze build wygrywał o 175K USD. Rekomendacja poszła w drugą stronę.

Dlaczego „tańszy" custom build był dla nich błędny: nie mieli zespołu senior inżynierów, który mógłby wchłonąć 0,5 FTE utrzymania na czas nieokreślony. Organizacja inżynieryjna już dostarczała core produktu. Alokacja 10–15% mocy seniorów na utrzymanie revenue-ops przez kolejne pięć lat oznaczała albo spowolnienie roadmapy produktu, albo rekrutację (co podbiłoby realny TCO Build powyżej 800K USD, gdy uwzględnisz rzeczywiste rekrutacje po stawkach rynkowych, nie wchłoniętą moc). „Tania" liczba zakładała darmowych inżynierów. Inżynierowie nigdy nie są darmowi.

Co faktycznie dostarczyliśmy: Blend. Salesforce zostaje jako system of record. Cienka warstwa custom revenue-ops (85K USD początkowo, niemal zero bieżąco) dla 4 workflow, których Salesforce nie zamodelował czysto. Netto 5-letni TCO wylądował na ~420K USD, między dwiema nagłówkowymi liczbami, i dostali workflow, których faktycznie potrzebowali. Dostarczone w 11 tygodni, bez nowych rekrutacji, bez poślizgu roadmapy.

18 miesięcy później: warstwa custom wciąż na produkcji, odnowienia Salesforce przeszły bez dramatu, a zespół inżynieryjny nie musiał wracać kontekstem do utrzymania RevOps po początkowym buildzie. Werdykt netto: Blend był właściwą odpowiedzią, bo respektował ograniczenie zespołu inżynieryjnego, które matematyka Build zignorowała.

Liczby zanonimizowane i zaokrąglone zgodnie z naszą umową konsultingową. Koszty zakładają okno 2025–2030. Ceny Salesforce odzwierciedlają podwyżki listy po sierpniu 2025. Zyski produktywności agentów AI do kodowania (bazowa Q3 2025) już wliczone w szacunek inżynieryjny 312K USD. Fully-loaded inżyniera na 230K USD = mediana wybrzeża USA wg BLS 2024 + 30% benefity + 25% overhead, skoryguj ±30% dla swojej geografii. Jesteśmy agencją inżynieryjną. To była realna rekomendacja wbrew naszym własnym interesom komercyjnym.

Jak AI zmieniło matematykę Build vs Buy w 2026

Punkt przecięcia się przesunął. Agenty AI do kodowania skompresowały godziny senior inżyniera na funkcję o 40–60% w naszych wewnętrznych pomiarach z pracy klienckiej w 2026. Oznacza to, że szacunek build, który zrobiłeś w 2023, jest teraz istotnie błędny. Gartner prognozuje, że 75% inżynierów oprogramowania enterprise będzie używać asystentów kodu AI do 2028, w górę z 10% w 2023, a nasze dane pipeline już odzwierciedlają większość tej adopcji przed harmonogramem.

Trzy konkretne przesunięcia:

• 18-miesięczne custom build dostarczane są teraz w 6–8 miesięcy, gdy zakres jest stały. Blend z case study powyżej dostarczono w 11 tygodni; ten sam zakres w 2023 zająłby 18–20 tygodni.
• Rozmiar zespołu dla narzędzi wewnętrznych spadł. Rutynowo prowadzimy 2-osobowe pody inżynierskie dla buildów, które dwa lata temu wymagały 5 inżynierów, bo agenty AI do kodowania jak Cursor i Claude Code wchłaniają boilerplate, który kiedyś pochłaniał moc mid-level.
• Szacunek build klienta z case study na 312K USD był o ok. 30% niższy niż ten sam szacunek w 2023, zanim AI-native enterprise software development stał się domyślnym trybem pracy.

Uczciwy kontrapunkt: AI obniża koszt build, ale obniża też koszt, który vendorzy SaaS płacą za dostarczanie funkcji. Presja cenowa vendorów jest realna, niektóre ceny SaaS spadną, a przesunięcie punktu przecięcia nie jest całkowicie jednostronne. Efekt kierunkowy wciąż sprzyja build (szczególnie Blend), bo wewnętrzna przepustowość inżynieryjna kumuluje się z AI szybciej niż ceny vendorów.

Typowe pułapki decyzyjne (Fałszywa oszczędność, koszt utopiony, syndrom NIH, optymizm vendor)

Cztery pułapki, które widzimy regularnie wykolejające decyzję:

1. Fałszywa oszczędność. Wybór tańszej liczby z roku 1 przy ignorowaniu 5-letniego TCO. Case study powyżej prawie tak poszło. Cena z pierwszego roku to najmniejsza część rachunku na każdej ścieżce.
2. Koszt utopiony. Trwanie przy SaaS, z którego wyrosłeś, bo migracja wygląda drogo. Migracja jest zwykle tańsza niż kolejne 3 lata z niewłaściwym narzędziem. Policz to.
3. Syndrom NIH (Not Invented Here). Budowanie rzeczy, które powinno się kupić, bo zespół inżynieryjny uważa problem za interesujący. CRM nie jest interesujący. Procesor płatności nie jest interesujący. Kup je.
4. Optymizm vendor. Wiara, że każda linijka demo vendora zadziała w twoim środowisku bez podatku integracyjnego. Demo to najlepszy przypadek. Twój przypadek jest trudniejszy. Dyskontuj demo o 30% przed porównaniem.

Najdroższy błąd, który widzimy: wybór tańszej liczby z roku 1 i ignorowanie 5-letniego kosztu wyjścia.

Jak Techsy podchodzi do ocen Build-vs-Buy

Techsy dostarcza dedykowane platformy enterprise, integruje SaaS z istniejącymi stackami i robi technical due diligence dla ocen COTS dla klientów B2B. Praca dzieli się mniej więcej 40/30/30 między te trzy.

Ocena build-vs-buy w Techsy wygląda tak: godzinna rozmowa discovery na scope workflow, przechodzimy z tobą na żywo przez 12-punktową rubrykę na wspólnym arkuszu, dostarczamy model TCO w tydzień i wysyłamy pisemną rekomendację, która może powiedzieć „kup SaaS, nie zatrudniaj nas". Nasze ostatnie 3 oceny: 1 zarekomendowała build, 1 buy, 1 blend. Nie mamy limitu. Jeśli myślisz szerzej o szerszej transformacji AI enterprise, ocena jest zwykle właściwym punktem startu. Umów bezpłatną 30-minutową ocenę build-vs-buy.

Najczęściej zadawane pytania

Jaka jest różnica między build, buy i partner w oprogramowaniu?

Buy oznacza licencjonowanie istniejącego oprogramowania SaaS lub COTS. Build oznacza tworzenie dedykowanego oprogramowania in-house z własnymi inżynierami. Partner oznacza wynajęcie agencji lub kontraktora do zbudowania własnościowego oprogramowania, które posiadasz. Gartner przekształca to w Buy/Build/Blend, gdzie Blend łączy licencjonowane COTS dla commodity workflows z dedykowanym kodem dla zróżnicowanych, co obejmuje dziś 76% wydatków na oprogramowanie enterprise.

Kiedy powinieneś budować oprogramowanie zamiast kupować?

Buduj, gdy spełnione są trzy warunki: funkcjonalność jest przewagą konkurencyjną, za którą klienci cię kupują, masz zespół senior inżynierów, który utrzyma to przez 5+ lat bez spowalniania roadmapy, a 5-letni TCO SaaS przy twojej liczbie użytkowników przekracza TCO custom build co najmniej 2x. Jeśli brakuje któregokolwiek z trzech, blend lub buy prawie zawsze wygrywa na uczciwej matematyce.

Kiedy kupowanie SaaS jest tańsze niż budowanie dedykowanego oprogramowania w 5 lat?

Buy wygrywa na TCO, gdy masz mniej niż ~100 użytkowników na danym workflow, funkcjonalność jest commodity (CRM, email, księgowość, observability) i potrzebujesz tego w mniej niż 90 dni. Poniżej tych progów subskrypcja SaaS, nawet z rocznymi podwyżkami, wychodzi niżej niż fully-loaded inżynieria plus utrzymanie plus infrastruktura plus koszt alternatywny.

Co Gartner mówi o build vs buy?

Gartner odrzuca binarne ujęcie i stosuje trójstronny model Buy/Build/Blend. Ich dane pokazują, że 76% wydatków na oprogramowanie enterprise trafia dziś do blended stacków (licencjonowane COTS plus dedykowane rozszerzenia), nie do czystego build lub czystego buy. Gartner raportuje też, że firmy pomijają 50–70% prawdziwego TCO w początkowych kalkulacjach, głównie na pozycjach integracji, alokacji FTE administracyjnych i kosztu wyjścia.

Czy build vs buy jest martwe?

Binarne ujęcie jest martwe. Trójstronna decyzja nie. Nazywanie pytania „build vs buy" przesłania fakt, że większość firm kończy na blend: SaaS dla commodity workflows, custom dla zróżnicowanych, klej pomiędzy. Decyzja żyje i jest trudniejsza niż wygląda, bo teraz wybierasz punkt podziału, nie jedną stronę. Ujmij to jako Buy/Build/Blend, a matematyka staje się czystsza.

Jak kodowanie AI (Cursor, Claude Code) zmienia matematykę build vs buy w 2026?

Agenty AI do kodowania jak Cursor i Claude Code skracają godziny senior inżyniera na funkcję o 40–60% w naszych pomiarach z 2026 na buildach klienckich. To przesuwa punkt przecięcia: buildy, które nie spinały się w 2023, teraz się spinają. Gartner prognozuje, że 75% inżynierów oprogramowania enterprise będzie używać asystentów kodu AI do 2028, więc to przesunięcie jest trwałe, nie tymczasowe. 18-miesięczne buildy rutynowo dostarczane są teraz w 6–8 miesięcy.

Jaki jest typowy roczny koszt utrzymania dedykowanego oprogramowania enterprise?

Branżowa reguła to 15–20% początkowego kosztu build rocznie, w sposób ciągły. Platforma custom za 300K USD powinna budżetować 45K–60K USD rocznie na utrzymanie (poprawki błędów, aktualizacje zależności, patche bezpieczeństwa, drobne usprawnienia). Nie obejmuje to dużych prac funkcjonalnych, które traktowane są jako nowy build. Zaniżanie budżetu utrzymania to najczęstszy błąd w modelach TCO custom build.

Jakie są ukryte koszty kupowania enterprise SaaS?

Sześć ukrytych kosztów, które większość demo pomija: lock-in vendor (6–18 miesięcy na zmianę), opłaty za customizację i change request (200–500 USD/godz.), pełzanie per-seat na 7–15% rocznie w miarę wzrostu organizacji, koszty integracji (20K–100K USD per podłączony system), koszt wyjścia i migracji (3–6 miesięcy inżynierii) i roczne podwyżki cen na 7–15% niezależnie od użycia. Opłata licencyjna roku 1 to rzadko więcej niż 30–40% prawdziwego kosztu 5-letniego.

Czym jest całkowity koszt posiadania (TCO) oprogramowania?

TCO to pełny 5-letni koszt ścieżki oprogramowania, obejmujący licencjonowanie lub development, wdrożenie, szkolenia, integrację, bieżące utrzymanie, alokację FTE administracyjnych, koszt alternatywny i koszt wyjścia/migracji, gdy w końcu odchodzisz. Badania Gartnera pokazują, że firmy typowo pomijają 50–70% prawdziwego TCO w początkowych kalkulacjach. Policz przed zobowiązaniem, nie po.

Jak duża musi być firma, żeby uzasadnić budowanie dedykowanego oprogramowania enterprise?

Zgrubna reguła: ~10M+ USD ARR lub ~50+ użytkowników na konkretnym workflow. Poniżej tego progu subskrypcja SaaS prawie zawsze wygrywa, bo nie jesteś w stanie zamortyzować inżynierii i utrzymania na wystarczającym użyciu. Powyżej, matematyka zaczyna sprzyjać build lub blend, szczególnie gdy workflow jest rdzeniem twojej pozycji konkurencyjnej. Agenty AI do kodowania w 2026 obniżają ten próg o 20–30% vs baza z 2023.

O autorze

Mert Batur Gurbuz jest współzałożycielem Techsy.io, gdzie zespół dostarcza agentów AI, systemy automatyzacji i pipeline'y voice/SDR dla klientów B2B. Studiuje na University of Birmingham i pisze o stacku narzędziowym LLM, którego zespół Techsy faktycznie używa na produkcji. Współzałożyciel, Techsy.io, University of Birmingham. Połącz się na LinkedIn.

Podsumowanie

Jeśli zapamiętasz jedną rzecz z tego tekstu: nazwij stronniczość każdego frameworka, który czytasz, zanim zaufasz rekomendacji. Vendorzy dają rady vendorów. Agencje dają rady agencji. Twój CFO daje rady CFO. Przeczytaj trzy, znajdź część wspólną i zaufaj temu.

• Przeprowadź 12-punktową rubrykę na żywo na spotkaniu. Skraca debatę z dwóch godzin do dwudziestu minut.
• Policz 5-letni TCO uczciwie. Cena z roku 1 nigdy nie jest odpowiedzią.
• Domyślnie wybieraj Blend, jeśli twój wynik ląduje na 30–45. Większość firm i tak tu kończy.

Jeśli chcesz drugiej pary oczu na tę decyzję, umów bezpłatną 30-minutową ocenę build-vs-buy. Powiemy ci, żebyś kupił SaaS, jeśli to właściwa decyzja. Zdarzyło się. Zdarzy się znowu.