Pytanie, które większość firm zadaje od tyłu
Spędziłem prawie dekadę po tej gorszej stronie tego pytania.
Przez siedem lat w poprzedniej firmie budowanie oprogramowania na własne potrzeby było moją pracą. Nie projektem po godzinach, nie inicjatywą na kwartał — robiłem to codziennie, razem z tą trudniejszą i cichszą częścią roboty, czyli pilnowaniem, żeby ludzie naprawdę używali tego, co zbudowałem. Dziś jestem CEO AgentUI i pomagam innym firmom podjąć dokładnie tę decyzję. Więc kiedy ktoś pyta mnie, czy budować, czy kupić, nie sięgam po framework przeczytany gdzieś w internecie. Sięgam po blizny.
Krótka wersja tego, czego się nauczyłem: większość firm zadaje to pytanie od tyłu. Zaczynają od „czy da się to kupić?”, a lepsze pytanie na start brzmi „czy ten proces jest wyjątkowy dla nas?”. To nie to samo pytanie, a mylenie ich kosztuje lata.
Wyjaśnię.
Domyślna zasada, którą wszyscy stosują źle
Na papierze obiegowa mądrość brzmi rozsądnie: najpierw spróbuj gotowca, a buduj tylko wtedy, gdy nic nie pasuje. Trzymaliśmy się tej zasady niemal religijnie. Zawsze próbowaliśmy kupić, zanim zbudowaliśmy.
Problem w tym, jak to „próbowanie” wyglądało w praktyce. Dla jednego kluczowego obszaru naszej działalności spędziliśmy lata — nie tygodnie, lata — próbując zmusić kupione oprogramowanie do działania. Przez ten czas przewinęły się dwa różne programy. Oba zawiodły. I za każdym razem zawiodły z tego samego powodu: wymagały, żebyśmy dostosowali naszą pracę do ich oprogramowania, zamiast dostosować oprogramowanie do naszej pracy.
To jedno zdanie to cały ten spór w pigułce. Kiedy kupujesz gotowy program do procesu, który naprawdę jest unikalny dla twojej firmy, nie kupujesz rozwiązania. Kupujesz remont całego sposobu, w jaki pracujesz, a ten remont nigdy się do końca nie kończy. Każde obejście, każde „ten fragment zrobimy sobie z boku w Excelu”, każde szkolenie tłumaczące, dlaczego program nie robi rzeczy oczywistej — to jest koszt wciskania firmy w cudze założenia.
Nikt ci nie mówi, że tego kosztu nie widać na fakturze. Oprogramowanie ma cenę. Lata operacyjnego tarcia nie mają.
Studium przypadku: program handlowy, który otworzył nam świat
Powiem to konkretnie, bo przy abstrakcjach łatwo kiwać głową, a trudno cokolwiek z nimi zrobić.
Jednym z największych programów, jakie zbudowałem, był program dla naszych handlowców. Zanim powstał, przygotowanie oferty było ręczną męczarnią. Handlowiec musiał posklejać kilka plików Excel, wytropić dane magazynowe, które mogły być aktualne albo nie, i wygrzebać informacje techniczne — karty katalogowe, PDF-y, dokumentację rozwiązania — z miejsc, w których akurat leżały. Było to wolne, podatne na błędy i całkowicie zależne od tego, czy dany handlowiec wie, gdzie co leży.
Zbudowaliśmy więc program, w którym handlowiec logował się, widział stan magazynu na żywo i tworzył ofertę od ręki. Odblokowała się nie tylko szybkość. Odblokowało się to, że wszystkie informacje techniczne były w jednym miejscu. Klikasz w produkt i widzisz wszystko: parametry, dokumentację, PDF-y, opis rozwiązania. A potem — i to była część, która znaczyła najwięcej — mogłeś wysłać to wszystko klientowi jednym kliknięciem.
Ten program zrobił coś, czego nie przewidziałem w pełni, kiedy zaczynałem go budować. Pozwolił nam zdobyć klientów z całego świata, do których wcześniej nigdy nie potrafiliśmy dotrzeć. Kiedy potencjalny klient na innym kontynencie dostaje kompletną, profesjonalną, technicznie szczegółową ofertę w minuty zamiast w dni, geografia przestaje mieć znaczenie. Ten program nie tylko przyspieszył naszą pracę. Powiększył rynek, który byliśmy w stanie wiarygodnie obsłużyć.
Żaden gotowy produkt nigdy by tego nie zrobił, bo żaden gotowy produkt nie rozumiał naszego magazynu, naszej dokumentacji technicznej i naszego sposobu sprzedaży tak jak my. Próbowaliśmy. Pamiętasz te dwa programy i te stracone lata? To właśnie one próbowały to zastąpić i nie dały rady.
To kiedy w takim razie kupować?
Jeśli doczytałeś do tego miejsca z wrażeniem, że jestem fanatykiem „zawsze buduj sam”, od razu to prostuję. Nie jestem.
Nigdy nie budowałbym CRM-u. CRM kupujemy, kropka, i prawie każdemu radzę to samo.
Różnica wygląda tak. CRM musi integrować się z pocztą i kilkunastoma innymi programami. To naprawdę złożona, dojrzała kategoria, a istniejące produkty są solidne właśnie dlatego, że tysiące firm przez lata je ogrywały. Nie ma tu żadnej unikalnej przewagi do zdobycia przez pisanie swojego. Włożyłbyś ogrom pracy, żeby w najlepszym razie dojść do czegoś nieco gorszego niż to, co mogłeś kupić pierwszego dnia.
To jest ten test i jest prostszy niż większość frameworków „budować czy kupić”:
- Kupuj, kiedy problem jest powszechny. Jeśli sto innych firm ma tę samą potrzebę co ty, ktoś już zbudował lepszą wersję, niż ty zbudujesz, i już zintegrował ją ze wszystkim. CRM, poczta, księgowość, kadry i płace — to jest rozwiązane. Nie wymyślaj tego od nowa.
- Buduj, kiedy proces jest unikalny dla ciebie. Kiedy masz przebieg pracy specyficzny dla tego, jak działa twoja firma — jak u nas tworzenie ofert technicznych — to jest dokładnie ten moment, w którym budowanie ma sens. Nie ma produktu, który pasuje, bo ten proces istnieje tylko w twoich czterech ścianach.
Pytanie rozstrzygające nigdy nie brzmi „czy istnieje na to oprogramowanie?”. Brzmi „czy to, co tu robimy, jest na tyle inne, że żaden uniwersalny program tego nie obejmie?”. Jeśli tak — buduj. Jeśli nie — kup i zajmij się życiem.
Co naprawdę zmieniła AI
Przez większość mojej kariery to drzewko decyzyjne miało brutalny przypis: nawet kiedy budowanie było oczywiście słuszne, było drogie. Potrzebowałeś programistów. Potrzebowałeś czasu. Budowanie było poprawne w teorii i często nie do udźwignięcia w praktyce, dlatego tyle firm domyślnie kupowało programy, które nie pasowały — a potem latami za to płaciło, tak jak my.
AI skasowała ten przypis i to jest część, która naprawdę mnie ekscytuje.
Stary świat zmuszał cię, żebyś dopasował całą firmę do oprogramowania. Nowy świat pozwala zbudować oprogramowanie, które dopasowuje się do twojej firmy. To odwrócenie jest całą stawką. Każda firma jest inna i po raz pierwszy możesz mieć system, który cyfryzuje twoje procesy i ten konkretny sposób, w jaki prowadzisz firmę — bez armii inżynierów.
Dokładnie to budujemy w AgentUI. Chodzi o to, żebyś mógł zbudować z AI dowolny program, którego potrzebujesz wewnątrz firmy, zamiast zatrudniać programistę i czekać miesiącami. Żeby było jasne: programiści nadal mają pełne ręce roboty. Do produktów, których dotyka klient, wziąłbym programistę bez wahania — to, z czym stykają się klienci, zasługuje na taki poziom rzemiosła i dbałości. Ale do programów na wewnętrzny użytek? W większości przypadków już go nie potrzebujesz. Potrzebujesz AI i narzędzia, które pozwala ci budować.
To przesuwa rachunek „budować czy kupić” w sposób, który łatwo niedoszacować. Kiedy budowanie było kosztowne, „kup i nagnij swoje procesy” często było racjonalnym wyborem, nawet jeśli bolało. Teraz, kiedy budowanie jest tanie i szybkie, szala mocno przechyla się w stronę budowania wszystkiego, co naprawdę jest twoje.
Dwa zastrzeżenia, które słyszę najczęściej
Kiedy przedstawiam ten argument, prawie zawsze pojawiają się dwie obawy. Są uczciwe i zasługują na prostą odpowiedź.
„A co z bezpieczeństwem?”
To jest ta duża. Firmy boją się wycieku informacji, dostępu niepowołanych osób do danych, włamania albo utraty informacji. To uzasadniona obawa — budowanie własnych programów historycznie oznaczało branie na siebie własnych problemów z bezpieczeństwem. To rozwiązujemy wprost w AgentUI, zarządzaną infrastrukturą, żeby wszystko, co zbudujesz, było bezpieczne z automatu. Nie powinieneś musieć zostać ekspertem od bezpieczeństwa, żeby zbudować program dla swojej firmy, i nie powinieneś wybierać między „pasuje do naszego biznesu” a „nie doprowadzi do wycieku”.
„Czy nie utkniemy z utrzymywaniem tego na zawsze?”
To obawa o utrzymanie i dług techniczny i to ona po cichu zabija wiele dobrych decyzji o budowaniu. Założenie jest takie, że budowanie oznacza podpisanie się pod wieczną konserwacją. Ale ludzie przeoczają jedną rzecz: przychodzi moment, w którym można po prostu przestać budować. Program robi swoje, a ty od niego odchodzisz. A ta naprawdę trudna część — utrzymanie infrastruktury pod spodem, czyli to, co faktycznie budzi grozę — to dokładnie to, co bierzemy na siebie po naszej stronie, więc nie niańczysz każdego elementu. Zbuduj, skończ, idź dalej.
Opinia pod prąd: przestań budować katedrę
Tu postawię swoją flagę i to jest rzecz, którą moim zdaniem większość ludzi robi źle nawet po tym, jak zdecydują się budować.
Nie próbuj budować ogromnego systemu od zera. To zły pomysł, prawie zawsze.
Odruch, kiedy firma zapala się do budowania własnego oprogramowania, jest taki, żeby pójść na całość — zaprojektować rozległą wewnętrzną platformę, która poprowadzi cały biznes. Tak umierają projekty budowy. Zawalają się pod ciężarem własnych ambicji, zanim cokolwiek dowiozą.
Dużo lepszy ruch to ucyfrowienie procesów, które już dziś robisz ręcznie — tych, które siedzą teraz w Excelu, tych, które są charakterystyczne dla twojej firmy. Tyle. Znajdź ten arkusz, którego twój zespół nie znosi, to ręczne sklejanie danych, które zjada godziny w każdym tygodniu, tę jedną rzecz, którą tylko twoja firma robi tylko w swój sposób. Zbuduj to. Jest małe, konkretne, ma oczywisty zwrot i jest dokładnie tym, czego żaden gotowy program nigdy dobrze nie obsłuży.
Zacznij od bolesnego arkusza, nie od wielkiej wizji. Katedra może poczekać. Program do ofert, który otworzył nam świat, nie zaczął się jako lot na Księżyc — zaczął się od „ten ręczny proces nas wykańcza, naprawmy to”.
Konkluzja
Kupuj to, co powszechne. Buduj to, co naprawdę twoje. Nie naginaj swoich procesów do oprogramowania, które nigdy nie było projektowane dla ciebie — latami popełnialiśmy ten błąd i rachunek przyszedł w straconym czasie i straconych szansach. A cokolwiek budujesz, zacznij od małego, zacznij od ręcznego procesu, który już rozumiesz, i pozwól programowi rosnąć od tego miejsca.
Przez większość mojej kariery ta rada miała zastrzeżenie, że budowanie jest luksusem. Już nie jest. To, co kiedyś wymagało programistów i kwartałów pracy, mogą dziś zbudować ludzie, którzy naprawdę rozumieją proces — czyli ty.
To jest prawdziwa zmiana. Pytanie nigdy nie brzmiało wyłącznie „budować czy kupić”. Brzmiało, czy stać cię na oprogramowanie, które pasuje do tego, jak naprawdę pracujesz. Teraz stać.