Dlaczego setki gwiazdek na Github nie przynoszą biznesu | Forki jako sygnał potencjału OSS| Lęk przed byciem twarzą firmy vs strategia | Agentic Commerce Protocol - Goryle otwierają pusty tron

Grow Your Software House to metody, narzędzia GPTs, analizy i nagrania, które pomagają software house'om odkryć swój silnik wzrostu.

Cześć! Nazywam się Maciej Greń i od 17 lat zajmuję się rozwojem firm typu Software House. Grow Your Software House to biuletyn z częścią darmową na Linkedin rozwinięty o płatne analizy tutaj na Substack wraz z wiedzą, narzędziami i filmami pokazującymi jak przestać błądzić i zacząć systematycznie rozwijać swój Software House. W dzisiejszym numerze:

• Od “zrobiliśmy i nic” do strategicznego OSS: Problem, Timing i Decydent jako fundament sukcesu

• Nietypowy sposób jak sprawdzić czy dany projekt OSS ma potencjał dla agencji software - po forkach go poznacie

• Jak lęk przed byciem twarzą swojej firmy, ekspertem w danej niszy warunkuje jej strategię?

• Agentic Commerce Protocol - kiedy dwóch Goryli otwiera pusty tron

Zebrana wiedza w tym biuletynie powinna być używana z rozwagą i na własną odpowiedzialność. Zapożyczam w nim nagminnie frazy z języka angielskiego, wybaczcie, robię to celowo ponieważ w codziennej pracy korzystamy z tych fraz nieustannie.

---

Dlaczego setki gwiazdek na Github nie przynoszą biznesu

Rozmawiałem ostatnio z SH, który zainwestował sporo czasu w budowanie OSS, zdobyli nawet kilkaset gwiazdek na Github, pojechali na konferencje, ale żadnego biznesu to nie przyniosło. Takich historii jest wiele, za każdym razem słyszę ten sam motyw:

zrobiliśmy, wypuściliśmy i ... nic.

Problem jest w tym, że nie rozumiemy problemu jaki rozwiązujemy naszym narzędziem/projektem. Tak jak to jest z tym newsletterem, jaki problem ja nim rozwiązuję?

Mój cel to pomagać firmom usługowym typu Software House rosnąć, dając gotowe, sprawdzone lekcje z mojej pracy i przemyśleń. Lekcje w różnej formie, czasem narzędzi, artykułów, nawet książek.

Lekcja zatem z takiego działania czyli z tworzenia projektu Open Source jest taka, że nie tworzymy go w dowolnym obszarze tylko musimy naprawdę dobrze zrozumieć kontekst narzędzi i rozwiązań, które są alternatywami.

Przykładowo, jeśli tworzymy narzędzie do optymalizacji zarządzania promptami w systemach agentowych to alternatywą może być prosty panel CRUD, który deweloper generuje w Cursorze w 10 min z promptami w backendzie i pozwala na ich wersjonowanie. To oczywiście przykład i alternatyw tak naprawdę jest dużo więcej, ale wiecie o co mi chodzi.

Zatem problem, który rozwiązujemy i jego otoczenie alternatywnych rozwiązań definiuje to jak kluczowe będzie skorzystanie z Waszej pomocy, jak bardzo unikatowa to będzie wiedza.

Druga kluczowa sprawa to timing.

Nie jest to taka prosta sprawa bo timing jest na dwóch poziomach: Developer Journey oraz Technology Journey (lub inaczej cykl adopcji technologii). Co się kryje pod tymi tajemniczymi pojęciami?

Developer Journey to podróż dewelopera podczas której tworzy kolejne wersje systemu dla danej firmy. Podczas tej podróży występują ciekawe momenty, które są różne w zależności od rozmiaru firmy i jej rodzaju, ale możemy je sprowadzić do takich bardzo prostych:

1. Potrzeba biznesowa - coś z biznesu prowadzi nas do wniosku, że trzeba zbudować nową część systemu. Czasem ta potrzeba pojawia się od strony zespołu technicznego, ale i tak jest argumentowana biznesowo (zaoszczędzimy/przyspieszymy/poprawimy X dzięki temu.)

2. Badanie architektury/technologii - wtedy ktoś techniczny sprawdza czy dana potrzeba może być rozwiązana i jak.

3. Szacunki i budżet. Czasem ten etap jest mocno oddzielony od samej realizacji danego systemu, szczególnie w dużych organizacjach.

4. Budowanie zespołu i rozpoczęcie prac. Tutaj mamy już wiedzę jaki mamy budżet i jaką technologią dany projekt tworzymy i chcemy go rozpocząć realizować.

5. Budowanie systemu i jego dostarczenie na produkcję.

6. Iteracja z rynkiem.

7. Powrót do punktu 0 dla obecnego systemu i tworzenie nowych modułów/wersji.

Jak myślicie, czy firma w etapie 5 będzie tak samo otwarta na współpracę z Agencją Software jak firma w etapie 1, 2 lub 3? z moich obserwacji to przepaść. Jeśli trafiacie do firmy w momencie wyboru technologii to możecie być poproszeni o pomoc w całym procesie szacunków, a potem wytworzenia. Jeśli lądujecie w fazie 4, 5 często firmy już kogoś mają, albo wewnętrznie, albo agencję. Wejście jest arcy-trudne.

Druga sprawa w timingu to Technology Journey/Adoption Cycle. Co to oznacza? jeśli technologia OSS, którą budujesz lub chcesz rozwijać jest we wczesnej fazie rynku np. nie jest jeszcze standardem, a na rynku jest duży gracz, który obecnie ten standard wyznacza, to warto o tym wiedzieć. Co więcej, tych etapów adopcji technologii jest kilka (innowatorzy, wizjonerzy, przepaść, wczesny rynek, kręgielnia, tornado/główny rynek, późny rynek) i zrozumienie gdzie dana kluczowa technologia jest ma kolosalne znaczenie. Jeśli inwestujecie czas i energię w coś niszowego, wcześnie na rynku to jego adopcja będzie trwała długo, bardzo długo. Drugą stroną tej podróży jest technologia, która już dawno jest na tzw. głównym rynku, dajmy na to Erlang, ale niestety nie stała się wiodącym standardem dla wielu nisz, ale raczej jest ciągle wyjątkową technologią do określonego segmentu.

Nie chcę się tutaj za mocno rozpisywać, ale ten przykład jest po to aby pokazać, że:

wybór projektu OSS może szybko być złym strzałem jeśli rozwiązujemy jakiś niewielki problem (biorąc pod uwagę alternatywy), późno w podróży developera, technologią która jest np. bardzo wcześnie na rynku.

Natura problemu - biznes czy tech?

Wracając jeszcze do problemu, który dany projekt rozwiązuje to kluczowe jest także to, czy ten problem jest bezpośrednio osób technicznych czy wychodzi od biznesu.

