O czym jest ten film
- Autor ogłasza przekroczenie miliona dolarów ARR (rocznych przychodów subskrypcyjnych) produktem zbudowanym przy pomocy Claude Code — Clarivo, czyli power dialerem wspomaganym AI dla branż, które żyją sprzedażą telefoniczną.
- Ekonomia wybranego problemu: bardzo wysoka wartość życiowa klienta, minimalny churn, bo narzędzie wpija się w infrastrukturę całej firmy, oraz słabo obsadzona konkurencją nisza.
- Metoda „kopania pomysłów”: dziesięć równoległych podagentów generuje po dziesięć odmiennych mechanizmów poprawy metryki, z wymuszoną dywergencją i zakazem autocenzury; z 200–300 pomysłów kilka okazuje się złotych.
- Zwycięskie rozwiązanie — pacing predykcyjny: równoległe wybieranie kilku numerów z przesunięciami czasowymi, plus routing rozmów; parametry doszlifowane na symulacjach karmionych danymi historycznymi (optymalizacja bayesowska).
- Uniwersalna pętla pracy: zdefiniuj problem → wypisz z modelem wszystkie rozwiązania → odfiltruj sam → zasymuluj → iteruj parametry → wdróż na żywo; na każdym etapie projekt może się wywrócić.
- Cennik metodą „podnoś, aż zrobi się trudno”: start od około 100 USD, obecnie 250 USD miesięcznie; sprzedaż zespołowa, gdzie umowa na 100 stanowisk to 25 tys. USD MRR.
- Teza o frameworkach: każdy kolejny framework agentowy koreluje ujemnie z zarabianiem; inteligencja mieszka w samym modelu, a nie w oprawce — wolać 90% sprawności zawsze niż 100% zrywami.
- Dobór problemu: celować wyłącznie w palące potrzeby branż z dużymi budżetami; „letnie” problemy (aplikacje typu to-do) przegrywają, bo każdy potrafi dziś odbudować sobie takie narzędzie za koszt tokenów.
- Wycena od wypracowanej wartości: klient z ośmiocyfrowymi przychodami zyskał 66% przychodów miesięcznie (ok. 24 mln USD rocznie), co uzasadnia negocjację 10–15% tej kwoty.
- Dwie fosy na przyszłość: regulacje (rejestracja A2P, HIPAA) wraz z ludzkim wdrożeniem oraz baza kodu niezależna od modelu, z zduplikowanymi specyfikacjami dla Claude Code, Codex i Gemini.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Kop pomysłów z modelu na maksa, oceń je sam
Na czym polega: Przeważająca część pomysłów wygenerowanych przez model to balast — siła metody leży w skali i wymuszonej różnorodności. Autor zlecał dziesięciu podagentom wymyślenie po dziesięć odmiennych mechanizmów, każąc im rozjechać się w kierunkach algorytmicznych, behawioralnych, infrastrukturalnych, regulacyjnych, psychologicznych, czasowych i tożsamościowych, bez cenzurowania wykonalności.
Jak stosować: Prompt w duchu: „Budujemy X. Nasza główna metryka to Y, zdefiniowana jako…, oto wynik bazowy, sufit branżowy i cel. Uruchom 10 podagentów, każdy proponuje 10 mechanizmów, maksymalnie się rozjednijcie, nie odsiewajcie pomysłów pod kątem wykonalności”. Potem czytasz listę od góry do dołu i dzielisz na śmieci oraz kandydatów.
Na co uważać: Z góry załóż, że 90–95% propozycji odpadnie, a spora część to twarde duplikaty. Nie myl efektowności promptu z wartością pomysłu — „regresja odebrań względem hiperlokalnej pogody” wyglądała naukowo, a wartości nie miała żadnej.
2.Zanim zbudujesz, zasymuluj na prawdziwych danych
Na czym polega: Zwycięski algorytm pacingu najpierw działał w środowisku symulacyjnym karmionym historycznymi czasami połączeń; przesunięcia między równoległymi numerami dobierała optymalizacja bayesowska, np. dla partii 50 tysięcy rozmów.
Jak stosować: Zbierz logi połączeń (własne lub klienckie — za zgodą), każ Claude zbudować symulator według specyfikacji, wskaż cel optymalizacyjny i licz parametry na danych, dopiero potem przenoś do produkcji.
Na co uważać: Symulacja to nie rzeczywistość. Autor wielokrotnie widział podejścia świetne „w symie”, które po wdrożeniu rozsypywała trzecia, niezauważona zmienna. Dostęp do danych historycznych jest przy tym przewagą, której startujący od zera po prostu nie mają.
3.Pętla: problem → pomysły → ludzki filtr → symulacja → wdrożenie
Na czym polega: Claude Code może pomóc zdefiniować problem i wypisać rozwiązania, ale krok odsiewania jest nieredukowalnie ludzki — z kilkuset propozycji realnych było może pięć, sześć.
Jak stosować: Zacznij od problemu, za który ludzie już płacą; każ modelowi wyliczyć wszystkie drogi rozwiązania; wybierz garstkę wykonalnych; zbuduj symulację; iteruj parametry; na końcu test na żywym biznesie.
Na co uważać: Pętla potrafi się wywalić na każdym kroku i najczęściej winne są założenia, nie kod. Gdyby było łatwo, robiłby to każdy — a wtedy nikt by na tym nie zarabiał.
4.Cennik: podnoś, aż poczujesz opór
Na czym polega: Zamiast statystycznych modeli wyceny autor zaczął od około 100 USD miesięcznie i podnosił cenę, dopóki klienci zgadzali się bez wahania — dziś to 250 USD, uznawane za wartość.
Jak stosować: Wystaw cenę, sprzedawaj i obserwuj łatwość domykania. Gdy sprzedaż zaczyna robić się trudna, zbliżasz się do pułapu. To bezpośrednio działa przy sprzedaży B2B z wdrożeniem.
Na co uważać: Nie ustawiaj sztucznie niskiej ceny „na start” — późniejsze podniesienie jej kosztuje więcej niż wejście z wyższej. Skomplikowane modele wyliczania „optymalnej ceny” AI zwykle zawodzą.
5.Uciekaj od taniego, samoobsługowego SaaS — buduj tam, gdzie wdrożenie robi człowiek
Na czym polega: Skoro każdy może „przetworzyć tokeny na produkt”, tani low-touch SaaS za 5–20 USD będzie masowo odbudowywany przez klientów albo zmielony przez kolejne generacje modeli. Autor wybrał przeciwny kraniec spektrum: high-touch, blisko enterprise.
Jak stosować: Celuj w średni rynek i wyżej, w sprzedaż na całe zespoły. Przykład z filmu: 100 stanowisk razy 250 USD to 25 tys. dolarów MRR, czyli 300 tys. ARR z jednej umowy.
Na co uważać: High-touch oznacza kosztowną obsługę i dłuższy cykl sprzedaży; bez zasobów na wdrożenia model się nie spina.
6.Frameworki to puch — inteligencja siedzi w modelu
Na czym polega: Zespół przetestował kilkadziesiąt podejść (m.in. frameworki agentowe, biblioteki zarządzające kontekstem, wektorowe bazy pamięci) i wniosek jest bezlitosny: każdy dodatkowy framework ujemnie koreluje z zarabianiem, bo rozprasza i psuje ustabilizowane zachowania modelu. Twórcy Claude Code trzymają puste pliki konfiguracyjne — opierają się na czystej inteligencji modelu.
Jak stosować: Zwykły model plus dobra, stabilna konfiguracja projektu. Zamiast gonić stuprocentową jakość, wybierz 90% potencjału, ale za każdym razem tak samo.
Na co uważać: Zmiana frameworku to nie tylko koszt wdrożenia, ale regresje: model zaczyna „rozumieć” prompt inaczej i traci zakumulowaną wiedzę o kodzie. Marginalne ulepszenia frameworkowe i tak wchłania kolejna generacja modelu, często w kilka dni.
7.Wybieraj problemy, które realnie bolą i mają budżet
Na czym polega: Zbiór rzeczy możliwych do zbudowania jest dziś praktycznie nieograniczony; pieniądze leżą w wąskim wycinku, za który ludzie płacą: palące problemy, branże z budżetami, ugruntowany od lat ból.
Jak stosować: Test kondycjonalny: czy problem kosztuje klienta miliony rocznie? Czy różnica „bez narzędzia / z narzędziem” to kilkukrotność wyników? Clarivo wychodził od trzykrotności klasycznego dialera i celował w kolejne dwukrotności.
Na co uważać: 90% ludzi buduje „letnie” problemy — wygodne do demo, złe w biznesie. Jeśli problem jest mały, klient prędzej czy później odbuduje rozwiązanie sam, za tokeny.
8.Wyceniaj od wypracowanej wartości, nie od kosztów
Na czym polega: Klient z ośmiocyfrowymi przychodziami zyskał dzięki wdrożeniu 66% przychodów miesięcznie — około 2 mln USD miesięcznie, 24 mln rocznie. Za rozwiązanie takiego kalibru można negocjować 10–15% twardej wartości, czyli w tym wypadku około 2,4 mln dolarów rocznie.
Jak stosować: Mierz efekt u klienta (przychody, oszczędności) i licz cenę od delty. Przygotuj dane, nie deklaracje — i zawsze doprecyzuj horyzont czasowy pomiaru.
Na co uważać: Wymaga to dostępu do metryk klienta i rzetelnego pomiaru. W materiale sam autor musiał prostować własny slajd: pokazywał „rok”, a chodziło o miesiąc — o rząd wielkości łatwo tu pomylić w obie strony.
9.Regulacje to naturalna fosa, której AI nie przeskoczy
Na czym polega: Model nie przeprowadzi za Ciebie rejestracji A2P dla numerów ani nie zdjąć wymogów HIPAA w ochronie zdrowia — i z powodów etycznych, i konstrukcyjnych odmówi. Firmy, które potrafią te procedury przejść szybko (relacje, certyfikacje, ludzki onboarding), mają fosę na świat, w którym budowanie stało się banalne.
Jak stosować: Celuj w kategorie wymagające certyfikacji, zgód, ludzkiego wdrożenia; buduj sieć kontaktów z ludźmi, którzy te procesy przyspieszają. Przeszkoda regulacyjna, na którą narzekają wszyscy, to jednocześnie bariera wejścia dla konkurencji.
Na co uważać: Zgodność kosztuje: anonimizacja danych, audyty, dłuższy czas wdrożenia. To cena fosy, nie bonus — trzeba ją wliczyć w model biznesowy.
10.Trzymaj bazę kodu niezależną od modelu
Na czym polega: Jakość, dostępność i ekonomika tokenów modeli będą się wahać (presja na moc obliczeniową rośnie). Zespół autora arbitrażuje koszty — DeepSeek przy całodobowych zadaniach porządkowych, coraz częściej Codex — a kod ma zduplikowane specyfikacje konfiguracyjne (agents.md, pliki dla Gemini), by móc się przełączyć w każdej chwili.
Jak stosować: Zduplikuj pliki konfiguracyjne dla poszczególnych platform, pozwól Claude przygotować przestrzeń roboczą do natychmiastowego przełączenia i daj każdemu w zespole prawo zmiany modelu ad hoc.
Na co uważać: Platformy różnie interpretują specyfikacje skillek i MCP — np. nie wszystkie ładują tylko nazwę i opis z front matter YAML; niektóre czytają całość. Te drobne różnice trzeba ręcznie ujednolicić.
Redakcyjne tłumaczenie
Milion dolarów ARR — i dialer, który to zrobił
Właśnie przekroczyliśmy milion dolarów ARR z naszym produktem SaaS, zbudowanym przy pomocy Claude Code. Wiem, że sporo z Was chciałoby użyć tego narzędzia — samodzielnie albo w swojej firmie — żeby złożyć jakąś aplikację i wypuścić ją na rynek. Dlatego przeprowadzę Was przez wszystko, co zrobiliśmy, żeby dojść tam, gdzie chcieliśmy, i podzielę się wnioskami zebranymi po drodze.
Czym jest ten produkt? Nazywa się Clarivo i to power dialer wspomagany sztuczną inteligencją — inaczej mówiąc, system, który pozwala wykonać więcej telefonów w tej samej jednostce czasu i sprawić, żeby więcej z nich zostało odebranych. Świetnie sprawdza się w branżach, które od zawsze żyją telefonem: gdy masz leady przychodzące i musisz do nich dzwonić szybko i masowo, albo gdy uprawiasz klasyczną sprzedaż do obcych ludzi (cold calling), z którymi nic wcześniej nie łączyło Twojej firmy.
(Informacja dodatkowa: w automatycznej transkrypcji nazwa produktu pojawia się w kilku wariantach zapisu — Clarivo, Clara, Clarvo itd.; w tekście ujednolicona jako „Clarivo”.)
Każdy biznes — SaaS, e-commerce, firma usługowa, cokolwiek — trzeba zaczynać od jasno zdefiniowanego problemu. Jak dokładnie go wybraliśmy, pokażę niżej, ale w skrócie: postawiliśmy na bardzo wysoką wartość życiową klienta, czyli na to, że pojedynczy klient przez kolejne lata zapłaci nam dużo pieniędzy. Na bardzo niski odsetek rezygnacji — raz wpięci w nasze narzędzie, klienci raczej się nie wycofają, bo cała ich infrastruktura na nas stoi. I wreszcie na coś, co w niedoobsadzonej konkurencją niszy dało się zrobić prosto.
Ekonomia nieodebranych telefonów
Żeby było jasne, o co walczymy: konkurent w tej branży wykonuje może sto telefonów na godzinę — wychodzących, żeby domknąć interes z ludźmi, których nigdy nie widział, albo przychodzących, gdy dzwoni się do listy osób, które zgłosiły się na jakąś ofertę. Z tej setki, przez czas wybierania, czas łączenia, nieobecność ludzi i nieodbieranie nieznanych numerów, realnie odbiera ledwie około 40%. Handlowiec więc dzwoni sto razy, odbiera czterdzieści osób — i już na starcie potencjał spada dwuipółkrotnie. Policzmy dalej: osiem godzin pracy dziennie, czterdzieści odebranych na godzinę — ile to realnych rozmów w miesiąc? Taki handlowiec zarabia jakieś dziesięć tysięcy dolarów miesięcznie.
Clarivo robi dwie rzeczy. Po pierwsze, pozwala wykonać więcej telefonów na wejściu — powiedzmy dwieście zamiast stu na godzinę. Po drugie, podnosi odsetek odebranych, bo połączenia stają się lepiej rozpoznawalne. Dokładamy do tego kilka algorytmów zbudowanych z Claude Code: równoległe wybieranie kilku numerów naraz oraz — w razie potrzeby — ponawianie połączeń drugi i trzeci raz. Efekt końcowy: na linii siedzi wyraźnie więcej żywych ludzi, a to wprost przekłada się na pieniądze. Firmom, z którymi pracujemy, poprawiamy wyniki o 50–80%. Jednej sporej firmie z Teksasu, robiącej trzy do pięciu milionów dolarów miesięcznie, pozwoliliśmy niemal podwoić przychody.
Skąd wziąć rozwiązanie, kiedy samemu nie wiadomo jak
Uczciwie przyznaję: gdy zaczynaliśmy, nie mieliśmy pojęcia, jak ten problem rozwiązać. Kazaliśmy więc Claude wypisać każdy znany mu sposób na podniesienie odsetka odebranych rozmów i zwiększenie liczby połączeń w jednostce czasu. Przeważająca część pomysłów była do wyrzucenia. Ale po wykopaniu dwustu, trzystu propozycji kilka okazało się naprawdę dobrych.
Sam prompt wyglądał mniej więcej tak: „Budujemy [tutaj wstaw produkt] — w naszym przypadku dialer AI dla lokalnych firm usługowych, takich jak ogrzewanie i klimatyzacja, hydraulika, dachy. Metryką, którą optymalizujemy, jest odsetek odebranych połączeń, definiowany jako procent wybranych numerów, po których w ciągu powiedzmy dziesięciu sekund odezwie się żywy człowiek. Oto nasz obecny wynik bazowy, oto sufit branżowy, oto cel. Uruchom dziesięć równoległych podagentów; każdy ma zaproponować dziesięć odmiennych mechanizmów podniesienia odsetka odebrań. Rozjedźcie się maksymalnie: mechanizmy algorytmiczne, behawioralne, infrastrukturalne, regulacyjne, psychologiczne, czasowe, oparte na tożsamości. Nie cenzurujcie się pod kątem wykonalności — tym zajmiemy się później”.
Potem bierzemy tę stertę i weryfikujemy każdą pozycję: śmieć czy coś sensownego. Na wyjściu jest masa rezultatów i sporo twardych duplikatów. Ale czytając od góry: pierwsza propozycja to model skłonności czasowych — sztuczna inteligencja wyznaczająca okno, w którym ludzie najczęściej odbierają. To naprawdę działa u nas w Clarivo: mamy optymalne okna dzwonienia wyliczone ze średnich czasów odebrań w danych porach dnia. Tuż obok leży za to „regresja pogodowa” — analiza statystyczna historycznych odbierań względem hiperlokalnej pogody. Bez długiego namysłu: to nigdzie nie zbliży się do wartości, jaką daje samo dzwonienie o właściwej porze. Takich pomysłów dostaniesz mnóstwo i większość będzie bezwartościowa. Ale kilka zadziała.
Pacing predykcyjny: zwycięzca z krótkiej listy
Po takim przeczesaniu pomysłów robimy shortlistę. U nas wygrał pacing predykcyjny — pomysł w branży znany, ani nasz wynalazek, ani Claude’a, ale chcieliśmy sprawdzić, ile przewagi daje: zamiast dzwonić do jednej osoby — do kilku naraz.
Rachunek jest prosty. Czas wybierania numeru jest stały: wpisujesz numer, po czym słuchasz sygnału. Jeśli nikt nie odbiera, cały ten czas przepadł. Optymalna strategia to więc nie jeden numer i jego sygnał, tylko dwa jednocześnie — gdy jeden nie odbierze, nic nie tracisz: w czasie, który i tak musiałbyś poświęcić na samo wykręcenie numeru, łączysz się z drugą osobą.
Nie zatrzymujemy się na dwóch. Stosujemy model algorytmiczny, który wbudowuje przesunięcia czasowe między równoległymi połączeniami — i dane potwierdzają, że dzięki temu w każdej jednostce czasu z nami rozmawia optymalna liczba osób. Czy zdarza się, że dwie osoby odbiorą jednocześnie i zrobi się niezręcznie? Zdarza. Dlatego mamy wbudowany routing rozmów i system kolejkowania — jeśli jedno z równoległych połączeń nie trafi do wolnego handlowca, trafia do następnego dostępnego. Ten system również zbudowaliśmy z Claude Code. Ale wszystko zaczęło się właśnie tutaj, od kopania pomysłów.
Gdy masz już środowisko symulacyjne, karmisz je danymi historycznymi o czasach rozmów — zgromadzonymi z naszych własnych firm i z firm innych ludzi — i możesz liczyć statystyki: jakie przesunięcie jest optymalne dla partii, powiedzmy, pięćdziesięciu tysięcy połączeń. Potem podajesz kolejny prompt: „Zaimplementuj symulację pacingu predykcyjnego według powyższej specyfikacji. Oto dane historyczne. Zoptymalizuj pod te cele — w tym wypadku optymalizacją bayesowską”. Szczegóły zależą od problemu, ale sedno jest jedno: Claude Code znajdował sposoby na poprawę tego, co chcieliśmy poprawić, a potem sam implementował je w środowisku symulowanym.
Wreszcie budujesz rzecz — u nas właśnie ten predykcyjny pacer — i wypuszczasz do prawdziwych firm. I tu, podejrzewam, wyłoży się większość ludzi, bo nie ma żywych biznesów, na których można by testować. Dlatego dane to ostateczna fosa: kto ma dane oraz możliwość wdrażania i testów równoległych, przechodzi przez ten etap wielokrotnie szybciej.
Uniwersalna pętla: od problemu do wdrożenia
Z tego wszystkiego wychodzi ogólny schemat. Zawsze zaczynasz od zdefiniowania problemu — Claude Code może pomóc w definicji i w kopaniu pomysłów, to nic wstydliwego. W naszym przypadku wiedzieliśmy po prostu, że to problem, za który ludzie zapłacą niezłe pieniądze. Potem pytasz: „Claude, jak można to rozwiązać? Wypisz wszystkie możliwe rozwiązania”. Dalej do pracy rusza ludzki mózg i zadaje sobie pytanie: co z tego jest kompletną abstrakcją, a co da się zrobić? Z kilkuset propozycji realnych było u nas może pięć, sześć. Resztę i tak stopniowo przeglądamy, żeby sprawdzić, czy któraś nie dołoży jeszcze trochę przewagi do odsetka odebrań — ale w zdecydowanej większości przypadków czytasz i od razu wiesz: „to jest ten”.
Następnie projektujesz z Claude Code symulacje, zwykle oparte na jakichś danych historycznych, uruchamiasz model statystyczny — u nas algorytm pacingu — i iterujesz: model zmienia parametry, dopóki wyniki nie przestaną rosnąć. Na samym końcu test na żywo, czyli prawdziwe wdrożenie. I uwaga: pętla może się wywalić na każdym kroku. Mieliśmy sporo wyszukanych podejść, które w symulacji dawały piękne liczby, a po wdrożeniu okazywało się, że istnieje trzecia zmienna, która całą logikę wywraca. Nie jest łatwo. Gdyby było łatwo, robiłoby to wszyscy — a gdyby robili wszyscy, nikt by na tym nie zarabiał. Ale właśnie tak dobraliśmy i dopracowaliśmy zbiór funkcji Clarivo, które ostatecznie utorowały nam niezły zarobek.
Cennik: podnoś, aż zrobi się trudno
Cena? Dwieście pięćdziesiąt dolarów miesięcznie — bynajmniej nie kwota wyliczona naukowo. Zaczęliśmy blisko stu dolarów; ludzie płacili, więc podnieśliśmy. Nadal płacili, więc podnieśliśmy znowu. Ludzie, którzy budują rozbudowane modele statystyczne wyceny albo każą AI wyznaczyć „najlepszą cenę”, zwykle się mylą. Dużo prostsza droga: ustal cenę, sprzedawaj, a jeśli klienci zgadzają się bez oporu — podnoś, dopóki sprzedaż nie zacznie robić się trudna.
W SaaS-ie istnieje całe spektrum modeli cenowych. Na jednym krańcu to, co nazywa się low-touch: samoobsługa, samodzielne wdrożenie, może film od założyciela, pięć do dwudziestu dolarów miesięcznie, wszystko zrobione za klienta. To potrafi działać. Ale moim zdaniem — w erze, w której Claude Code i inne agenty AI składają praktycznie dowolny SaaS — każdy właściciel firmy w pewnym momencie zada sobie pytanie, czy nie taniej będzie po prostu przepalić tokeny i zbudować całość od nowa. Dlatego zamiast iść w tanio, drobne skalowo i w rozwiązanie malutkiego problemu, poszliśmy w dokładnie przeciwną stronę: spory problem, blisko enterprise, w modelu high-touch, z ręcznym wdrożeniem.
Clarivo siedzi właśnie tam. Z zasady nie sprzedajemy pojedynczych licencji — pojedynczy użytkownik teoretycznie może się zapisać, ale pracujemy z firmami i wdrażamy narzędzie w gotowych zespołach, które dzwonią. Przykładowa umowa: sto stanowisk po dwieście pięćdziesiąt dolarów, czyli dwadzieścia pięć tysięcy dolarów MRR, trzysta tysięcy ARR. Tak mniej więcej to wygląda: garść podpisanych kontraktów z firmami średniego rynku i większymi, działającymi w bardzo „telefonicznych” branżach. Wystarczy, że kilku takich ludzi powie „tak” i wdroży narzędzie u swoich zespołów, a robi się z tego poważny interes.
(Informacja dodatkowa: MRR/ARR — miesięczny/roczny powtarzalny przychód subskrypcyjny, standardowa miara kondycji firm SaaS.)
Szersza teza: dziś każdy zbuduje praktycznie wszystko. Łączna liczba commitów rośnie w tiempo pionowym, bo sztuczna inteligencja wykonuje większość intelektualnego ciężaru. Pytanie nie brzmi już „czy zbudujesz ten produkt” — zbudujemy wszyscy. Wąskim gardłem, fosą, źródłem wartości jest „co budować” i „jak to wycenić”.
Frameworki to puch — inteligencja mieszka w modelu
Bardzo szybko zrozumiesz też, że większość frameworków to puch. Testowaliśmy ich mnóstwo — agentowe frameworki typu Hermes czy OpenClaw, rozmaite biblioteki zarządzające kontekstem, bazy wektorowe pamięci projektu. Łącznie może pięćdziesiąt różnych podejść. I mogę powiedzieć stanowczo: jeśli celem jest produkt, który ma potem zarabiać, każdy kolejny framework koreluje ujemnie z tym, ile zarobisz. Bo skacząc między oprawkami, nie tylko się rozpraszasz i odrywasz od tego, co budujesz — typowo zyskujesz też regresje w kodzie, bo prompt jest teraz rozumiany albo „pośredniczony” inaczej niż wcześniej. Dla niewtajemniczonych: regresja to sytuacja, gdy podejście, które działało świetnie — powiedzmy czysty zestaw z małym plikiem konfiguracyjnym CLAUDE.md — przestaje działać, bo mnóstwo założeń i wiedzy modelu o Twojej bazie kodu traci ważność.
Dlatego zamiast skakać dookoła i gonić stuprocentową jakość albo „stuprocentowy wynik testu inteligencji modelu”, wolę model działający na dziewięćdziesiąt procent swojego potencjału — ale zawsze tak samo, konsekwentnie. Prawdziwa wartość, której wielu nie rozumie: inteligencja jest dziś w samym modelu. Nie w błyszczącym frameworku, który go oplata. Doczepianie nowej oprawki do zespołu pracującego z Claude Code przypomina zakładanie futrzastej nakładki na kierownicę i przekonywanie siebie, że dzięki niej auto jeździ tak dobrze. Auto jeździ dobrze, bo ma koła, silnik i podwozie — bo ktoś rzetelnie to zbudował. Ale skoro chcesz być wyjątkowy i nowoczesny, zakładasz futrzastą kierownicę i mówisz: „o, dużo lepiej”. Tylko że to nie jest realna poprawa, tylko Twoja subiektywna. Ludzie chcą przypisać sobie zasługi, nawet gdy nie są ich — więc wirtualnie doczepiamy futrzane nakładki, czyli te wszystkie agenty i narzędzia, podczas gdy silnikiem pozostaje bazowy model.
Zajrzyjcie więc, co mają we własnych plikach konfiguracyjnych ludzie, którzy te technologie stworzyli — na przykład Boris Cherny, jeden z twórców Claude Code.
(Informacja dodatkowa: Boris Cherny — inżynier Anthropic, współtwórca Claude Code.)
U takich osób zwykle nie ma tam nic istotnego. Żadnych rozbudowanych promptów systemowych. Opierają się na czystej inteligencji modelu — a czysta inteligencja modelu jest, przy wszystkich zastrzeżeniach, po prostu bardzo dobra. Frameworki dają poprawki marginalne. A Claude Code rośnie tak szybko, że jeśli jakaś oprawka daje Ci pięcioprocentową przewagę, następna generacja narzędzia — trzy, cztery dni później — najpewniej już ją wbudowała: w prompt systemowy albo wprost w trening modelu.
Wybieraj problemy, które płacą
Druga rzecz: wybieraj problemy, za które naprawdę się płaci. Skoro zbudować możesz niemal cokolwiek, to w jednym kole diagramu Venna leży wszystko, co da się zbudować — i żaden punkt tam wybrany nie zarobi Ci ani dolara. Szukasz wąskiego wycinka po drugiej stronie: rzeczy, za które ludzie realnie płacą. Palące problemy. Branże i nisze z dużymi budżetami. Ludzie z bólem istniejącym od dawna. I całą swoją uwagę kierujesz właśnie tam.
Tak zrobiliśmy z Clarivo. Widzieliśmy, jak mało skuteczni bywają handlowcy — i że sama różnica między pracą bez power dialera a z nim dawała trzykrotność wyników (dialer w końcu nie jest nowym pomysłem). Powiedzieliśmy sobie: co, jeśli da się zrobić istniejące dialery jeszcze lepszymi? Jeśli wygenerujemy choć dwukrotność skuteczności, będziemy mogli zabrać sobie sporą część wartości, którą dostarczamy firmom. W tym miejscu trzeba dziś siedzieć, żeby wygrać w SaaS.
Wszystko układa się przy tym na spektrum problem–wartość. Po jednej stronie problemy letnie: „miło mieć”, ale nie trzeba. I tam, niestety, czas spędza 90% ludzi. Sam budowałem masę dem pokazujących, jak złożyć aplikację to-do, proste rozszerzenie przeglądarki czy narzędzie produktywności. Gorzka prawda jest taka, że jeśli problem nie jest wystarczająco duży, by ktoś wybrał Twój SaaS zamiast zbudować go samodzielnie — a budowanie jest dziś łatwe, każdy może wymieniać tokeny na produkt po jakimś kursie wymiany — to ludzie po prostu to zrobią, a żywotność Twojego produktu będzie wyraźnie krótsza niż przy palącym problemie.
Wybraliśmy coś, co kosztuje organizacje miliony dolarów rocznie. Jeśli wiedzą, że da się poprawić odsetek odebranych rozmów, zapłacą za to niemal wszystko. I nie chodzi tu o „marketing dla wyprowadzaczy psów”, skoro przeciętny wyprowadzacz psów zarabia może tysiąc dolarów miesięcznie. Rozwiązuj kluczową potrzebę dużej firmy — z reguły ze średniego rynku wzwyż — ludzi z budżetami i wieloma stanowiskami, które muszą wykupić subskrypcję, żeby problem rozwiązać.
Wycena od wartości: 66 procent i dwadzieścia cztery miliony
Wdrożyliśmy to u jednego z naszych klientów z przychodami zaczynającymi się od ósemki. Na slajdzie widnieje „rocznie”, ale dosłownie chodziło o miesiąc — mam wrażenie, że AI po prostu mi nie uwierzyło, kiedy mówiłem, że to legalnie miesiąc. Podnieśliśmy jego miesięczne przychody o 66 procent. Delta to dwa miliony dolarów miesięcznie — dwadzieścia cztery miliony rocznie.
I teraz sedno: gdy rozwiązujesz komuś problem, nie powiem, że „należy Ci się” określona kwota, ale zwykle możesz negocjować 10–15% wartości, którą dostarczasz. Dajemy tej firmie dwa miliony dolarów miesięcznie, dwadzieścia cztery miliony rocznie — żądanie, a przynajmniej pozycja wyjściowa do negocjacji, jednej dziesiątej tej kwoty, czyli 2,4 miliona dolarów rocznie, nie jest niczym wygórowanym. Taki właśnie problem warto rozwiązywać: klienci ze środkami, paląca potrzeba — i przy tym wartość sama w sobie musi być duża. Inaczej szanse na sukces są nikłe.
Regulacje jako fosa
Kolejna sztuczka: wybierz branżę albo typ SaaS-a, który wymaga ludzkiego wdrożenia, ludzkiego wprowadzenia klienta. Jeśli wszystko, co robisz, jest w pełni cyfrowe, to w ciągu najbliższych kilku lat rozsądnie jest założyć, że sztuczna inteligencja zrobi to lepiej niż Twój zespół — a wtedy samo wdrożenie narzędzia przestaje mieć wartość. „Hej Claude, zrób to wszystko za mnie” będzie możliwe niemal wszędzie i to dość szybko.
Jednego AI dziś nie potrafi: nie przewróci regulacji. U nas trzeba wyrobić mnóstwo numerów i przejść rejestrację A2P. To sztywna rzecz — przepis, regulacja. Nie da się powiedzieć: „Claude, wywal tę rejestrację A2P i sprowadź mi pięć milionów numerów”. Claude odmówi — i z powodów etycznych, i dlatego, że takie ograniczenia ma wbudowane. Ale nawet bez tego nie ma drogi do numerów z pominięciem tego biurokratycznego procesu. W świecie, w którym samo „robienie” przestało być fosą, szukaj naturalnych fos tworzonych przez środowisko regulacyjne — u nas taką fosą są numery.
Świetny drugi przykład to ochrona zdrowia. Wszyscy narzekają na HIPAA — ja również — bo to istny zator dla amerykańskiej służby zdrowia przy budowaniu czegokolwiek obiecującego, choćby usługi transkrypcji: wymaga skrupulatnego trzymania się zasad, co mocno spowalnia, trzeba anonimizować dane i tak dalej. Ale z drugiej strony to właśnie wielka szansa w świecie ogólnej inteligencji — bo regulacja jest dziś jedyną rzeczą, która powstrzymuje przed wejściem na ten rynek. Certyfikacja, zgoda odpowiedniej rady na wdrożenie. Jeśli jako firma zbudujesz formę ludzkiego wdrożenia — człowieka odpowiedzialnego za relację z organem, który musi pieczętować projekt — zajdziesz dużo dalej. Mamy sieć kontaktów do ludzi, którzy potrafią te procesy przeprowadzać znacznie szybciej. I to jest jedna z fos, które wniosą nas przez najbliższe lata — zamiast żeby wielka trójka AI po prostu zmieliła większość tanich, samoobsługowych SaaS-ów.
(Informacja dodatkowa: A2P (application-to-person) — amerykański reżim rejestracji numerów służących do masowej komunikacji biznesowej; HIPAA — federalna regulacja ochrony danych medycznych w USA.)
Kod niezależny od modelu
Ostatnia rada: utrzymuj bazę kodu niezależną od modelu. Wiem, że cała teza tego materiału brzmi „zbudowaliśmy to w Claude Code” — i to jest w dziewięćdziesięciu procentach prawda. Poza Claude Code testowaliśmy inne modele. DeepSeek — żeby arbitrażować koszty tokenów przy ciągłych, całodobowych zadaniach: porządkowaniu kodu, refaktoryzacji, łatach błędów. Działało przyzwoicie. Codex próbowaliśmy wielokrotnie i zespół sięga po niego coraz częściej, bo wpadamy na limity tokenów — ekonomika tokenów to główna rzecz, która powstrzymuje nas przed pójściem all-in w Claude Code na okrągło. Przez najbliższe miesiące jakość i dostępność tych modeli będą się pewnie wahać, bo wielkie firmy AI zaczynają się przepychać o moc obliczeniową: cały świat chce te modele, odkoro zobaczył, że się po prostu opłacają. Musisz więc umieć błyskawicznie przełączyć bazę kodu — choćby z projektu Claude Code na projekt Codex.
To wcale nie jest trudne; to drobne tarcie, które ludzi spowalnia. W Clarivo zrobiliśmy kod całkowicie niezależnym od modelu. Claude Code ma swój specyfikacji skillek i oczekuje własnego pliku konfiguracyjnego? Trzymamy więc równolegle agents.md, specyfikację skillek dla agentów i pliki dla Gemini — na wypadek, gdyby w dowolnej chwili chciało się przeskoczyć albo sprawdzić, czy inny model rozwiąże problem, na którym utknęliśmy. Każdy w zespole może to zrobić. Praktyczna wskazówka: zduplikuj wszystko i każ Claude przejść przez specyfikacje każdego z modeli, żeby przygotować przestrzeń roboczą tak, by w każdej chwili dało się natychmiast załadować prompty systemowe i pozostałą konfigurację. Uwaga na niuanse: specyfikacje MCP i skillek są dziś rozumiane inaczej przez Claude i przez inne platformy. Nie wszystkie robią strojenie przez front matter YAML, gdzie wstępnie ładuje się wyłącznie nazwę i opis skillek; niektóre czytają całość. To drobne różnice między modelami, wokół których warto się ustawiać — dzięki nim Ty i Twój zespół będziecie działać wyraźnie szybciej.
Na koniec
Mam nadzieję, że materiał Wam się podobał — świetnie się go robiło. Obowiązkowa wstawka promocyjna: produktem, który posłużył tu za studium przypadku, jest Clarivo. Jeśli chcecie poprawiać odsetek odebranych rozmów, zajrzyjcie — eksperymentujemy z cenami i różnymi rozwiązaniami, a link wrzucę na górę opisu. Szerzej: jeśli chcecie nauczyć się monetyzować automatyzacje AI i aplikacje SaaS w ten sposób, zapraszam do Maker School, mojego dziewięćdziesięciodniowego programu z rozliczalnością — gwarantuję, że w tym czasie zdobędziecie pierwszego klienta na usługę związaną z AI lub automatyzacją, a w przeciwnym razie zwracam pieniądze. A jeśli macie pomysły na kolejne materiały albo chcecie, żebym nagrał coś na konkretny, gorący temat — dajcie znać. Większość tematów czerpię dziś z komentarzy. Dziękuję za obejrzenie i do zobaczenia w następnym filmie.