Punkt wyjścia: czy system jest „wymienialny”, czy strukturalny?
Zanim porównasz dostawców, sklasyfikuj produkt:
Oprogramowanie wymienialne: da się je zastąpić w 12–24 miesiące bez paraliżu biznesu (np. strona, prosty panel wewnętrzny).
Oprogramowanie strukturalne: obsługuje krytyczne procesy, przechowuje dane kluczowe lub buduje obowiązki audytowe (np. płatności, transakcje, rozliczenia, uprawnienia).
Jeśli to drugi przypadek, „najtańsza” opcja w praktyce bywa tą, która najlepiej kontroluje złożoność, ułatwia zmiany i zapewnia operacyjność. Bo największe koszty pojawiają się nie w wytworzeniu pierwszej wersji, tylko w utrzymaniu i adaptacji.
Wniosek decyzyjny:
Jeśli system jest wymienialny → optymalizuj krótkoterminowo (czas, budżet, prostota). Jeśli jest strukturalny → optymalizuj pod własność, operacyjność i przewidywalną zmianę.
Koszt: za co realnie płacisz (a czego nie widać w stawce)
W praktyce koszty dzielą się na dwie grupy: „widoczne” koszty wytworzenia i koszty koordynacji/organizacji pracy.
Koszty wytworzenia (łatwe do policzenia)
zespół wytwórczy (engineering, QA, product/design),
prace architektoniczne i platformowe,
elementy bezpieczeństwa/compliance (jeśli dotyczy),
środowiska, CI/CD, narzędzia.
Te pozycje są podobne niezależnie od modelu — różnią się opakowaniem i marżą.
Koszty koordynacji (najczęściej zaniżane)
Rosną, gdy:
jest dużo handoffów i warstw decyzyjnych,
seniorzy są „dzieleni” między wiele klientów,
proces wymaga wielu formalnych kroków przed zmianą kierunku.
Duże agencje często mają więcej procesów i równoległych projektów. To bywa zaletą w programach o wysokiej formalizacji, ale potrafi spowolnić feedback i podnieść koszt „samej organizacji” pracy. Mniejszy software house z reguły utrzymuje ciaśniejszy kontekst i prostszą ścieżkę decyzji — o ile faktycznie zapewnia stabilny skład zespołu.
Wniosek decyzyjny:
Jeśli wymagania są stabilne i dobrze opisane → narzut koordynacji może być akceptowalny. Jeśli wymagania ewoluują → koordynacja staje się głównym kosztem i małe, stabilne zespoły zwykle wygrywają.
Tempo dostarczania: dlaczego „więcej ludzi” bywa wolniej
Szybkość zależy mniej od liczby osób, a bardziej od:
czasu podejmowania decyzji,
jakości informacji zwrotnej (i jak szybko trafia do zespołu),
skali przeróbek wynikających z braku kontekstu.
Duża agencja potrafi szybko zmobilizować duży zespół i „udźwignąć” program w wielu strumieniach prac. Jednocześnie — jeśli kluczowe decyzje przechodzą przez kilka warstw, tempo iteracji spada.
Software house ma często przewagę w projektach, gdzie trzeba szybko uczyć się na danych z rynku/operacji. Kontekst zostaje w zespole, a decyzje są bliżej wykonania. To nie jest gwarancja jakości — to przewaga strukturalna, którą trzeba zabezpieczyć umownie i organizacyjnie (stabilność zespołu, zakres odpowiedzialności, definicja „done”).
Wniosek decyzyjny:
Jeśli potrzebujesz szybkich iteracji → preferuj mały, stabilny zespół i krótką ścieżkę decyzyjną. Jeśli prowadzisz program o wielu zależnościach i formalnym governance → duża agencja może być lepszym dopasowaniem.
Ryzyko operacyjne: „skończone” znaczy „da się utrzymać”
W systemach krytycznych najczęstszy problem nie brzmi „czy dowieziemy funkcje”, tylko: „czy da się tym bezpiecznie zarządzać w realnych warunkach”. Operacyjność to nie dodatek na końcu — to część produktu.
Ryzyko rośnie, gdy:
nie ma jasnych właścicieli komponentów i odpowiedzialności po starcie,
w systemie narasta ukryta złożoność (silne sprzężenia, kruche integracje),
utrzymanie działa „ticketowo”, bez stałej opieki architektonicznej,
brakuje runbooków, monitoringu, sensownych alertów i scenariuszy awarii.
Wniosek decyzyjny:
Jeśli na starcie nie potrafisz wskazać właściciela operacji (SRE/DevOps/On-call), zasad zmian i standardów obserwowalności — kupujesz przyszłe przestoje i spadek tempa rozwoju, niezależnie od tego, czy dostawcą jest duża agencja czy software house.
Własność długoterminowa: IP w umowie to nie to samo co brak lock-inu
Duża agencja może przekazać własność kodu w umowie — i często to zrobi. W praktyce lock-in może jednak pozostać przez:
brak dokumentacji decyzji i kontekstu,
złożony, „agencjowy” proces dowożenia,
wysokie obciążenie poznawcze kodu,
zależność od konkretnych osób lub specyficznych narzędzi.
Własność operacyjna oznacza, że inny zespół (wewnętrzny lub nowy dostawca) przejmie system bez utraty kontroli i bez wielomiesięcznej „rehabilitacji” kodu.
Wniosek decyzyjny:
Traktuj przekazanie IP jako warunek konieczny, ale niewystarczający. Liczy się przenaszalność: dokumentacja, obserwowalność, rozsądna architektura i model utrzymania.
Kompromisy
Duża agencja: kiedy ma sens
Potrzebujesz formalnej struktury programu (wiele strumieni prac, mocne governance, wymagania zakupowe).
Projekt jest wyspecjalizowany i faktycznie wymaga szerokiego „bench’u” kompetencji.
Akceptujesz wyższy koszt koordynacji w zamian za skalę i proces.
Kompromis: więcej struktury i potencjalnej skali, ale często wolniejsza pętla feedbacku i większy narzut organizacyjny.
Software house: kiedy ma sens
Priorytetem jest tempo uczenia się i iteracji.
Roadmapa jest discovery-driven (zmieni się wraz z danymi z rynku i operacji).
Chcesz bezpośredniego dostępu do osób decyzyjnych, a nie „warstw” accountu.
Kompromis: mniejsza rezerwa kompetencyjna — specjalizację trzeba zweryfikować wcześniej, a stabilność zespołu zabezpieczyć.
Anti-patterny, które psują decyzję po czasie
Ciężki „big design” bez strategii zmiany
Wczesne decyzje architektoniczne potrafią zamienić się w sztywność, gdy produkt ewoluuje.Rotacja ludzi jako „optymalizacja kosztu”
Na papierze wygląda dobrze. W praktyce zabija kontekst, zwiększa przeróbki i ryzyko błędów.„Dowiezione funkcje” bez operacyjności
Brak runbooków, standardów monitoringu i przygotowania na awarie kończy się trybem gaszenia pożarów.„Przekazaliśmy repozytorium” jako definicja własności
Kod jest formalnie twój, ale nikt nie potrafi go bezpiecznie rozwijać.
Co to znaczy w praktyce wdrożeniowej
Jeśli system dotyka finansów, tożsamości lub rejestrów transakcyjnych, kupujesz również:
audytowalność (kto/co/kiedy),
śledzenie zmian i statusów,
kontrolę dostępu (role, uprawnienia),
przewidywalne integracje (np. płatności i webhooks),
proces obsługi incydentów.
W materiałach dostawcy Bitecode opisano podejście modułowe: start od działającej bazy i dostosowanie jej do logiki biznesowej zamiast budowania wszystkiego od zera. W opisie pojawiają się m.in. moduły użytkowników i ról, płatności (ze Stripe), rejestry transakcji z historią statusów, „wallety” i powiadomienia oraz zdefiniowany stack technologiczny. To może skrócić czas do pierwszej wartości — pod warunkiem, że równie poważnie potraktujesz przenaszalność, operacyjność i plan przejęcia utrzymania.
W tych samych materiałach pojawiają się deklaracje (np. dotyczące czasu realizacji i „pełnej własności kodu”). Traktuj je jako punkt wyjścia do weryfikacji w umowie i w planie handoveru, nie jako automatyczną gwarancję.
Wniosek decyzyjny:
Jeśli Twoim ryzykiem jest późna przeróbka i wolne uczenie się, modułowa baza + stabilny zespół mogą być rozsądnym wyborem. Jeśli Twoim ryzykiem jest governance i skala programu — możesz potrzebować modelu dużej agencji, ale musisz kontrolować narzut koordynacji.
„Build vs buy” w tym kontekście
Tu nie chodzi o „budować czy kupić system”. Chodzi o to, jakim systemem dowożenia chcesz zbudować produkt.
Wybierz dużą agencję, jeśli:
governance i skala są ważniejsze niż szybkość iteracji,
potrafisz wymusić stabilność zespołu i ciągłość seniorów,
masz po stronie firmy mocne product ownership (żeby decyzje nie „wyparowały” do dostawcy).
Wybierz software house, jeśli:
potrzebujesz krótkich pętli feedbacku i trwałego kontekstu,
roadmapa będzie się zmieniać w trakcie,
zależy Ci na przenaszalności (możliwości zmiany dostawcy albo przejęcia in-house).
Checklisty decyzyjne
Checklista dla dostawcy (dla obu modeli)
Stabilność zespołu: kto jest przypisany na 6–12 miesięcy? co uruchamia rotacje?
Ścieżka decyzji: kto podejmuje decyzje produktowe i architektoniczne, w jakim czasie?
Operacyjność jako deliverable: jakie runbooki, monitoring, alerty i standardy utrzymania powstaną — i kiedy?
Failure modes: jakie są kluczowe scenariusze awarii i jak będą obsługiwane?
Przenaszalność: jakie artefakty powstaną (dokumentacja, diagramy, ADR-y, instrukcje deployu)?
Własność w praktyce: jak wygląda handover i plan „pierwszych 90 dni” po wdrożeniu?
Checklista po stronie firmy
Jeden właściciel produktu z realną decyzyjnością (priorytety, zakres).
Zasady governance: co wymaga akceptacji, a co jest decyzją zespołu.
Definicja „done”: zawiera operacyjność, nie tylko funkcje.
Plan po starcie: wsparcie, reakcja na incydenty, rytm iteracji i backlog utrzymaniowy.
Podsumowanie
Duża agencja bywa dobrym wyborem w programach o wysokiej formalizacji lub tam, gdzie specjalizacja i skala są kluczowe. Jej słabym punktem bywa narzut koordynacji i wolniejsza pętla feedbacku, zwłaszcza gdy klient nie ma mocnego product ownership.
Software house może wygrać tempem i skupieniem — szczególnie gdy system powstaje iteracyjnie i wymaga stałego kontekstu. Warunkiem jest stabilny skład, jasny model odpowiedzialności i realna przenaszalność systemu po wdrożeniu.
Jeśli oprogramowanie „prowadzi firmę”, a nie tylko ją wspiera, decyzja jest strukturalna. Wtedy warto oceniać dostawcę przez pryzmat tego, czy ułatwia zmianę, kontroluje złożoność i zostawia po sobie system, który da się utrzymać bez ciągłego „ratownictwa”.