Jeśli wychodzi od biznesu (przykładowo: wkurza ich cennik Stripe i chcą zmienić dlatego zlecają to osobom technicznym aby podały alternatywy) to nawet jeśli stworzyłeś mega super fajne narzędzie adresujące ten problem to osoby techniczne, które dotrą do niego i powiedzą “wow! ta firma jest super” nie kupią tego od Ciebie tylko pójdą do szefa i powiedzą “no jest taki tool, ale kosztuje/nie wiemy jaka jest licencja”. Z dużą dozą szczęścia może się uda, ale często w tym właśnie momencie same osoby techniczne mówią “to może poszukam czegoś darmowego...”.

Budowanie projektów OSS, które są późno w developer journey może mieć jednak swój sens...

Przykładowo w 2015 Mike Grabowski stworzył projekt OSS na React Native, który potem został połączony z React Native core. To sprawiło, że Mike i firma za nim stojąca stała się rozpoznawalna na rynku. Sam projekt OSS stał się akredytacją, dowodem, że Mike i jego zespół są mistrzami w danej technologii. Natomiast to tylko przepustka, taki projekt to coś co pozwala na budowanie marki firmy, która pracuje z największymi graczami na rynku, która jest zapraszana na konferencje. Niestety, sam projekt OSS w takim przypadku będzie tylko i aż - górą lejka marketingowego i z racji wielu tysięcy gwiazdek na Github - darmowym banerem reklamowym do super określonej grupy docelowej.

Taktyka OSS polegająca na pisaniu bardzo popularnych projektów, które nie trafiają wcześnie w Developer Journey, ma sens jeśli poruszamy się w ekosystemie problemów, które dana technologia rozwiązuje dla osób technicznych. Wówczas budowanie w oczach tych liderów reputacji ma sens bo oni są decydentami ekonomicznymi i kolejny problem, dużo wyżej w developer journey, mogą Tobie zlecić, szczególnie jeśli dużo o tym będziesz mówił, pisał, i pomagał tym ludziom.

To kluczowa różnica - zrozumieć źródło problemu i dla kogo go rozwiązujesz. Jeśli jest to decydent technologiczny to wówczas budowa projektów OSS późno w Developers Journey nadal się zwróci bo ten decydent dzięki temu Tobie zaufa.

Dlatego warto stanąć trochę z boku tych swoich prób i zadać sobie pytanie:

Czy faktycznie wiem, w którym momencie, jaki problem i dla kogo rozwiązuję?

jeśli nie, to zapewne zdajesz się na szczęśliwy los... co czasem też się udaje, ale częściej, widzę to z autopsji, prowadzi do efektu, że nawet jak dana Agencja Software dosłownie “siedzi” na kurze znoszącej lub mogącej znosić dla nich złote jajka to nie wie o tym i rozmawia z rynkiem w nieodpowiedni sposób.

Nietypowy sposób jak sprawdzić czy dany projekt OSS ma potencjał dla agencji software - po forkach go poznacie

Ostatnio odkryłem kolejne pokłady wartościowych danych na Github. Forki…

Zapewne większość z Was wie co to jest, ale pośpieszę: deweloperzy robią forka danego projektu OSS, gdy muszą coś z w nim zmienić, coś czego nie da się zrobić nadbudowując kod wokół. W skrócie - dany projekt OSS jest dla nich wystarczająco kompletny aby na nim dalej iść, ale nie wystarczająco gotowy, zatem muszą go dopracować.

Czytając pierwszy wpis, dotyczący Developer Journey można powiedzieć, że gdy deweloper robi forka to już jest w etapie nr 4 czyli patrząc na moją własną wiedzę - za późno aby łatwo skorzystać z pomocy agencji software. Ale czy tak naprawdę jest?

Sam fakt, że dany projekt OSS jest forkowany przez duże firmy, to bardzo kluczowa informacja. Gdzieś w developer journey, ta technologia się pojawia i jest na tyle istotna, że zamiast ją zastąpić, zespół ją postanawia poszerzyć pod swoje potrzeby.

Ten proces decyzyjny, często angażuje osoby z zarządu/kierownictwa ponieważ dopisanie funkcji do projektu, nad którym nie mamy kontroli to ryzyko biznesowe. To powoduje naturalną potrzebę poszukania alternatyw, ale jeśli ich nie ma i pozostaje “dopisać” to jest to idealny moment aby precyzyjnie zbudować swoją ofertę pod ten przypadek. Aby było zabawniej, treść pod tego typu potrzeby jest na wyciągnięcie ręki. Forki mają commity, które zazwyczaj są kopalnią wiedzy nt. tego czego dany projekt OSS nie ma, a powinien mieć.

Przykładowo firma Unyt z Niemiec zrobiła forka Deno, aby mieć pełną kontrolę nad wersją i móc wprowadzać własne poprawki lub usuwać niepotrzebne funkcje bez czekania na zmiany w oficjalnym repozytorium. Pozwala im to utrzymać stabilność i dostosować runtime Deno do integracji z ich własnym ekosystemem (Unyt Land / UIX) oraz wymogów bezpieczeństwa.

Deno to nowoczesne środowisko uruchomieniowe dla JavaScript i TypeScript napisane w Rust, stworzone przez twórcę Node.js – zbudowane na silniku V8, z wbudowanym menedżerem modułów, narzędziami (lint, test, fmt) i silnym modelem bezpieczeństwa opartym na uprawnieniach.

Utrzymanie takiego forka to duży koszt dla organizacji, szczególnie jeśli Twoim kluczowym stackiem technologicznym nie jest Rust. W takiej sytuacji, nawet jeśli firma już sama utrzymuje taki fork, może być żywo zainteresowana Waszą pomocą aby przekazać w Wasze ręce utrzymanie tego modułu. Brzmi jak mały projekt? może... ale jaka będzie marża? czy takich klientów nie jest wielu ? sam projekt Deno jest obecnie sforkowany ponad 5 tysięcy razy...

Co jest natomiast najpiękniejszego w tym podejściu, to fakt, że mamy problemy technologiczne danej firmy na wyciągnięcie ręki, commity w forkach są gotowe do automatycznej analizy przez AI i do przygotowania szytej na miarę oferty/mailingu... jeśli...Wasza firma faktycznie posiada tego typu kompetencje.

Jak lęk przed byciem twarzą swojej firmy, ekspertem w danej niszy warunkuje jej strategię?

Trochę dziwne pytanie prawda? z jednej strony firma to nie jednostka, a jednostka to nie firma. Z drugiej strony, czy to nie jest jedank prawda? szczególnie w małych organizacjach, pomimo, że mogą już być stworzone procesy, zatrudnione osoby na odpowiednie stanowiska to brak tej jednej kluczowej sprawy, która powoduje, że firma jest na równi pochyłej w dół.

