Najczęstsze dwa błędy
Decyzja "build vs buy" — czy zbudować własny system, czy kupić gotowy — kończy się dwoma błędami częściej, niż się przyznajemy.
Błąd numer jeden: budowanie własnego HubSpota. Firma, która ma za dużo pieniędzy i za małą cierpliwość, decyduje że "potrzebujemy własnego systemu". Buduje przez rok coś, co HubSpot oferuje za niewielką miesięczną opłatę. System ma 60% funkcji HubSpota i kosztuje 5× więcej. Po dwóch latach nikt go nie utrzymuje.
Błąd numer dwa: zostawanie z HubSpotem, kiedy 80% firmy to wyjątki od jego logiki. Firma używa CRM, który nie pasuje, więc zespół wpisuje dane "w okolicach pól", traci czas na walkę z narzędziem, w końcu przestaje wpisywać. CRM jest formalnie "wdrożony", a faktycznie martwy.
Dobra decyzja "build vs buy" wymaga frameworka. Nie intuicji, nie zachwytu nową technologią, nie ekonomii ego. Konkretnych pytań w konkretnej kolejności.
Pytanie 1 — Czy Twoja firma ma "swoją logikę"
Pierwsze i najważniejsze pytanie: jak bardzo Twoja firma odbiega od tego, co robi przeciętna firma w branży?
Mała odchyłka: sprzedajesz tę samą usługę co konkurencja, podobnym klientom, w podobny sposób. Możesz różnić się jakością, ale proces jest standardowy. Klient pyta → dajesz ofertę → realizujesz → fakturujesz.
→ Gotowy SaaS to dobra decyzja. HubSpot, Pipedrive, monday — wszystko zaprojektowane pod standardowy proces. Kup, skonfiguruj, używaj.
Średnia odchyłka: robisz coś podobnego do branży, ale masz unikalne kroki w procesie. Np. agencja marketingowa, która przed projektami robi 4-tygodniowy audyt.
→ Konfigurowalny SaaS + ewentualnie własne mikrowarstwy. Bazuj na gotowcu, ale dorób własne narzędzia tam, gdzie naprawdę odbiegasz.
Duża odchyłka: Twoja firma robi rzeczy, których standardowy CRM nie potrafi opisać. Klinika z 7-warstwową komunikacją z pacjentem i scorecardem finansowym per lekarz. Agencja z systemem 7 warstw, w którym praca układa się w sekwencji. Doradca z metodologią wymagającą 12 dokumentów i 4 punktów decyzyjnych dla każdego klienta.
→ Custom system ma sens. Bo gotowiec wymaga kompromisu w 60% funkcji. A kompromis kosztuje czas zespołu codziennie.
Pytanie 2 — Czy Twoja "logika" jest stabilna
Drugie pytanie często pomijane: jak długo Twoja firma pracuje w obecny sposób?
Mniej niż 2 lata: firma wciąż się definiuje. Procesy są w ruchu. Co miesiąc coś zmieniacie.
→ Nie buduj custom systemu. Bo zanim go skończysz, Twoja firma będzie pracować inaczej. Custom system to zakodowanie obecnej logiki. Jeśli logika się zmienia — kodowanie ją zatrzymuje.
2–4 lata: firma ma już swój kształt, ale wciąż dopina detale.
→ Konfigurowalny SaaS + plany na custom. Używaj gotowca przez kolejny rok-dwa. Notuj, gdzie Cię uwiera. Jak masz 20–30 konkretnych przypadków, że gotowiec nie pasuje — wtedy myśl o custom.
4+ lat: firma działa spójnie. Procesy są ustabilizowane. Nie zmieniacie logiki co kwartał.
→ Custom system jest realną opcją. Bo to, co zakodujesz, będzie aktualne za 2 lata.
Pytanie 3 — Jaki masz zespół
Trzecie pytanie, które w decyzji "build vs buy" ma większą wagę, niż się powszechnie zakłada:
Czy w firmie jest osoba, która myśli o "produkcie systemowym"?
Custom system bez właściciela produktu po stronie klienta — to projekt, który po roku jest niezadowalający. Nie dlatego, że deweloper jest słaby. Dlatego, że nikt po stronie firmy nie pilnował, "co ten system ma robić".
Właścicielem produktu może być:
Bez takiej osoby — gotowiec jest bezpieczniejszy. Bo gotowy system został zaprojektowany przez czyjś zespół produktowy. Custom system bez właściciela produktu to "system, którym nikt nie kieruje".
Pytanie 4 — Jaką ekonomię to ma
Czas pomyśleć o ekonomii. Ale uwaga — większość firm liczy ją źle.
Zła kalkulacja: "ile kosztuje custom system" vs "ile kosztuje SaaS" w pierwszym roku.
Dobra kalkulacja: "ile kosztuje custom system w ciągu 5 lat, włącznie z utrzymaniem i rozwojem" vs "ile kosztują SaaS-y, których używamy, włącznie z czasem zespołu walczącego z ich ograniczeniami, w ciągu 5 lat".
W tej drugiej kalkulacji custom system wygrywa zaskakująco często — pod warunkiem że odpowiedzi na pytania 1, 2, 3 były właściwe. Bo:
ALE: jeśli odpowiedzi na pytania 1, 2, 3 były złe — custom system będzie 3× droższy i przyniesie 0% wartości.
Pytanie 5 — Czy masz cierpliwość
Ostatnie pytanie, które wszyscy chcą pominąć: czy masz cierpliwość do roku iteracji?
Custom system po pierwszym wdrożeniu nie działa idealnie. Działa dobrze — ale wymaga 6–12 miesięcy szlifowania. Każdy miesiąc dodaje warstwę. Zespół zaczyna używać. Sugerują zmiany. Dorabiamy.
To jest fundamentalnie inna ekonomia niż SaaS. SaaS kupujesz raz, używasz. Custom buduje się przez rok, potem rośnie.
Jeśli oczekujesz "kupić i działać od jutra" — kup SaaS. Jeśli akceptujesz "rok ciężkiej pracy, potem 5 lat przewagi" — buduj custom.
Tabela decyzyjna
| Sytuacja | Odpowiedź | |---|---| | Standardowy proces, mały zespół, mała ambicja | Gotowy SaaS | | Standardowy proces, duży zespół, ambicja wzrostu | Konfigurowalny SaaS + integracje | | Średnia odchyłka, średni zespół, plan na lata | Hybryda — gotowiec jako baza + custom warstwy | | Duża odchyłka, dojrzała firma, właściciel produktu, cierpliwość | Custom system | | Duża odchyłka, niedojrzała firma | Najpierw uporządkuj firmę, potem decyduj |
Co zrobić, żeby decyzja nie była błędna
Trzy zasady, które chronią przed wpadnięciem w jeden z dwóch błędów na początku:
Zasada 1 — Najpierw 6 miesięcy z gotowcem. Zanim zaczniesz mówić o custom, użyj gotowca przez pół roku. Notuj, gdzie nie pasuje. Po 6 miesiącach masz konkretną listę, a nie domysł.
Zasada 2 — Buduj custom warstwami. Nigdy "wielki release za rok". Pierwsza warstwa działa za 4–8 tygodni. Co miesiąc dodajesz kolejną. Po 6 miesiącach masz coś, co już oszczędza czas.
Zasada 3 — Pilnuj właściciela produktu. Custom system bez kogoś, kto myśli o nim codziennie po stronie firmy — nie zadziała. Jeśli nie masz takiej osoby — albo ją zatrudnij, albo nie buduj custom.
Kiedy warto zacząć rozmowę
Jeśli odpowiedzi na pytania 1–5 wskazują, że custom system ma sens — najprostszy następny krok to rozmowa, w której opisujesz, gdzie konkretnie gotowiec Was uwiera.
Po takiej rozmowie zwykle widać, czy projekt ma sens. I jaką jego wersję warto zacząć — bo custom system może być małą warstwą nad gotowcem albo pełnym systemem od podstaw. Decyzja zależy od konkretów.