We wczesnym rynku (Early Market oraz w Early Majority), technologia nie jest jeszcze sprawdzona. Technologia, którą Twój Software House wprowadza do firmy. Klienci nie kupują wówczas produktu. Kupują wiarę w OSOBĘ, która im ten produkt dostarczy. Dlaczego? Bo ryzyko jest ogromne, technologia może nie działać, wdrożenie może się nie udać, a kariera kupującego jest zagrożona. W tym momencie jedyną walutą jest ZAUFANIE. A zaufanie we wczesnym rynku = zaufanie do osoby, nie do marki firmowej.

The Personal Brand Tax

Co to znaczy? Ktoś z core teamu musi:

• Być twarzą na konferencjach

• Pisać technical thought leadership

• Budować osobisty autorytet w społeczności

• Być rozpoznawalnym jako OSOBA (nie firma)

Unikanie Personal Brand Tax w efekcie oznacza, że Twoja firma powinna się skupić na drugiej połowie Technology Journey (Adoption Cycle).

źródło Research Gate.

Pierwsze trzy fazy Technology Journey wymagają zbudowania zaufania, że ktoś dostarczy doświadczenie całego kompletnego rozwiązania. Produkt (technologia) nie jest jeszcze potwierdzona przez wielkie firmy z całego świata, nie ma wielu wdrożeń, dlatego zaufanie w osobę jest tak kluczowe.

Dlaczego o tym piszę dla Agencji Software?

bo od kiedy pamiętam, ten aspekt był źle rozumiany w firmach, w których pracowałem.

Bycie twarzą, ekspertem było odbierane jako drobny element kampanii marketingowej. To niestety kategoryczny błąd. Firmy odbijają się od błyszczących slajdów i filmów jeśli muszą zaryzykować i podjąć współpracę z firmą, która ma ich przeprowadzić suchą stopą przez nowy, nieznany świat.

Twarz osoby jest kluczowa, jej ekspertyza i prowadzenie relacji z rynkiem - esencjonalne.

Natomiast, nie oznacza to, że firmy, które chcą uniknąć tego typu działań są skazane na przegraną. Znamy przecież wiele z nich, które nie mają jakiegoś wielkego sławnego guru, który promuje się na Linkedin. Przykładowo są firmy, które budują swój model biznesowy w głównym rynku, gdzie jest stabilna technologia np. Microsoft Dynamics i poprzez partnerstwa, relacje, wiedzę ekspercką, która dotyczy konkretnego systemu - stają się idealnym partnerem do działania. Wynika to z tego, że ciężar dowodu, że dana technologia jest warta inwestycji już został przeniesiony na rynek i teraz firmy usługowe, które na głównym rynku wypracowały swoją przewagę wiedzy, wdrożeń, partnerstw mogą z tego korzystać.

Strategiczne rozwidlenie: dwie równoległe rzeczywistości

To prowadzi nas do kluczowego momentu decyzyjnego. Obecność lub brak osoby gotowej zapłacić podatek osobistej marki nie jest drobnym detalem w kampanii marketingowej. To fundamentalny wybór, który dzieli firmy usługowe na dwa równoległe światy z zupełnie innymi zasadami gry.

I nie - nie ma drogi “lepszej” czy “gorszej.” Są po prostu dwie różne rzeczywistości.

Rzeczywistość A: Macie osobę gotową być twarzą

Co wam się otwiera? Właściwie wszystko.

Możecie gonić technologie na dowolnym etapie ich podróży - od wczesnego rynku gdzie jeszcze praktycznie nikt nie wie czy to zadziała, po główny rynek gdzie już jest standard ale możecie zdominować konkretną niszę. Wasz wybór zależy tylko od apetytu na ryzyko, kapitału który macie i cierpliwości.

Najbardziej lukratywne ścieżki (ale też najbardziej wymagające):

Tornado we wczesnym rynku - technologie które dopiero zyskują błogosławieństwo wielkich firm. Luka talentów jest ogromna bo popyt znacznie przekracza podaż. Tron goryla usługowego jest pusty albo słabo obsadzony.

Dzisiaj takie miejsca to przykładowo Rust dla infrastruktury krytycznej, Temporal dla budowania niezawodnych systemów rozproszonych, Polars dla przetwarzania danych.

Jak to wygląda w praktyce? Wasza osoba-twarz staje się częścią społeczności, buduje autorytet przez wkład do rdzenia projektu, występuje na konferencjach, pisze artykuły techniczne. Klienci kupują dostęp do tej osoby i jej zespołu. Nie kupują “firmy która robi X” tylko “dostęp do eksperta Y który pomoże nam przeżyć.”

Marże? Najwyższe możliwe. Premium za wiedzę której praktycznie nikt inny nie ma.

Ale ryzyko też najwyższe. Technologia może nie wejść na główny rynek, tornado może w ogóle nie nastąpić. A nawet jeśli nastąpi to czas do pierwszych klientów to spokojnie 12-24 miesiące budowania autorytetu. I co najważniejsze - ta osoba-twarz musi pozostać związana z firmą przez lata. Gdy Mike Grabowski sprzedał CallStack, musiał zostać w zarządzie. Dlaczego? Bo ON BYŁ produktem. Bez niego firma traci główny asset.

Zbywalność takiej firmy na początku wzrostu? Niska. To jest trade-off.

Kręgielnia - technologia już na głównym rynku ale możecie dominować kolejne nisze. Tutaj jest ciekawie bo początkowo personal brand jest kluczowy do zdobycia pierwszych 3-5 nisz. Ale stopniowo, gdy macie już 20-30 studiów przypadków, brand firmowy zaczyna przejmować ciężar dowodu. Osobisty autorytet otwiera drzwi, portfolio je zamyka.

I w tym modelu da się zrobić przejście. Po kilku latach osoba-twarz może zejść z pierwszego planu, a firma funkcjonować na brandzie firmowym.

Rzeczywistość B: Nikt nie chce być twarzą

Co wam zostaje?

Automatycznie musicie pominąć wczesne etapy rynku. Nie możecie gonić tornado, które dopiero się zaczyna. Musicie skupić się na technologiach, które już weszły na główny rynek albo są w jego drugiej połowie.

Brzmi jak porażka? Wcale nie.

To jest po prostu inne pole bitwy z innymi zasadami.

Główny rynek + specjalizacja branżowa - bierzecie sprawdzone, dojrzałe technologie i dodajecie głęboką wiedzę o konkretnej branży albo procesie.

Przykład? Wdrożenia systemów dla konkretnego przemysłu. Nie musicie być gwiazdami open source. Musicie rozumieć procesy klienta lepiej niż on sam. Brand firmowy budujecie przez portfolio przypadków, metodyki wdrożeniowe, certyfikaty. Klienci kupują sprawdzone procesy i referencje, nie wiarę w guru.

Marże? Średnie do wysokich, zależnie od poziomu specjalizacji branżowej.

Ryzyko? Niskie. Technologia sprawdzona, rynek istnieje, popyt przewidywalny.

Czas do pierwszych klientów? 3-6 miesięcy. Znacznie szybciej niż w tornadzie bo nie musicie budować autorytetu od zera - technologia już jest znana.

Zbywalność firmy? Wysoka. Brand firmowy, metodyki, portfolio - wszystko transferowalne. Nie jesteście zależni od jednej osoby.

Strategia Produkt Plus Jeden - bierzecie dojrzały projekt open-source i rozszerzacie go o brakujący element dla konkretnej niszy. Produkt/platforma staje się marką, nie osoba.

Przykład? Platforma handlu międzyfirmowego zbudowana na dojrzałym silniku. Marketing skupia się na produkcie i jego wartości biznesowej - ile oszczędza czasu, ile redukuje kosztów. Nie na tym kto to zrobił.

Marże? Wysokie. Produkt daje przewagę, możecie dyktować ceny przez wartość biznesową którą dostarczacie.

Czas do rynku? 6-12 miesięcy. Musicie najpierw zbudować ten produkt, potem go sprzedawać.

Zbywalność? Bardzo wysoka. Produkt jest głównym aktywem, nie osoba.

Model partnerski - stajecie się certyfikowanym partnerem dużego dostawcy technologii. Wykorzystujecie ich markę jako zastępcze zaufanie.

Tutaj jest elegancko bo błogosławieństwo od dużego dostawcy (Microsoft, Shopware, ktokolwiek) zastępuje wasz osobisty autorytet. Oni przynoszą początkowe zaufanie, wy budujesz na tym przez portfolio i metodyki firmowe.

Marże? Średnie, często dostawca ma swoje wyobrażenia o poziomie cen.

Ryzyko? Niskie. Dostawca przynosi leady, wy dostarczacie wykonanie.

Czas do klientów? 3-6 miesięcy, często szybciej bo leadsy płyną od vendora.

Które etapy rynku eliminuje brak osoby-twarzy?

Wczesny rynek i przepaść - całkowicie. Tu nie ma dyskusji. Bez zaufania osobistego nie przekonasz pierwszego pragmatycznego klienta że warto zaryzykować. To jest po prostu niemożliwe.

Kręgielnia (pierwsze 5-10 nisz) - bardzo trudne ale nie niemożliwe. Jeśli idziesz modelem partnerskim gdzie dostawca technologii przynosi initial trust, da się. Ale samodzielnie? Arcy trudne.

Kręgielnia (nisze 10-30) - już możliwe. Gdy macie mocne portfolio firmowe, osobisty brand przestaje być konieczny. Case studies mówią za was.

Tornado - możliwe ale z handicapem. Możecie wygrać pozycję drugą albo trzecią na rynku. Trudniej o pozycję numer jeden (goryl) bo tam osobiste zaufanie nadal dużo znaczy. Ale bycie drugim czy trzecim wcale nie jest złe... czasem nawet lepsze niż bycie pierwszym jeśli chodzi o marże względem wysiłku.

Główny rynek - tutaj wręcz może być lepiej bez osobistego brandu. Klienci kupują na podstawie procesów, portfolio, SLA, metodyk. Osobisty brand może być nawet postrzegany jako ryzyko (”a co jak ta osoba odejdzie?”).

To nie ograniczenie. To klaryfikacja.

Lęk przed byciem twarzą nie eliminuje szans na zbudowanie silnika wzrostu, ale całkowicie dyktuje KTÓRY silnik możecie wybrać. Rezygnujecie z szansy na spektakularny wzrost napędzany tornadem (CallStack przeszedł drogę od zera do sprzedaży za setki milionów w 8 lat).

Ale zyskujecie:

• Większą stabilność (sprawdzone technologie, nie eksperymenty)

• Lepszą powtarzalność (jasne wzorce, dostępne narzędzia, dojrzały ekosystem)

• Możliwość zbudowania firmy która może funkcjonować bez was (brand firmowy, nie osobisty)

• Szybsze pierwsze przychody (3-6 miesięcy vs 12-24)

Oba wybory są dobre.Ale tylko jeden jest WASZ.

Cztery pytania które rozstrzygają

Jeśli odpowiecie “nie” na którekolwiek z tych pytań, rzeczywistość A (wczesny rynek, tornado hunting) jest dla was zamknięta:

1. Czy macie w core teamie kogoś kto CHCE być rozpoznawalny jako ekspert w społeczności?

2. Czy ta osoba jest gotowa poświęcić 20-30% czasu na konferencje, artykuły, budowanie obecności publicznej?

3. Czy możecie zaakceptować że przez pierwsze 6-12 miesięcy ten wkład nie przyniesie bezpośrednich klientów?

4. Czy możecie zagwarantować, że ta osoba zostanie w firmie przez najbliższe 3-5 lat minimum?

Choć jedno “nie”? Idźcie rzeczywistością B.

Nie dlatego że jest gorsza. Dlatego że pasuje do tego kim jesteście. A dopasowanie strategii do DNA to różnica między latami walki w czerwonym oceanie gdzie każdy projekt to bitwa o stawkę, a spokojnym budowaniem przewagi w niszy gdzie klienci przychodzą bo wiedzą że jesteście najlepsi w tym co robicie.

Pytanie brzmi: w której rzeczywistości żyjecie?

Test Tornada w praktyce: Agentic Commerce Protocol - kiedy dwóch Goryli otwiera pusty tron

W poprzednich numerach pokazałem wam fundamenty: jak zdiagnozować DNA swojej firmy (#7), jak działa anatomia Tornada (#8), a dzisiaj - strategiczne wymiary wyboru OSS przez pryzmat Problemu, Timingu i Decydenta. Teraz połączmy to wszystko w jedną, praktyczną analizę projektu, który pojawił się zaledwie kilka dni temu i może zdefiniować następną dekadę e-commerce.

Kilka dni temu OpenAI i Stripe wypuściły wspólnie coś pozornie niewielkiego: Agentic Commerce Protocol. Open source. Apache 2.0 license. Już 640 gwiazdek i 68 forków.

Pozornie to tylko kolejny protokół. Ale gdy spojrzysz przez pryzmat wszystkiego co napisałem w tym numerze - Problem, Timing, Decydent, Personal Brand Tax - nagle widzisz coś innego. Widzisz coś co się zdarza raz na kilka lat: moment gdy dwóch gigantów otwiera nową kategorię i zostawia pusty tron dla kogoś innego.

Co właściwie się wydarzyło?

Wyobraź sobie scenariusz:

jesteś CTO średniej wielkości firmy e-commerce. Sprzedajecie ubrania sportowe. Dobrze wam idzie, ale ostatnio coraz częściej słyszysz o konkurencji, która “zintegrowała AI agents” z zakupami. Klienci mogą powiedzieć ChatGPT “kup mi buty do biegania, budżet 500 zł” i transakcja się dzieje. Bez przechodzenia na stronę, bez formularzy, bez friction.

Masz problem. Jasny, naglący problem biznesowy. Pytasz swojego Head of Engineering: “czy możemy to zrobić?”. On kiwa głową, ale mówi “musimy to zaprojektować od zera. Integracja z OpenAI, bezpieczne przekazywanie tokenów płatniczych, inventory management w czasie rzeczywistym, obsługa błędów... to może być pół roku pracy.”

Pół roku. Konkurencja już to ma. Nie możesz czekać.

I właśnie w tym momencie OpenAI i Stripe pokazują wam Agentic Commerce Protocol. Otwarty standard. Gotowe wzorce integracji. Referencyjne implementacje. Dokumentacja. To co miało być pół roku staje się trzema tygodniami.

To jest problem który ACP rozwiązuje. Nie jest to akademicki protokół stworzony w próżni. To jest odpowiedź na konkretny, palący ból tysięcy firm, które widzą jak rynek się zmienia i boją się zostać w tyle.

Dlaczego akurat teraz? Timing tej decyzji

Pamiętasz Developer Journey z pierwszego rozdziału? Te sześć etapów przez które przechodzi każda firma budując nowy system? Agentic Commerce Protocol trafia w najbardziej złoty moment jaki można sobie wyobrazić.

Firma jest w etapie zero lub jeden. Potrzeba biznesowa dopiero się pojawiła (”musimy mieć agentic commerce”) i lider technologiczny dopiero zaczyna badać jak to zrobić. Zespół deweloperski jeszcze nie dostał zadania “naucz się tego”. Budżet jeszcze nie został wydany. Architektura jeszcze nie została wybrana.

To jest moment maksymalnej otwartości na zewnętrzną pomoc. To jest moment gdy firma desperacko szuka kogoś kto już to zrobił, kto wie jak to zaprojektować, kto może ich przeprowadzić przez ten wybór.

Porównaj to z narzędziami deweloperskimi typu Cursor czy Claude Code, które analizowaliśmy wcześniej. Tam firma ma już zespół. Mówi im “nauczcie się tego narzędzia” i załatwione. Potrzebują może szkolenia, ale nie potrzebują agencji software która zbuduje im system.

Tutaj jest zupełnie inaczej. Tutaj potrzebują was. Na full projekt. Na arhitectural design. Na długoterminowe wsparcie. To nie jest szkolenie. To jest fundament ich następnej generacji systemu e-commerce.

Kto faktycznie podejmuje tę decyzję?

W pierwszym rozdziale pisałem o tym jak kluczowe jest zrozumienie nie tylko problemu i timingu, ale też kto jest decydentem ekonomicznym. Kto faktycznie powie “tak, robimy to” i podpisze budżet.

W przypadku Agentic Commerce Protocol mamy do czynienia z przełomem biznesowym, nie czysto technologicznym. To oznacza specyficzną dynamikę władzy w organizacji.

Inicjatorem jest zazwyczaj ktoś z biznesu. Head of E-commerce który wraca z konferencji i mówi “konkurencja właśnie pokazała że ich klienci mogą kupować przez ChatGPT, a my nawet nie zaczęliśmy o tym myśleć.” Albo CEO który czyta raport pokazujący że 40% ich “target audience” używa już AI assistants do researchu produktów.

Oni idą do CTO z pytaniem: “czy możemy to zrobić? ile to kosztuje? jak długo to potrwa?”. CTO musi nagle stać się ekspertem w czymś co jeszcze tydzień temu nie istniało jako kategoria. Patrzy na Agentic Commerce Protocol i widzi że OpenAI i Stripe już rozwiązali połowę problemów. Idzie z tym z powrotem do CEO i mówi “tak, możemy, ale potrzebujemy kogoś kto już to robił.”

Tutaj wchodzisz ty.

Ale żeby dostać ten kontrakt musisz przejść jeszcze przez jednego strażnika: Head of Security/Legal/Compliance. Oni mają prawo veta. Mogą zabić projekt jednym zdaniem: “to nie spełnia naszych wymogów compliance.” Ale tutaj masz przewagę. Bo Stripe jest maintainerem protokołu. A Stripe to firma której każdy payment team ufa. To jest twoja przepustka przez tę bramę.

Widzisz jak wszystkie elementy układają się w historię? Problem jest realny i naglący. Timing jest idealny - wczesny etap Developer Journey. Decydent jest jasny - biznes inicjuje, tech zatwierda, payment team nie blokuje. To jest recepta na wysokomarżowy, strategiczny projekt.

Czy to rewolucja czy tylko nowy sposób robienia starego?

Żeby zrozumieć dlaczego Agentic Commerce Protocol to przełom, a nie ewolucja, musimy cofnąć się o krok i zobaczyć jak do tej pory firmy próbowały rozwiązać problem integracji AI z e-commerce.

Metoda pierwsza: każdy budował to od zera. Custom integracja z API OpenAI, własny system do zarządzania sesją konwersacji, własny protokół do bezpiecznego przekazywania danych płatności między AI a backendem e-commerce. Efekt? Każda firma rozwiązywała te same problemy. Bezpieczeństwo. Prywatność. Inventory synchronization. Error handling. Setki zespołów pisały ten sam kod, każdy na swój sposób, każdy popełniając te same błędy.

To przypomina lata przed pojawieniem się standardów płatności online. Każdy sklep robił własną integrację z bankiem. Chaos. Wysoki koszt. Wysokie ryzyko.

Agentic Commerce Protocol zmienia to fundamentalnie. To nie jest “API do integracji z ChatGPT”. To jest otwarty standard który definiuje jak AI agents, firmy e-commerce i payment providers rozmawiają ze sobą. Niezależnie od tego czy używasz OpenAI, Anthropica, czy własnego modelu - protokół jest ten sam. Niezależnie od tego czy płatności obsługuje Stripe, Adyen czy ktoś inny - protokół jest ten sam.

Zmienia to ekonomię całego rynku. Nagle integracja która kosztowała pół roku i dziesiątki tysięcy dolarów staje się tygodniem pracy i kilkoma tysiącami. Ale co ważniejsze - zmienia to kto wygrywa. Bo zwycięzcą nie jest już ten kto pierwszy zbudował integrację. Zwycięzcą jest ten kto najlepiej rozumie biznes klienta i potrafi najszybciej dostarczyć kompletne rozwiązanie używając standardu.

To jest dokładnie ten sam moment co pojawienie się React Native w świecie mobile. Przed React Native trzeba było mieć dwa zespoły, dwie bazy kodu, podwójny czas developmentu. Pojawienie się React Native zmieniło zasady gry. Nagle liczyło się kto najlepiej rozumiał cross-platform architecture i potrafił dostarczyć aplikację na obie platformy szybciej niż konkurencja.

Pamiętasz Callstack z numeru 6? Oni nie byli pierwszymi którzy używali React Native. Ale stali się Gorylem Usługowym bo jako pierwsi zbudowali kompletną ofertę wokół tej technologii. Mieli metodyki, wzorce, case studies, technical thought leadership.

Teraz masz dokładnie taki sam moment z Agentic Commerce Protocol. Nie musisz być pierwszym który go użył. Musisz być pierwszym który zbuduje wokół niego kompletną, powtarzalną ofertę dla określonej niszy.

Jak głęboka jest prawdziwa fosa kompetencyjna?

Tutaj musisz być bardzo ostrożny. Bo na pierwszy rzut oka Agentic Commerce Protocol wygląda prosto. Dokumentacja jest przystępna. OpenAPI spec jest czytelny. Stripe i OpenAI mają referencyjne implementacje. Junior developer może w weekend zbudować demo które działa.

I to jest właśnie pułapka.

Bo demo to nie produkcja. A produkcja w e-commerce to zupełnie inny poziom złożoności. To tutaj zaczyna się prawdziwa fosa.

Pomyśl o rzeczywistych pytaniach które zadaje klient: “Co się stanie gdy AI agent złoży zamówienie ale inventory zmieni się w między czasie? Jak obsługujemy zwroty inicjowane przez AI? Jak robimy A/B testing konwersji gdy transakcja dzieje się poza naszą stroną? Jak integrujemy to z naszym CRM? Jak śledzimy customer journey który zaczyna się w ChatGPT a kończy w naszym magazynie? Jak zapewniamy compliance z GDPR gdy dane płyną przez trzech pośredników?”

To nie są akademickie pytania. To są pytania które decydują czy projekt się uda czy nie. I tu jest właśnie miejsce gdzie większość firm się zatrzymuje. Zrobili demo. Pokazali że “działa”. A potem zderzają się z rzeczywistością produkcji i okazuje się że nie mają pojęcia jak rozwiązać te problemy.

Ty jako Software House możesz być tym który te problemy już rozwiązał. Nie dla wszystkich branż - to byłby błąd. Ale dla jednej konkretnej niszy. Dla fashion e-commerce. Albo dla home decor. Albo dla B2B industrial supplies. Wybierz jedną niszę i stań się niekwestionowanym ekspertem który wie jak zaimplementować ACP w tej konkretnej branży, z jej specyficznymi wymogami, z jej specyficznymi workflow, z jej specyficznymi problemami.

To nie jest fosa technologiczna jak w przypadku Rust, gdzie sam język jest barierą. To jest fosa domenowa - kombinacja zrozumienia protokołu plus głęboka wiedza o konkretnej niszy biznesowej. I to jest właśnie typ fosy który pozwala na premium marże bez wymuszania na tobie bycia gwiazdą konferencji technologicznych.

Jak szerokie może być to tornado?

To jest kluczowe pytanie strategiczne. Bo możesz znaleźć idealną technologię, idealny timing, ale jeśli rynek jest za mały to nigdy nie zbudujesz Goryla Usługowego. Zostaniesz wysokomarżowym butikiem - co nie jest złe, ale to nie jest Goryl.

Z Agentic Commerce Protocol mamy ciekawą sytuację. Problem który rozwiązuje - integracja AI agents z transakcjami - jest uniwersalny dla praktycznie każdej firmy która sprzedaje cokolwiek online. Fashion, electronics, home decor, B2B supplies, digital products, subscriptions, tickets. Każda z tych branż prędzej czy później będzie musiała zintegrować agentic commerce.

To jest ogromny, horyzontalny rynek. Setki tysięcy firm e-commerce na świecie. Ale tutaj pojawia się kluczowe rozwidlenie strategiczne.

Możesz próbować być generalistą - “robimy agentic commerce dla każdego”. To prowadzi prosto do walki cenowej. Bo każdy inny Software House może powiedzieć to samo. Nie masz przewagi. Nie masz fosy. Konkurujesz na Upwork z zespołami które zrobią to taniej.

Albo możesz wybrać jedną niszę wertykalną i stać się jej niepodważalnym ekspertem.

“Najlepsi na świecie w agentic commerce dla premium fashion brands.”

Nagle nie konkurujesz z setkami agencji. Konkurujesz z może trzema, czterema które też wybrały tę niszę. A jeśli będziesz pierwszy który zdobędzie referencje od Gucciego, Prady, czy chociaż mniejszych premium brandów - stajesz się oczywistym wyborem dla każdego kolejnego.

Szerokość potencjalnego tornado jest więc gigantyczna - każda firma e-commerce. Ale twoja strategia musi być wąska - jedna konkretna nisza. To jest klasyczna Kręgielnia opisana przez Geoffrey’a Moore’a. Zdobywasz jeden kręgiel (premium fashion), potem kolejny logicznie powiązany (luxury accessories), potem kolejny (high-end home decor). Nisza po niszy, budując portfolio referencji i ekspertyzy.

Błąd który widzę w większości Software House’ów to próba zdobycia wszystkich kręgielni naraz. To prowadzi do rozmycia ekspertyzy, braku referencji w jakiejkolwiek niszy, i w efekcie - walki cenowej.

Gdy dwóch Goryli otwiera rynek

Teraz najważniejsze pytanie: czy rynek jest gotowy? Czy pragmatycy - te duże, ostrożne firmy które stanowią większość rynku - zaczną wdrażać agentic commerce?

Odpowiedź leży w tym kto za tym projektem stoi. I tutaj mamy coś niezwykłego.

OpenAI i Stripe. Razem. Jako współmaintainerzy otwartego standardu.

Pomyśl co to oznacza dla CTO który musi sprzedać ten projekt swojemu CEO. “Chcę zainwestować ćwierć miliona dolarów w nową, nieprzetestowaną technologię.” CEO pyta: “kto za tym stoi?”. CTO odpowiada: “OpenAI - lider w AI - i Stripe - lider w płatnościach. Razem stworzyli otwarty standard.”

To jest błogosławieństwo z absolutnego szczytu piramidy. Nie ma silniejszego sygnału dla pragmatycznego rynku. To nie jest startup z Doliny Krzemowej który za rok może nie istnieć. To są dwa Goryle, każdy w swojej domenie, które mówią: “to jest standard przyszłości, budujcie na nim.”

Pamiętasz z numeru 8 jak opisywałem rolę Goryli w uruchamianiu Tornada? Pragmatycy czekają na sygnał że technologia jest bezpieczna. Ten sygnał może przyjść tylko od kogoś kto ma ich bezwarunkowe zaufanie. W przypadku AI agents to OpenAI. W przypadku płatności to Stripe. Gdy ci dwaj mówią razem - wahanie znika.

I tu jest właśnie twoja szansa. Bo Goryle otworzyły rynek, ale nie będą go obsługiwać. OpenAI nie zbuduje implementacji dla każdej branży e-commerce. Stripe nie stworzy portfolio studiów przypadku dla fashion, electronics, B2B. Oni zbudowali infrastrukturę. Stworzyli standard. Ale zostawili przestrzeń - ogromną, lukratywną przestrzeń - dla Goryla Usługowego który będzie implementował ten standard dla konkretnych nisz.

Gdzie dokładnie jesteśmy teraz? Timing jest wszystkim

Wiesz już że problem jest realny, że dwóch Goryli go zatwierdza, że szerokość rynku jest ogromna. Ale to wszystko nic nie znaczy jeśli jesteś za wcześnie albo za późno.

Za wcześnie - to są lata samotnej pracy bez klientów, próby edukacji rynku który jeszcze nie jest gotowy słuchać. Za późno - to są lata walki z ugruntowaną konkurencją która już zajęła wszystkie dobre pozycje.

Z Agentic Commerce Protocol jesteśmy w idealnym momencie. Projekt jest w statusie “draft”. To znaczy że standard jeszcze się formuje, jeszcze nie jest wykuty w betonie. Możesz wpływać na jego kształt. Możesz być częścią dyskusji. Już jest 68 forków - to sygnał że ludzie eksperymentują, testują, próbują zrozumieć jak to zastosować w swoich kontekstach. Ale jeszcze nie ma masowej adopcji. Jeszcze nie ma setki agencji które mówią “jesteśmy ekspertami od ACP.”

To jest klasyczna faza którą Geoffrey Moore nazywa “early bowling alley” - jest kilka pierwszych kręgielni które zostały zdobyte (OpenAI i Stripe mają swoje implementacje), ale większość kręgielni wciąż stoi nietknięta. Rynek widzi że coś się dzieje. FOMO zaczyna się budować. Ale większość wciąż czeka - czeka na sygnał że to bezpieczne, czeka na referencje, czeka na kogoś kto powie “my to już wdrożyliśmy i działa.”

Ty możesz być tym kimś. Nie dla całego rynku - to niemożliwe. Ale dla jednej niszy. Dla premium fashion możesz być pierwszym który ma study case, który ma working implementation, który pokazuje ROI. I wtedy każdy kolejny brand w tej niszy przyjdzie do ciebie bo jesteś oczywistym, bezpiecznym wyborem.

Tornado jeszcze nie nastąpiło. Ale fronty atmosferyczne już się zbierają. Presja rośnie. Każdy CEO w e-commerce czyta te same artykuły o AI agents transformujących retail. Każdy CTO wie że musi coś z tym zrobić. Brakuje tylko tego jednego elementu - kompletnej, sprawdzonej oferty usług wokół standardu.

To może być twoja oferta. Ale okno jest ograniczone czasowo. Za sześć miesięcy będzie pięć innych agencji które próbują to samo. Za rok będzie dwadzieścia. Za dwa lata jeden z nich będzie Gorylem a reszta będzie walczyć o resztki. Pytanie brzmi: czy będziesz tym Gorylem?

Czy tron usługowy jest zajęty?

Spojrzałem na ekosystem wokół Agentic Commerce Protocol szukając tego samego co zawsze - czy jest już ktoś kto ma niepodważalną pozycję? Kto jest Gorylem Usługowym dla ACP?

Odpowiedź jest prosta i brutalna: nie ma nikogo.

Jest kilka agencji które już mają pierwsze projekty z AI agents w commerce. Ale żadna z nich nie skupiła się wyłącznie na ACP. Żadna nie ma portfolio studiów przypadku pokazujących “tak wdrażamy ACP w różnych niszach.” Żadna nie ma publicznych contributions do standardu które budowałyby ich autorytet. Żadna nie mówi głośno “jesteśmy THE ekspertami od Agentic Commerce Protocol.”

Tron jest pusty. Kompletnie, totalnie pusty.

Ale nie zostanie pusty długo. Protokół jest za atrakcyjny, backing jest za mocny, timing jest za dobry. Ktoś ten tron zajmie. Pytanie tylko kto i kiedy.

I tu jest właśnie przewaga działania teraz, szybko, zdecydowanie. Nie musisz być najlepszym technicznie. Nie musisz mieć największego zespołu. Musisz być pierwszym który powie głośno “to jest nasza specjalizacja” i który zbuduje portfolio referencji szybciej niż konkurencja zdąży zareagować.

Personal Brand Tax - ile musisz zapłacić?

Wróćmy do kluczowego pytania z trzeciego rozdziału: czy Agentic Commerce Protocol wymaga od ciebie bycia twarzą? Czy musisz stać się tym ekspertem który jest na każdej konferencji, który pisze technical blog, który kontrybuuje do core projektu?

Odpowiedź jest subtelna i bardzo ważna: to zależy którą ścieżkę wybierzesz.

Pamiętasz dwa archetypy z numeru 7? Architekt Principal i Ekspert Domenowy? Ten wybór tutaj ma fundamentalne znaczenie.

Jeśli chcesz iść ścieżką Architekta Principal - być ekspertem od samej technologii, od samego protokołu - wówczas Personal Brand Tax jest WYSOKI. Musisz być rozpoznawalny w community. Musisz kontrybuować do projektu. Musisz być tym do którego przychodzą z technicznymi pytaniami o edge cases w protokole. To wymaga czasu, obecności, konsystencji. To wymaga osoby która CHCE być tą twarzą.

Ale jest druga ścieżka. Ścieżka Eksperta Domenowego. I tu jest piękno tego przypadku.

Możesz być ekspertem nie od protokołu, ale od niszy biznesowej. “Najlepsi w agentic commerce dla premium fashion brands.” Twój Personal Brand Tax jest wtedy ŚREDNI, nie WYSOKI. Nie musisz kontrybuować do ACP. Nie musisz być na konferencjach technicznych. Musisz być ekspertem w swojej niszy biznesowej - fashion e-commerce. Musisz rozumieć ich problemy, ich workflow, ich customer journey, ich specifics.

ACP jest wtedy narzędziem które używasz, ale nie jesteś od niego ekspertem. Jesteś ekspertem od rozwiązywania problemów premium fashion brands, a ACP to po prostu najlepsze narzędzie do tego celu w 2025 roku.

Ta różnica jest kluczowa. Bo większość Software House’ów nie ma osoby która chce i może zapłacić wysoki Personal Brand Tax. Nie ma kogoś kto chce być gwiazdą technologii. Ale większość ma kogoś kto może stać się ekspertem w określonej niszy biznesowej. To wymaga innego typu wiedzy, innego typu pracy, ale jest osiągalne dla znacznie szerszego grona firm.

I tu jest właśnie magia Agentic Commerce Protocol. To nie jest czysto technologiczny przełom jak Rust czy Temporal. To jest przełom który łączy technologię z biznesem. Możesz wygrać koncentrując się na którejkolwiek ze stron - albo na technologii (wysoki Personal Brand Tax), albo na biznesie (średni Personal Brand Tax).

Ale musisz wybrać. Nie możesz być “trochę ekspertem od ACP i trochę ekspertem od fashion.” Musisz wybrać jedną ścieżkę i na niej zbudować swoją pozycję.

Które pytania musisz sobie zadać?

Jeśli wybierasz ścieżkę technologiczną (Architekt Principal):

• Czy masz kogoś kto CHCE być rozpoznawalny jako ekspert od ACP?

• Czy ta osoba może poświęcić 20-30% czasu na community, content, contributions?

• Czy możesz przetrwać 6-12 miesięcy budując autorytet zanim przyjdą pierwsi klienci?

Jeśli wybierasz ścieżkę biznesową (Ekspert Domenowy):

• Czy możesz wybrać JEDNĄ niszę i skupić się tylko na niej przez najbliższe 12-24 miesiące?

• Czy macie kogoś kto rozumie (albo może się nauczyć) tę niszę biznesową bardzo głęboko?

• Czy możecie zbudować case study w tej niszy nawet jeśli pierwszy projekt będzie “po kosztach”?

Żadna ścieżka nie jest lepsza. Ale żadna nie jest też łatwa. Wybierz tę która pasuje do tego kim jesteście jako firma.

---

Analiza Forków - za wcześnie na prawdziwe sygnały

Protokół został opublikowany 28 września 2025 - to zaledwie 10 dni temu. Za wcześnie żeby forki pokazywały prawdziwe sygnały adopcji. Obecne 68 forków to głównie:

• Zespół Stripe - pracuje nad przykładami implementacji

• Zespół OpenAI - buduje reference implementations

• Wczesni adoptatorzy - eksperymentują z protokołem

To nie są jeszcze sygnały “produkcyjnej adopcji” które pokazałem w numerze 8. To są sygnały “wczesnego eksperymentowania” - co jest normalne i oczekiwane dla technologii która ma 10 dni.

Ale jest coś znacznie ważniejszego niż forki.

Spójrz na 8 issues w repozytorium. Dużo z nich dotyka konkretnych problemów biznesowych:

• “Support for Restaurant/Food Ordering Use Cases”

• “Add Subscription & Recurring Payment Support”

• “Pickup fulfillment option”

• “Merchant UI Customization”

To nie są pytania techniczne typu “jak zaimplementować X w protokole.” To są pytania biznesowe typu “jak rozwiązać problem Y w mojej branży.”

I tu jest złota żyła dla Software House’ów. Te issues to idealne źródło wiedzy o tym czego rynek naprawdę potrzebuje. Każdy issue to sygnał że ktoś ma konkretny problem biznesowy i szuka rozwiązania. To są twoi przyszli klienci, którzy już teraz mówią ci czego potrzebują.

I tu jest kluczowa różnica. W tradycyjnych projektach OSS (jak React, Vue, Angular) issues to głównie:

• Bug reports

• Feature requests techniczne

• Performance improvements

• API design discussions

W ACP issues to głównie:

• “Jak wdrożyć to w mojej branży?”

• “Czy protokół obsługuje mój use case?”

• “Jakie są best practices dla mojego typu biznesu?”

To potwierdza dokładnie to co napisałem wcześniej - ACP to nie jest przełom technologiczny, to jest przełom biznesowy.

Ludzie nie pytają “czy to działa?” - pytają “czy to rozwiąże mój problem biznesowy?” To jest fundamentalna różnica która pokazuje że rynek jest gotowy na rozwiązanie, nie na technologię.

Za 6 miesięcy będziemy mogli przeanalizować prawdziwe forki - te które pokażą kto rzeczywiście wdraża ACP w produkcji, jakie problemy napotykają, jakie features dodają. Wtedy będziemy mieli prawdziwe sygnały adopcji.

Ale już teraz mamy sygnał że rynek ma problem który ACP rozwiązuje. I to jest znacznie ważniejsze niż forki.

---

Podsumowanie: czy to jest twoja szansa?

Przeczytałeś właśnie pełną analizę Agentic Commerce Protocol przez pryzmat wszystkich wymiarów które pokazałem w tym numerze i w poprzednich.

Problem? Realny, naglący, dotyka tysięcy firm które widzą jak ich konkurencja wdraża AI agents.

Timing? Idealny. Developer Journey etap 1-2, protokół w draft status, rynek czeka na sygnał że to bezpieczne.

Decydent? Jasny. Biznes inicjuje, tech weryfikuje, payment team nie blokuje bo Stripe daje confidence.

Błogosławieństwo Goryli? Platynowe. OpenAI + Stripe to najsilniejszy możliwy sygnał dla rynku.

Tron usługowy? Pusty. Kompletnie, totalnie pusty.

Personal Brand Tax? ŚREDNI dla ścieżki biznesowej, WYSOKI dla ścieżki technologicznej. Możesz wybrać.

To jest wzorcowy przykład technologii która spełnia wszystkie wymiary strategicznego wyboru OSS dla Software House. Ale - i to jest kluczowe - okno czasowe jest ograniczone.

Za pół roku będzie znacznie trudniej. Za rok może być za późno żeby zostać Gorylem. Wtedy zostanie ci walka o drugą pozycję, o bycie jednym z wielu dostawców.

Pytanie które musisz sobie teraz zadać nie brzmi “czy to jest dobra technologia” - odpowiedź jest oczywista: tak.

Pytanie brzmi: “czy jesteśmy gotowi działać TERAZ, szybko, zdecydowanie?”

Gotowi wybrać jedną niszę i skupić się tylko na niej?

Gotowi zbudować pierwszy case study nawet jeśli będzie to po kosztach?

Gotowi powiedzieć głośno “to jest nasza specjalizacja” zanim zrobi to ktoś inny?

Jeśli odpowiedź jest “tak” - masz przed sobą historyczną szansę. Może nie w skali Callstack i React Native. Ale definitywnie szansę na zbudowanie wysokomarżowego, skalowalnego biznesu wokół technologii która będzie rosła przez następną dekadę.

Jeśli odpowiedź jest “nie” albo “nie jesteśmy pewni” - nie ma w tym nic złego. Czasem najlepsza strategia to poczekać aż rynek się ustabilizuje, aż pierwszy Goryl się pojawi, aż będzie jasne że to działa. Wówczas możesz wejść na niżej wiszący owoc, na drugą czy trzecią pozycję, na niszę którą Goryl zignorował.

Obie drogi są dobre. Ale musisz wybrać świadomie, nie przypadkiem.

---

W następnym numerze: Lista technologii które są w podobnej fazie co ACP - wczesna adopcja, pusty tron, błogosławieństwo Goryli - ale z różnymi poziomami Personal Brand Tax. Plus: framework do systematycznego scoringu każdej technologii w 15 minut.

Do zobaczenia za dwa tygodnie.