Build & Sell AI SaaS Products (2 HOUR COURSE)

O czym jest ten film

1. Autor buduje na żywo, w ciągu jednego dnia roboczego (ok. ośmiu godzin), kompletny produkt AI SaaS — od pustego folderu do działającej aplikacji na własnej domenie.
2. Całość organizuje wokół sześciu „P”: ból (pain), obietnica (promise), produkt, hydraulika (plumbing), opakowanie (packaging) i dowód (proof).
3. Stack to Codex w aplikacji ChatGPT, Claude Code w aplikacji Claude oraz Glido jako warstwa głosowa; do tego Next.js, Supabase, Stripe, GitHub i Vercel.
4. Pomysł nie bierze się z powietrza — pięć agentów researchowych przeczesuje ok. 60 tysięcy komentarzy z YouTube, własnej społeczności, X i Reddita, żeby znaleźć realny ból i realny przedział cenowy.
5. Powstaje ClientPack: narzędzie zamieniające transkrypty rozmów sprzedażowych w gotową, brandowaną dziesięciostronicową talię dla klienta agencji AI.
6. Kluczowy wzorzec pracy: jeden model (Fable 5) jako menedżer projektu, który tylko deleguje, oraz roje tańszych agentów-wykonawców pracujących równolegle w osobnych work tree.
7. Drugi model służy jako niezależny weryfikator — Codex steruje przeglądarką, klika po aplikacji i celowo próbuje ją zepsuć, znajdując blokery przed premierą.
8. Osobny przebieg to audyt bezpieczeństwa pod OWASP — cztery blokery o wysokim priorytecie, których autor sam nigdy by nie znalazł.
9. Wątek uczciwości: prawdziwą fosą nie jest kod (dający się odtworzyć w jeden dzień), tylko prompt z wiedzą branżową autora oraz dowody społeczne od klientów.
10. Druga połowa to playbook sprzedażowy: pierwszych 50 klientów, moment „aha”, pricing, ryzyko zbyt szybkiego skalowania i praca z małymi twórcami zamiast reklam.

Redakcyjne tłumaczenie

Sześć „P” jednodniowego sprintu

Dzisiaj buduję produkt AI SaaS na waszych oczach, praktycznie na żywo. Zaczynam od kompletnego zera — nie mam nawet pomysłu. Przejdziemy przez ideację, planowanie, budowę, testy, uwierzytelnianie, obsługę płatności i podpięcie prawdziwej domeny. Wszystko po to, żebyście po tym materiale wiedzieli dokładnie, jak znaleźć jakiś pomysł, zamienić go w produkt i zacząć szukać dla niego klientów.

Całość organizuję wokół sześciu „P”.

Pierwsze P to ból. Wcielam się dziś w waszą sytuację: startujecie właściwie od zera, z odrobiną wiedzy o AI, bez pomysłu i bez produktu. Chcemy zbudować coś, czego ludzie faktycznie użyją. W idealnym świecie zrobiłbym to tak: poszedłbym po informację zwrotną. „Oto mój pomysł na biznes. Ile byście za to zapłacili? Czy w ogóle byście zapłacili?” Zebrałbym walidację, zanim cokolwiek zbuduję, albo zrobiłbym mały dowód koncepcji i pokazał: „Tu jest demo, a gdybym zbudował to na poważnie, widzielibyście w tym wartość?”. Dopiero potem bym budował. Krótko mówiąc: sprzedawaj, zanim zbudujesz. Do znalezienia bólu i samego pomysłu użyjemy AI.

Drugie P to obietnica. Musi być krystalicznie czysta i mieścić się w jednym zdaniu na stronie docelowej. Co to narzędzie robi? W jaki sposób obiecuje odpowiedzieć na ból, który znaleźliśmy?

Trzecie P to produkt — zaplanujemy go, zbudujemy i przetestujemy. To rdzeń dzisiejszej pracy.

Czwarte P to hydraulika. Trzeba podpiąć obsługę płatności, uwierzytelnianie, zarządzanie bazą danych. Celem takiego produktu jest to, żeby kiedyś obsłużył tysiące użytkowników, więc instalacja pod spodem musi to udźwignąć.

Piąte P to opakowanie — wytyczne marki, spójne kolory, wszystko to, co sprawia, że produkt sprawia wrażenie profesjonalnego; coś, co ktoś odwiedzający stronę może po prostu kupić albo zasubskrybować.

Szóste P to dowód. Przez cały czas będziemy weryfikować, bo prawda jest taka, że ja nie umiem czytać Pythona. Nie umiem w nim programować. Nie wiem, jakich jeszcze języków użyjemy. Ale AI robi to naprawdę dobrze. Naszą rolą jest być kierownikiem projektu — tym, który mówi: „zweryfikuj to, aż będziesz pewien, że gotowe, i udowodnij mi tę pewność”. Chodzi o to, żeby wykorzystać coraz inteligentniejsze agenty kodujące, ale zachować kontrolę nad osądem. Jeśli produkt polegnie, to nasza wina. Nie zwalamy na AI, zwalamy na siebie.

Stack: dwa harnessy kodujące i głos zamiast klawiatury

Trzy rzeczy napędzają dziś całość, choć po drodze pojawi się mnóstwo dodatkowych API i procesorów płatności.

Po pierwsze — Codex, którego uruchamiam przez aplikację desktopową ChatGPT. Po drugie — Claude Code w aplikacji desktopowej Claude. Po trzecie — Glido jako warstwa głosowa, żeby nie ograniczała mnie prędkość pisania. Mówię tak szybko, jak potrafię, i tak szybko pracuję.

(Informacja dodatkowa: Glido to narzędzie do dyktowania tekstu w dowolnej aplikacji; autor jest jego współzałożycielem, o czym mówi otwarcie w dalszej części materiału.)

Jeśli chcecie podążać za tym filmem, polecam mieć wszystkie trzy — dzięki temu możecie działać szybko i pozwolić różnym modelom oraz różnym harnessom kodującym spojrzeć na wasz projekt z odmiennych perspektyw. Jeśli wolicie tylko Codeksa albo tylko Claude’a, to też w porządku. Ale przekonałem się, że możliwość skonfrontowania dwóch różnych harnessów — żeby jeden zagrał adwokata diabła i przetestował pomysł drugiego pod obciążeniem — bardzo pomaga.

Jak myślę o różnicy między nimi? Claude jest dla mnie partnerem do myślenia. Wydaje się bardziej kreatywny — zwłaszcza gdy przełączę go na Fable, ma w sobie coś z perspektywy mądrej starej sowy. Codex natomiast przypomina rottweilera. Bierze zadanie, bierze polecenie i po prostu wykonuje, wykonuje i weryfikuje, aż będzie dobrze, aż będzie skończone. Świetnie sprawdzają się w tandemie.

Buduję w projekcie Herk 2, czyli moim systemie operacyjnym opartym na AI. Mam tam folder „Other Worlds”, a w nim utworzyłem nowy, całkowicie pusty świat: „AI SaaS Sprint”. To z tego folderu będą pracować i Codex, i Claude Code — dzięki temu widzą dokładnie to samo.

P jak ból: 60 tysięcy komentarzy zamiast burzy mózgów

Otwieram Glido i zaczynam mówić.

„Chcę dziś zbudować produkt AI SaaS i pokazać widzom, ile da się zrobić z AI. Najważniejsza część budowania SaaS-a to realny ból — musimy odpowiedzieć na problem, który rynek naprawdę ma. Duża część mojej widowni nie ma kanału na YouTubie ani społeczności, z której mogłaby zbierać dane — my to mamy. Chcę więc, żebyś użył naszych danych pierwotnych: komentarzy z YouTube’a, wypowiedzi ludzi w naszej społeczności na Skool — jakie mają problemy. Ale sięgnij też po dane publicznie dostępne, wtórne: fora Reddita, LinkedIn, X, Instagram. Przejrzyj to i pomóż mi zidentyfikować ból, który da się rozwiązać, albo kilka takich bólów.

Szukamy produktu AI SaaS, który realistycznie da się zbudować w jeden dzień. Czegoś bardzo wizualnego, z bardzo czytelną obietnicą. Nie jakiegoś ultratechnicznego CRM-a, do którego trzeba ludzi wdrażać przez tydzień czy dwa. Szukam czegoś, po zarejestrowaniu czego wartość przychodzi natychmiast — w pięć, dziesięć minut człowiek to uruchamia, rozumie i dostaje korzyść.

Chcę, żebyś działał jako orkiestrator. Powołaj różne podagenty, zrób research, użyj różnych metod scrapowania, a na końcu wróć, skonsoliduj wszystko i daj mi czyste sygnały z kilkoma pomysłami. Wybór zostawiam sobie. Powiedz mi, jeśli czegoś potrzebujesz — kluczy API albo dostępu do danych, do których nie sięgasz.”

Ponieważ to bardziej materiał w formule wyzwania, zakładam, że macie za sobą podstawy Claude Code czy Codeksa. Jeśli nie, polecam wcześniejszy, darmowy kurs — omawia zmienne środowiskowe, klucze API i całą resztę; po nim ten film będzie miał znacznie więcej sensu.

Claude ma dostęp do API YouTube’a, do społeczności na Skool, do X, do Firecrawla i Perplexity. Uruchamia pięć agentów researchowych równolegle. Przez całe to wyzwanie będę myślał o tym, jak robić kilka rzeczy naraz — mamy mało czasu. Jest już dziewiąta, zeszło nam jakieś piętnaście minut. Przeczuwam, że większość dnia zejdzie na czekaniu, aż agenty w tle się przemielą, a nie na moim promptowaniu. Dlatego będziemy nawarstwiać zadania, ile się da. Na razie jesteśmy jednak zablokowani — bez pomysłu nie ruszymy z opakowaniem ani ze stroną.

Co pokazały dane

Jest prawie dziesiąta. Research trwał długo, ale to prawdopodobnie najważniejsza część — pomysł, ból, to jest cały produkt. Wszystko inne buduje się wokół niego.

Podsumowanie: przejrzane ok. 16 tysięcy komentarzy z YouTube’a, ok. 8 tysięcy komentarzy i postów z mojej płatnej społeczności, ok. 4 tysiące tweetów oraz — bo Reddit jeszcze się mielił, więc dopytałem — ok. 20 tysięcy komentarzy z Reddita. To jest właśnie sedno: można oddelegować myślenie i zbieranie danych, ale nie wolno oddelegować rozumienia. Sam przeczytałbym tyle komentarzy znacznie dłużej niż w godzinę. Teraz jednak to ja muszę spojrzeć na te dane i zrozumieć, co mówią i co z nich zbudować.

Trzy finalne rekomendacje: pakiet propozycji i przekazania projektu klientowi; generator grafik społecznościowych (karuzele, infografiki); oraz narzędzie do zmiany rozmiarów kreacji reklamowych. Wybieram pierwsze — model rekomendował je najwyżej, lepiej pasuje do tego, czego szuka moja widownia, i mogę je wpiąć w istniejący produkt.

Jedna uwaga: nie widzę tu żadnej fosy. Ktoś może użyć produktu przez miesiąc, zrozumieć, jak działa i co mu się w nim podoba, a potem zbudować własne skille i własne systemy wokół tego. To trzeba po prostu przyjąć do wiadomości. Gra w produkty jest teraz nieco przerażająca — narzędzia ewoluują błyskawicznie i coraz więcej rzeczy trafia do open source.

Najważniejsza rekomendacja z tej części: udało mi się wykorzystać własne dane pierwotne i zobaczyć, czego chcą klienci, którzy już mi płacą. Wy powinniście robić dokładnie to samo. A jeśli nie macie jeszcze produktu ani widowni, sięgnijcie po własną ekspertyzę dziedzinową. Jeśli znacie się na firmach budowlanych, róbcie ten research i scrapujcie bóle w niszy, którą naprawdę rozumiecie. Inaczej, jeśli wyślecie generyczny prompt bez niczego, co jest wasze, dostaniecie te same rekomendacje AI, co wszyscy inni pytający „pomóż mi znaleźć dobry pomysł na biznes”.

Jeszcze jedna rzecz, którą model wygrzebał. Pamiętacie, jak mówiłem o cenie rzędu 5–25 dolarów miesięcznie? Model odpowiedział, że według danych to za mało — i podał konkretne cytaty. Reddit dostarczył 835 zdań o cenach ze spójnym przedziałem. Sens: narzędzie, które robi jedną nudną rzecz naprawdę dobrze, może kosztować 50 dolarów miesięcznie i ludzie chętnie zapłacą. Potrzebujesz 100–200 osób płacących 25–50 dolarów miesięcznie za coś, co oszczędza im czas w każdym tygodniu.

Porządkowanie projektu i wstępne rusztowanie

W projekcie istnieje na razie tylko jeden folder — research — z pięcioma plikami Markdown: YouTube, Skool i tak dalej, plus krajobraz konkurencji. Są bardzo szczegółowe: ceny, narzędzia z konkretnymi metrykami, wszystkie źródła do kliknięcia. Ten research chodził blisko godzinę i wszystko zostaje w projekcie, więc Codex i Claude będą mogli z tego korzystać później.

Idziemy więc w produkt do przekazywania projektów klientom. Użytkownik zakłada konto, wrzuca informacje typu „taki workflow buduję, dla takiej firmy”, ma portal do zarządzania projektami klientów, a na wyjściu dostaje deliverables: brandowany PDF, wizualizacje, diagramy oraz rzeczy, o których warto pomyśleć przy przekazaniu — informacje o poświadczeniach dostępowych, oczekiwania wobec klienta i tak dalej.

Proszę Claude’a o przygotowanie pliku claude.md i zduplikowanie go do agents.md, bo w tym projekcie będę korzystał z obu narzędzi.

(Informacja dodatkowa: CLAUDE.md i AGENTS.md to pliki z instrukcjami projektowymi wczytywane automatycznie odpowiednio przez Claude Code i Codeksa. Ten sam kontekst musi istnieć w dwóch plikach, bo każde narzędzie czyta swój.)

Opakowanie równolegle: nazwa, logo, kolory

Zanim ruszymy z budową, biorę się za opakowanie — te rzeczy nie są od siebie zależne, więc mogą iść równolegle. Do tego używam Codeksa, bo ma GPT Image 2, moim zdaniem obecnie najlepszy model generowania obrazów.

Mówię mu, co budujemy, i proszę o pytania, a potem o nazwę, warianty logo i schematy kolorów — czyli o gotowy system projektowy dla całego produktu.

Warto zauważyć: oba narzędzia pracują w tym samym folderze. Codex widzi agents.md i claude.md, które przed chwilą stworzył Claude, oraz folder research. Trzeba tylko pilnować, żeby sobie wzajemnie nie nadpisywały pracy — na razie to nie problem, bo robią zupełnie różne rzeczy.

Skoro pliki konfiguracyjne gotowe, używam skilla o nazwie session handoff. Daje mi podsumowanie tego, co zrobione, i listę ważnych plików, dzięki czemu mogę wyczyścić sesję i wkleić to podsumowanie z powrotem. Byliśmy na mniej więcej połowie okna kontekstowego; po wklejeniu świeża sesja podejmuje dokładnie tam, gdzie skończyliśmy.

(Informacja dodatkowa: „handoff” to sposób na uniknięcie tzw. context rot — degradacji jakości odpowiedzi, gdy okno kontekstu zapełnia się historią rozmowy.)

Wracam do Codeksa, bo ma pytania. Przepraszam za przeskakiwanie — wiem, że może wyglądać chaotycznie, ale tak realnie pracuję. Żongluję sesjami i przeskakuję między nimi dość szybko. Odkryłem, że przy zakładaniu fundamentów nie obniża mi to jakości. Oczywiście, gdy jesteś w głębokim skupieniu, zostań przy jednym oknie.

Codex proponuje pozycjonowanie: „zamień chaotyczne notatki z projektu i workflow w dopracowane deliverables gotowe dla klienta w kilka minut”. Podoba mi się, ale to jeszcze nie dość mocna obietnica. Odpowiadam głosem na jego pytania:

Moment kluczowy to chwila po rozmowach rozpoznawczych i sprzedażowych, gdy trzeba wysłać klientowi materiały domykające sprzedaż — muszą być brandowane, profesjonalne i spójne. Nasz awatar to ludzie, którzy dopiero zaczynają w agencjach AI, albo prowadzą taką agencję z kilkoma klientami i zaczynają tonąć w deliverables. Ból: przytłoczenie i brak struktury tego, co dostarczają klientom.

Nazwa: dosłowna. Mamy jedną bardzo konkretną obietnicę, nazwa ma się z nią zgrywać. Marka ma sprawiać wrażenie premium consultingu. Ma być całkowicie niezależna od mojego nazwiska i mojej marki. Domeny nie rozstrzygamy teraz — priorytetem jest dobra nazwa produktu. Kolorów: unikać czerwieni. Ma być nowocześnie i czysto, ale absolutnie nie ma pachnieć wibekodingiem ani sieczką z AI. I proszę o mocniejszą wersję jednozdaniowej obietnicy, a potem o iteracje logotypów, koncepcji i palet.

Planowanie budowy: menedżer, który nie wykonuje

Wracam do Claude’a i przełączam go na Fable, bo wchodzimy w planowanie i patrzenie za zakręt.

Mówię: „Mam osobną sesję Codeksa, która pracuje nad nazwą, obietnicą, logo i kolorami. Twoje zadanie w tej sesji: jesteś Fable 5, jesteś bardzo inteligentny, pomóż mi rozpisać samą budowę. Twój deliverable to dokument planu — coś, czym posłużysz się, delegując pracę podagentom. Nie jesteś wykonawcą. Jesteś menedżerem, kierownikiem projektu. Jeśli nie masz jeszcze jasnej wizji produktu, dopytaj i pobrainstormujmy, aż będziesz pewien, jak wygląda doświadczenie użytkownika i co technicznie musi się wydarzyć.”

Potem opisuję wizję wersji pierwszej. Użytkownik wrzuca transkrypt rozmowy rozpoznawczej i sprzedażowej — tyle, ile chce. To uruchamia nowy projekt w jego panelu, powiedzmy dla klienta A. AI z tyłu analizuje transkrypty i dodatkowe informacje, po czym tworzy pełną talię slajdów.

To jest naprawdę ważne, bo celem tej talii jest przekonanie klienta do współpracy. Na początku ma podświetlić ból: oto, co boli w twojej firmie, oto twoje ograniczenia, a oto rozwiązania, o których rozmawialiśmy. Dalej: oczekiwane rezultaty. W pracy z klientem najistotniejsze jest pokazanie, że inwestycja w ciebie zwróci się dziesięciokrotnie. To jest uzasadnienie ceny.

Potem trzeba pokazać liczby, które się poruszą, bo nie sprzedajemy podróży, tylko cel. Przykład: „rozmawialiśmy o bólu, że masz za mało nowych klientów. Okazało się jednak, że nie potrzebujesz więcej leadów, tylko lepszego systemu do follow-upu i reaktywacji. Przeramowaliśmy to. Oto rozwiązanie. Metryka, którą ruszamy: obecnie masz około pięciu nieobecności na umówionych spotkaniach tygodniowo; ten system AI zejdzie z pięciu do dwóch w ciągu trzydziestu dni”. Ta metryka w głowie właściciela firmy ma bardzo wyraźny związek z przychodem.

Dalej wchodzą szczegóły techniczne i wizualizacja — właściciele firm i osoby nietechniczne lubią patrzeć na rzeczy wizualne. Talia ma być profesjonalna, wizualna i nastawiona na wynik.

Potrzebujemy też, żeby użytkownicy systemu mogli wgrywać własne studia przypadku i specjalizacje, tak żeby każda talia była personalizowana — „przy okazji, robiliśmy podobne wdrożenia dla tych klientów, a oto ich wyniki. Dlatego jesteśmy pewni, że dowieziemy to i to”. Muszą też móc dodać własne logo i wytyczne marki, żeby wszystkie PDF-y wychodziły brandowane.

Dokument planu ma pokazywać wszystkie kroki, które model widzi, żebyśmy mogli delegować pracę do różnych sesji, mieć agentów pracujących w osobnych work tree bez nadpisywania się nawzajem i przesunąć w równoległość tyle, ile się da.

To była ogromna porcja mówienia, ale tak wygląda większość tej budowy: mój osąd i moja rola kierownika projektu. Chodzi o strategiczne promptowanie i wbudowywanie weryfikacji, żebyście nie musieli sprawdzać każdej linijki, tylko dostawali od agenta coś w rodzaju: „jestem pewien, że to działa, a oto dlaczego i oto, co przetestowałem”.

ClientPack: nazwa, logo, komunikat

Wracam do Codeksa. Sprawdzanie kolizji wyeliminowało kilka oczywistych nazw — CloseKit jest już zajęty przez niemal identyczny produkt do propozycji AI, a ClientReady przez usługę raportowania AI. Trzy najczystsze dosłowne terytoria to ClientPack, ScopePack i ProposalReady. Codex traktuje ClientPack jako wiodącą nazwę roboczą i porówna ją wizualnie z pozostałymi.

ClientPack bardzo mi się podoba — jest „C”, jest „P”, jest profesjonalna paleta. ScopePack mniej. ProposalReady wygląda trochę bardziej „aliszowo”, bardziej figlarnie niż premium. Codex nazywa wybrany wariant „editorial fold”: nowoczesny, przystępny, wyważony między SaaS-em a konsultingiem. Ten jeden wygląda po prostu na godny zaufania. Zatwierdzam.

Komunikacja: nagłówek „Zamień rozmowy rozpoznawcze w propozycje gotowe dla klienta”. Jednozdaniowa obietnica: „Zamień rozmowy rozpoznawcze w dopracowane, brandowane materiały, które pomagają domknąć klienta”. Krótka linia marki: „Discovery wchodzi, gotowe dla klienta wychodzi”.

Zanim to zatwierdzę, chcę zdania innych. Proszę Codeksa: „Powołaj kilka person-agentów — właściciele firm, właściciele agencji, właściciele małych firm, prezesi. Niech przeczytają komunikaty, spojrzą na logo i nazwę, i powiedzą, co myślą o brandingu: czy mu ufają, czy jest wystarczająco mocny, czy wydaje się generyczny. Nie muszą debatować ani robić głębokiej analizy — po prostu pierwsze wrażenie.”

Robię tak często i to bardzo pomaga. Zespoły agentów, podagenty, debaty, a nawet „pokoje wojenne”, w których modele się spierają i podają konsensus — to naprawdę ułatwia decyzje, kiedy masz trzy opcje, które ci się podobają, i potrzebujesz odrobiny perswazji albo usłyszenia dziur w konkretnym planie.

Po tym przemiale nagłówek brzmi: „Zamień rozmowy rozpoznawcze w pakiety propozycji gotowe dla klienta”. Obietnica jest konkretniejsza: „Dopracowana, brandowana propozycja, zakres, rozpisanie ROI i plan projektu — bez budowania każdego dokumentu od zera”. To trafia w ból. Linia marki zostaje.

Jedna szczera uwaga: samo to nie wystarcza na produkt SaaS. Nie sądzę, żeby ten ból był na tyle silny, by dobrze sprzedawać, zwłaszcza przy wysokiej wartości życiowej klienta, bo ludzie to wezmą i zrobią coś swojego. Ale to dobra wersja pierwsza, na której da się budować. Docelowo może to być system operacyjny do zarządzania klientami — portal, w którym klient loguje się i widzi postępy, zgłasza tickety i tak dalej. To może ewoluować na podstawie sygnałów od widowni i użytkowników bety. Może warto wpuścić ludzi najpierw za darmo, zbierać feedback, a monetyzować później.

Wiem, że zaraz podniesiecie kwestię, że najtrudniejsze jest zdobycie klientów. To prawda i dlatego tak trudno zaczynać od razu od produktu SaaS. Dlatego wielu z nas idzie najpierw drogą usługową — łatwiej działać w modelu wysokiego kontaktu, łatwiej zebrać dane o tym, co działa, a co nie, i dopiero z tej wiedzy zbudować produkt.

Strona zapisów i wbudowana weryfikacja

Wracam do Codeksa i uruchamiam prostą, jednostronicową landing page z listą oczekujących. Używam do tego /goal, czyli trybu, w którym model będzie dążył do celu, aż go osiągnie.

Prompt w skrócie: skoro znamy nazwę, logo i kolory, zrób prostą, profesjonalną stronę z formularzem zapisów. Logo na górze, nagłówek i obietnica na górze, niżej informacje o tym, co produkt będzie robił. Możesz przejrzeć projekt, dokument planu i moje wcześniejsze rozmowy.

I kluczowa część: „Nie przerywaj, dopóki tego nie zweryfikujesz. Otwórz stronę, zrób zrzuty ekranu, upewnij się, że lista działa. Sprawdź, że gdy ktoś wpisze e-mail, ten adres faktycznie gdzieś się zapisuje. Czy to Google Sheet, czy mail do mnie — obojętne, ale ma być w pełni funkcjonalne, zanim gdziekolwiek to wypuścimy.”

To właśnie jest wbudowywanie weryfikacji. Gdybym tego nie dopisał, prawdopodobnie dostałbym stronę, która nie działa — sam plik HTML, w którym można wpisać e-mail, kliknąć „wyślij” i nic się nie stanie.

Plan budowy od Fable

Zaglądam do dokumentu planu. Mamy plan budowy generatora talii przedsprzedażowych. Są zablokowane decyzje. Jest doświadczenie użytkownika: rejestracja, jednorazowa konfiguracja (loga, studia przypadku), zakładanie projektów (nazwa klienta, jego biznes), wrzucanie transkryptów, analiza, ekran przeglądu przed wygenerowaniem PDF-a, generowanie talii, panel z listą wcześniejszych projektów i możliwością edycji czy ponownego wygenerowania.

Struktura talii: okładka, gdzie jesteś dziś, prawdziwe ograniczenie, plan, co się poruszy, matematyka, jak to działa, dlaczego my, zakres, inwestycja, następne kroki.

Architektura: Next.js z App Routerem, Supabase na backendzie, checkout Stripe’a, dwa wywołania AI na projekt — jedno do analizy, jedno do stworzenia talii. Plan ma fazę zerową (fundament), pierwszą i drugą, a w nich osiem strumieni pracy od A do H. Pomysł: budować je równolegle, a delegowanie zostawić Fable’owi, bo robi to lepiej ode mnie.

Teraz odpalam /goal również w Claude Code — to nie jest funkcja tylko Codeksa. Promptuję w bardzo określony sposób: Fable 5 jest kierownikiem projektu i nie ma niczego wykonywać samodzielnie, bo to spaliłoby mnóstwo naszego limitu na Fable. Ma tylko delegować.

Zanim wejdziemy głębiej — jedna rzecz. Budowanie i skalowanie SaaS-a z sukcesem nie jest łatwe i nie chcę, żeby ten film sugerował inaczej. Widzę od kuchni, co dzieje się w Glido, jak to jest skomplikowane i ile pracy wkłada zespół w ciągłe iteracje. To nie jest łatwe — ale jest sto razy łatwiejsze niż przed AI. Wielu z nas ma mnóstwo pomysłów, których nigdy nie realizuje. Chcę pokazać, ile da się osiągnąć w jeden dzień, będąc osobą zupełnie nietechniczną — po prostu ciekawą, promptującą i zarządzającą agentami, które weryfikują swoją pracę.

Prompt do Fable’a, w skrócie: jesteś kierownikiem tego projektu od początku do końca i to ty odpowiadasz za błędy. Pracuj na planie budowy, przechodź przez fazy, delegując pracę podagentom na Opusie lub Sonnecie — cokolwiek pasuje do złożoności zadania. Możesz używać dynamicznych workflowów, podagentów, zespołów agentów. Twoim zadaniem jest zrobić to jak najszybciej: cokolwiek da się zrównoleglić, zrównoleglij. Nie ma powodu, żeby to szło jak taśma produkcyjna. Jeśli potrzebujesz osobnych work tree, korzystaj.

Bardzo ważne: agenty mają zapisywać postępy — albo do planu budowy, albo każdy do własnego folderu w stylu „oto co zrobiłem, oto nad czym pracuję” — żebyś mógł ich doglądać, pilnować, że się nie nadpisują, i stale weryfikować oraz dawać im informację zwrotną.

Twój deliverable to skończona wersja pierwsza, dowód koncepcji, który mogę odpalić i przetestować. Przewiduję, że zablokuje cię brak klucza do Supabase czy integracji Stripe’a — zbuduj wokół tego infrastrukturę, całą hydraulikę, a na koniec zgłoś mi, jakich kluczy potrzebujesz. To ma być jedyna rzecz, którą muszę zrobić. Myśl o tym, jak ludzie płacą, jak wygląda onboarding, gdzie powstają konta, jak my jako administratorzy zarządzamy bazą użytkowników. To musi być odporne na idiotę zarówno po stronie klienta, jak i administratora.

To bardzo duży prompt i pewnie zajmie kilka godzin. Włączam sterowanie zdalne, żeby doglądać sesji z telefonu. Dzięki temu mogę zrobić sobie lunch, pójść na spacer albo na siłownię i po prostu zaglądać.

To właśnie jest tu potężne. Wysłałem jedno polecenie, a system buduje, ogląda, iteruje, ogląda ponownie, weryfikuje, korzysta z integracji, żeby sprawdzić, czy działa — i będzie tak szedł, aż udowodni mi, że wszystko gra. Po stronie Fable’a: wziął dokument planu, wie dokładnie, co robić, i uruchamia mnóstwo agentów równolegle. Powołuje dziesiątki pracowników do jednej, bardzo konkretnej rzeczy. Trudno jest kazać jednemu agentowi zrobić wszystko — gubi się, kontekst się zapełnia, pojawia się rot i bloat. Ale kiedy masz jednego menedżera na Fable’u, który rozdziela zadania i powołuje nowych agentów do wąskich zadań, jakość całości jest znacznie wyższa. Mogę podejrzeć transkrypt każdego z nich w czasie rzeczywistym. Wciąż mam kontrolę, ale nie muszę być pośrednikiem między wszystkim.

Chodzi mi o to, że wielu rzeczy po prostu nie musicie wiedzieć. Jak zintegrować Stripe’a z własną aplikacją? Nie musicie wiedzieć. Oddelegowujecie to myślenie i research do Claude’a, a on powie: potrzebuję tego połączenia, tego klucza, włącz to w interfejsie. Robicie to i on ogarnia resztę.

Nie twierdzę, że w tym filmie zarobię milion dolarów na aplikacji AI. Pokazuję sposób myślenia: oddelegować myślenie, ale zostać w pętli tam, gdzie trzeba. I mam nadzieję zmotywować was do tego, że AI można stawiać znacznie ambitniejsze cele, niż sądziliście.

W tej chwili chodzi dziewięć agentów: od przeglądu interfejsu, przez warstwę danych, trasy API, oglądanie PDF-ów, naprawianie skoków w ekstrakcji, po sprawdzanie w Puppeteerze, czy da się poklikać. A ponieważ tę pracę wykonują Opus i Sonnet, a nie Fable, nasz limit wystarczy na znacznie dłużej — zużyliśmy dopiero 3% tygodniowego limitu Fable’a, mimo ogromu wykonanej pracy.

Landing page, GitHub i Vercel

Strona ClientPacka jest gotowa. Wygląda naprawdę dobrze. Widać, że robiło ją AI — podobne formatowanie, duży tekst hero, obrazek hero po prawej — ale wcale nie jest źle. Grafiki, które musiało wygenerować, mają przyjemny, profesjonalny sznyt. Głębia w tym logo też mi się podoba. Pulsująca ikonka jest bardzo „aliszowa”, ale całość trzyma poziom.

Dopytałem, gdzie zapisują się e-maile. Model przeprowadził swoje kontrole i odpowiedział, że trafiają do bazy danych hostingu, do której nie mam bezpośredniego dostępu. Zapytałem, jak je odczytać. Zaproponował osobną stronę administracyjną chronioną hasłem. Zgodziłem się.

Teraz mam panel administracyjny: loguję się, widzę adres, którym się zalogowałem, mogę odświeżyć listę, pobrać ją jako CSV i zobaczyć ostatni zapis oraz sumę zapisów. Test: wpisuję fałszywy e-mail na stronie, klikam „dołącz do listy”, dostaję komunikat „jesteś na liście”, wracam do panelu, odświeżam — nowy wpis jest. Mamy rosnącą listę mailingową osób zainteresowanych produktem.

Strona stoi na tymczasowym adresie, coś w rodzaju clientpack-waitlist.nateherk.[...]. To działający URL, ale nie ma odpowiedniego charakteru — od razu widać, że to strona wygenerowana przez asystenta. Chcę własną domenę. Plan: wypchnąć kod na repozytorium GitHuba, a stamtąd wdrożyć na Vercelu.

Proszę Codeksa o utworzenie prywatnego repozytorium — powinien być już uwierzytelniony w moim GitHubie. Jeśli nigdy nie używaliście GitHuba: wchodzicie na github.com, konto jest darmowe, potem prosicie Codeksa albo Claude Code o uwierzytelnienie, przechodzicie przez logowanie OAuth i gotowe. Vercel to z kolei miejsce, w którym zarządzacie wdrożeniami pod prawdziwym adresem i możecie kupić własną domenę.

Domyślnie wdrożenie dostaje adres w stylu nazwa.vercel.app. Można podpiąć własną domenę. W zakładce domen sprawdzam dostępność: clientpack.com jest zajęta, getclientpack.com jest wolna za 11,25 dolara. Można ją kupić od razu z poziomu Vercela i przypiąć do projektu.

Codex wypchnął kod do repozytorium client pack landing page. Wszystkie pliki i foldery potrzebne do hostowania strony są na miejscu. Mamy kontrolę wersji — jeśli później zmienimy kolor albo copy, wypchniemy zmianę i zachowamy historię.

W Vercelu: „add new project”, import repozytorium z Gita, podpięcie konta GitHub, „import”, „deploy”.

I tu problem — 404, nie znaleziono. Cieszę się, że się zdarzył, bo mogę pokazać, co robić. Robię zrzut ekranu i wklejam Codeksowi: „Podpiąłem konto GitHub, podpiąłem repo, które przed chwilą zrobiłeś, do Vercela, i przy wdrożeniu stało się to. Nie wiem, czy próbowało się to wdrożyć jako Vite, czy co się stało. Jeśli potrzebujesz więcej informacji z Vercela, powiedz. Napraw to.” Chwilę później problem jest rozwiązany. Odświeżam Vercela — podgląd się pojawia, wchodzę w domenę i strona działa.

Opakowanie mamy więc gotowe, mimo że produkt jeszcze nie. To ważne: da się zrealizować ideę sprzedawania przed budową, żeby zwalidować, że czas, który zamierzasz włożyć w produkt, się zwróci. A Codex sam z siebie, bez proszenia, zweryfikował, że wszystko działa.

Pierwsze spotkanie z wersją pierwszą

Wcześniej na to nie patrzyłem. Fable mówi, że wersja pierwsza jest skończona. Proszę o uruchomienie na osobnym localhoście.

Co zostało zweryfikowane, a nie tylko zbudowane: pełna ścieżka klienta z prawdziwymi wywołaniami modelu. Gdy klient wprowadzi informacje, trafiają one do modelu AI — prawdopodobnie do modelu Anthropic, bo to Claude budował. Za to płaci użytkownik w abonamencie. Można było zrobić rozliczenie za zużycie; to wybór modelu biznesowego. Tutaj wyszło tak, że masz subskrypcję i pewną liczbę generacji, a my ponosimy koszt API. Przy skalowaniu pojawią się z tym różne problemy do przemyślenia.

Dalej: „talia jest dobra — zrobiłem zrzuty ekranu każdego wygenerowanego PDF-a i obejrzałem je. Znalazłem i naprawiłem pięć defektów układu, potem potwierdziłem to na świeżej generacji. Skrypt kontroli dopasowania geometrii pilnuje teraz wszystkich dziesięciu slajdów”. Jeden pakiet kosztuje 16–20 centów. Każde wywołanie AI loguje tokeny i koszt w dolarach do panelu administracyjnego.

To oczywiście nie jest produkt skończony. Zostają otwarte punkty: klucze Supabase, Vercela, Anthropic. Ale mamy coś, na co można spojrzeć.

Otwieram localhost. To ClientPack. Są projekty. Jest sekcja marki i studiów przypadku — tu użytkownik wpisuje nazwę agencji, kolor, specjalizację, wgrywa logo i dodaje studia przypadku. Każda talia jest generowana w jego stylu, a pasujące studium przypadku może trafić automatycznie do materiału sprzedażowego. Jest sekcja rozliczeń: plan darmowy, zero z jednej talii, możliwość przejścia na płatny. Interfejs jest czysty i łatwy.

Mamy dwie talie klienckie — jedna w wersji roboczej, jedna gotowa. Klikam gotową: Radiant Skin Med. Otwiera się mały portal projektu. Widać, że talia jest gotowa, widać bóle, inwestycję, wartość miesięczną. Są przyciski: pokaż talię, edytuj, ustalenia, wygeneruj ponownie. Są transkrypty: rozmowa rozpoznawcza z 2 sierpnia i tekst rozmowy uzupełniającej z 6 sierpnia. Przy dodawaniu transkryptu można wrzucić pliki tekstowe, dokumenty, pliki VTT, dowolną liczbę — albo po prostu wkleić tekst. Są też szczegóły projektu: nazwa klienta, czym się zajmuje, co jeszcze warto wiedzieć.

Otwieram talię. Dziesięć slajdów do przewijania, można też pobrać PDF.

Slajd pierwszy: nazwa naszej agencji, miejsce na logo, kolory zaciągnięte z ustawień. Klient: Radiant Skin Medspa. Hasło: „Zapełnij fotele, które już masz zarezerwowane, bez zwiększania wydatków na reklamę”. Przygotowane przez nas, data.

Slajd „gdzie jesteś dziś”: pięć terminów tygodniowo przepada pusto; zapytania, za które już zapłaciłeś, czekają na odpowiedź całymi dniami; klienci po botoksie potrzebują poprawki po dwunastu tygodniach i nikt ich o to nie pyta. System wyciągnął konkretne cytaty, w których klient sam nazwał swój ból. To wzmacnia przekaz — trzy bóle poparte prawdziwymi cytatami z rozmowy rozpoznawczej. Klient widzi, że nie przepuściliśmy go przez generyczny prompt, tylko odnosimy się do tego, co realnie powiedział.

Slajd „prawdziwe ograniczenie”: przyszli z „potrzebujemy więcej leadów”, ale prawda jest taka, że potrzebują trzydziestu minut po zapytaniu i dwunastu tygodni po wizycie. Ten reframing ustawia nas jako konsultantów i długofalowych partnerów myślowych, a nie jako wykonawców przyjmujących zamówienia.

Dalej plan w trzech krokach. Potem metryki: pięć tygodniowo schodzi do dwóch, pierwsza odpowiedź z około dwóch dni do poniżej pięciu minut, powtarzalne rezerwacje zabiegowe z około czterech do dziesięciu miesięcznie. Potem matematyka: ile inwestujesz i co to zwraca w pierwszym roku. To oczywiście musi być poparte prawdziwymi danymi i liczbami, które klient sam podał. Ale sam framework — mamy jako konsultanci system, tak pracujemy z firmami, tak pokazujemy wartość i ROI — buduje profesjonalizm. To jak posiadanie własnej metodyki.

Dalej procesy: jak wygląda proces ręczny i jak będzie po wdrożeniu, plus wizualizacja. Ta akurat mogłaby być lepsza, ale już teraz pozwala pokazać: tu jest wyzwalacz, tu jest krok, tu zapada decyzja, tu wchodzi AI, a tu nadal pracuje twój zespół. Potem „dlaczego my” ze studiami przypadku, zakres z tym, co wchodzi i co nie wchodzi, oraz inwestycja i następne kroki. To nie jest formalna umowa do podpisu — to raczej „odbyliśmy trzy rozmowy, oto czego się dowiedzieliśmy, oto jak widzimy współpracę, wchodzicie w to?”.

Mogę wrócić do projektu i edytować ustalenia: zmienić wagę bólu, przesunąć go wyżej lub niżej, pobawić się metrykami, a potem kliknąć „wygeneruj talię ponownie”. Wersja robocza jest chyba robocza dlatego, że nie ma jeszcze transkryptu.

Jak na pierwszy dowód koncepcji jestem zadowolony. Ale teraz trzeba sprawdzić, czy wszystko działa, bo z pewnością są tu błędy, których jeszcze nie znaleźliśmy. Nie przeszliśmy też onboardingu. Klikam „wyloguj” w lewym dolnym rogu — i nic się nie dzieje.

Zwróćcie uwagę: całą tę pracę mogliśmy wykonać samym Fable 5. Nie wiem, o ile byłoby lepiej, ale spójrzcie — od ostatniego sprawdzenia zużyliśmy 1% limitu Fable’a. Cały ten kod i decyzje szły przez routowanie do innych agentów, a nie przez realne obliczenia Fable’a. To świetny trik.

Codex jako łamacz aplikacji

Znowu robię session handoff, bo wchodzimy w rejony context rot. Czyszczę czat, wklejam podsumowanie i mówię: „oto co się właśnie stało, nic nie rób, dopóki nie powiem”.

Równolegle otwieram nowy czat w Codeksie w tym samym projekcie i wklejam ten sam handoff. Lubię używać Codeksa jako weryfikatora, gdy chodzi o otwieranie aplikacji i klikanie po niej — Codex jest znacznie lepszy w obsłudze komputera. Chcę, żeby założył projekt, wygenerował transkrypty, wklejał różne typy dokumentów i próbował zepsuć aplikację. Ma znaleźć błędy i dziury.

Prompt: „To jest wersja pierwsza ClientPacka, widzisz ją otwartą na localhoście. Użyj obsługi komputera i kliknij każdy przycisk. Pobaw się tym. Spróbuj to zepsuć. Znajdź błędy. Twoim celem jest powiedzieć nam, co trzeba naprawić, zanim wejdą prawdziwi klienci. Próbuj wgrywać różne formaty, generować talie, klikaj w różne przyciski i szukaj zarówno błędów wizualnych, jak i technicznych oraz ograniczeń funkcjonalnych. Kiedy przetestujesz to na wielu ścieżkach, poszukasz przypadków brzegowych i uznasz, że próbowałeś wystarczająco dużo, żeby z przekonaniem stwierdzić, czy ta wersja jest gotowa — daj znać, co trzeba zmienić.”

To otworzy przeglądarkę i Codex zacznie klikać. Świetne jest to, że niczego nie zmienia, więc w Claudzie mogę równolegle budować dalej, nie wchodząc mu w drogę.

W Claudzie mówię: „Codex testuje teraz wersję, którą mi dałeś. Wrócę z tym, co znajdzie. Ciebie pytam o co innego: jesteś Fable 5, orkiestratorem, nic nie wykonujesz, tylko zarządzasz zespołem podagentów na Opusie i Sonnecie i odpowiadasz za całość. Interesuje mnie ścieżka onboardingu. Jak to wygląda od początku aż do panelu, gdy klient przychodzi, subskrybuje, wdraża się i loguje? Gdzie trzymamy te dane na backendzie? Ta ścieżka musi być szybka, łatwa i płynna, inaczej stracimy płacących klientów już w onboardingu. Powiedz, czego potrzebujesz — Supabase, Stripe, cokolwiek.”

W przeglądarce Codeksa widać, jak próbuje. Wpisał kolor akcentu jako „red”, a potrzebny jest kod szesnastkowy, więc poprawił. Kursor porusza się sam — to Codex. Przetestuje mnóstwo wariantów i wróci z czymś w rodzaju „sprawdziłem tysiąc możliwości, które tobie zajęłyby dwanaście godzin”.

Pokażę jeszcze funkcję „by the way” — ukośnik pozwalający zadać Claude’owi pytanie bez przerywania głównego toku pracy. Pytam o stack backendowy do uwierzytelniania, żeby wiedzieć, jakie konta założyć. Odpowiedź: Supabase obsłuży uwierzytelnianie i będzie naszą bazą klientów, a Stripe wyłącznie płatności — nigdy nie dotknie warstwy autoryzacji. Klucz Anthropic już mamy.

Główna sesja ma dla nas pytania. Co nowy użytkownik dostaje przed zapłatą? To decyduje, czy checkout jest przed pierwszą talią, czy po. Odpowiadam: darmowa talia, ale ze znakiem wodnym. Cena docelowa: konfiguracja mówi 39 dolarów miesięcznie i 390 rocznie, a przedział z researchu to 29–49. Idę za rekomendacją, skoro poparta jest researchem.

Proponowana ścieżka: strona z cennikiem, rejestracja, checkout, trzystopniowy onboarding, pierwsza talia. Prosto. Trzeba tylko upewnić się, że działa, że subskrypcja faktycznie odnawia się cyklicznie i że da się ją anulować.

Supabase i Stripe: klucze, sandbox, tabele

Zakładam konto Supabase — jest darmowe na start. Nowy projekt, nazwa „client pack”, mocne hasło do bazy (zapamiętajcie je), włączone API danych z automatycznym udostępnianiem nowych tabel, reszta domyślnie. Potem konto w Stripie. Wiem, że to może onieśmielać — tyle nowego oprogramowania. Spokojnie: Claude powie dokładnie, czego potrzebuje i skąd to wziąć.

Claude tymczasem: decyzje zablokowane, dwaj pracownicy na Opusie budują, każdy w izolowanym work tree, żeby nie zakłócić testów Codeksa. Jeden robi lejek i kreator onboardingu, drugi znak wodny na darmowych taliach.

Trzeba wypełnić .env.local. Dla Supabase: załóż darmowy projekt, wejdź w ustawienia projektu, potem API, weź URL projektu, klucz anon i sekret roli serwisowej. Analogicznie dla Stripe’a. Nie widzę pliku .env, więc każę go utworzyć.

W Supabase wchodzę w ustawienia projektu i klucze API. Potrzebny URL projektu chwilę mi umyka — okazuje się, że to „API URL”. Kopiuję, wklejam. Potem klucz anon publiczny. Potem odsłaniam i kopiuję sekret roli serwisowej. Zapisuję i proszę Claude’a o weryfikację, a sam idę po klucze Stripe’a: w sekcji dla deweloperów, w kluczach API, mam klucz tajny i publikowalny.

Ważna rzecz, którą podpowiedział Claude: najpierw pracujemy w piaskownicy. W panelu Stripe’a przełączam się na nowy sandbox, w nim wchodzę w klucze API i widzę ostrzeżenie, że testuję w piaskownicy i żadne prawdziwe transakcje nie zostaną przetworzone. Podmieniam klucze na testowe. Kiedy cały potok od początku do końca będzie potwierdzony, wystarczy podmienić klucz testowy na produkcyjny i gotowe — cała logika w aplikacji już będzie na miejscu.

Mam nadzieję, że widzicie, na czym polega odblokowanie: nie musimy znać wszystkich wtyczek. Musimy tylko umieć zadać właściwe pytania, tak jakbyśmy rozmawiali z deweloperem, który zbudował dziesiątki produktów SaaS i integracji.

Teraz coś fajnego. Claude mówi, że potrzebujemy tabel w Supabase — a w edytorze tabel faktycznie jest pusto. I dodaje: „skopiowałem właśnie polecenie do edytora SQL do twojego schowka”. Wchodzę w edytor SQL w Supabase, wklejam, uruchamiam. Sukces, brak zwróconych wierszy. Wracam do tabel: jest ich osiem. Subskrypcje, transkrypty, zdarzenia użycia, talie, studia przypadku i tak dalej. Nie musiałem robić nic więcej, a Claude zna teraz strukturę i może pisać skrypty backendowe.

O prawdziwej fosie

Jest jeszcze jedna rzecz, kluczowa dla tej konkretnej aplikacji. Testujemy, czy wszystko działa technicznie: czy połączenia są dobre, czy przyciski działają. Ale co z faktyczną wartością tej aplikacji? Jej wartość polega na tym, że dostajemy naprawdę wysokiej jakości analizę. Nie chodzi o to, czy talia ładnie wygląda i czy wszystko się renderuje — chodzi o to, czy te informacje są trafne i prawdziwe.

I to jest po naszej stronie. Sposób, w jaki AI z tyłu analizuje transkrypty, zależy od nas. Wraca tu myśl, że można oddelegować myślenie i zbieranie danych, ale nie da się oddelegować rozumienia. Jeśli to tylko wyciąga generyczne treści z Opusa 5 czy innego modelu, to nie wystarczy.

Co bym zrobił? Użyłbym czegoś w rodzaju skilla „grill me” i powiedział: przemaglaj mnie ze wszystkiego, co wiem o komunikacji z klientami, pozycjonowaniu wartości, ROI, inwestycji i realistycznych rezultatach rozwiązań AI. A potem: weź te dane z dwudziestominutowego wywiadu i wpisz je w prompt, który analizuje transkrypty na backendzie.

Bo ostatecznie prawdziwym IP, prawdziwą fosą jest tutaj prompt siedzący za przyciskiem „analizuj” i „wygeneruj ponownie”. Każdy może odtworzyć całą tę aplikację w jeden dzień — to nie może być fosa. Fosą jest cała moja wiedza, całe doświadczenie i wszystkie miny, na które nadepnąłem, wbudowane w ten prompt. A w miarę dodawania kolejnych narzędzi pomagających prowadzić agencję, fosą stają się wszystkie dane i doświadczenia, które w to włożyłem. Nie to, czy Stripe współpracuje z aplikacją i czy ładnie wygląda. Za to nikt nie zostanie. Ludzie zostają dla IP, do którego nie mają dostępu.

Mówię o tym, bo nie zamierzam w tym filmie przez wiele godzin zrzucać z siebie wiedzy i optymalizować tego promptu. Ten materiał pokazuje, ile da się zrobić w jeden dzień — i, co ważniejsze, ile jeszcze zostaje do zrobienia potem. Przy każdym nowym kliencie pojawia się feedback, trzeba coś naprawiać. Klienci znajdą błędy. Klienci będą prosić o funkcje. Będziecie chcieli iterować. Tytuł tego filmu sugeruje budowę SaaS-a w jeden dzień, ale prawda jest taka, że w przestrzeni AI nie istnieje coś takiego jak skończony produkt. Mój system operacyjny zmieniam codziennie. Wszystkie skille zmieniam codziennie. Automatyzacje zmieniają się nieustannie. To nigdy nie jest gotowe, kiedy myślisz, że jest gotowe.

Raport Codeksa: to nie jest gotowe dla klientów

Codex skończył. Werdykt: to jeszcze nie jest gotowe dla klientów. Dlatego lubię używać innego modelu do znajdowania rzeczy, które Fable 5 i wszyscy jego pracownicy przeoczyli.

Dwa główne blokery premiery. Po pierwsze: przegląd i zatwierdzenie nie są egzekwowane — wygenerował prawdziwą talię, mimo że wywnioskowana wartość bazowa nie została potwierdzona. Potwierdził też, że przycisk ponownego generowania pozostaje aktywny przy zerowej liczbie bólów, zerowej liczbie rozwiązań, ujemnym zainteresowaniu, ujemnej inwestycji i pustych wymaganych ustaleniach. Po drugie: nieznane ROI produkuje slajd pokazujący klientowi zwrot „0x”, co oczywiście nie może się zdarzyć. Do tego lista błędów o wysokim i średnim priorytecie oraz lista rzeczy potwierdzonych jako działające.

Decyzja: oddać ten raport Fable’owi czy kazać Codeksowi naprawić to, co sam znalazł? Skoro dotąd budował głównie Claude i wciąż buduje coś innego, spróbujmy Codeksem.

Prompt przez /goal: „Odpowiadasz teraz za wszystko, co znalazłeś. Naprawiasz blokery i błędy wysokiego priorytetu; średnie na razie zostaw. Wykorzystaj zespół agentów — jesteś orkiestratorem i kierownikiem projektu. Podagenty, zespoły agentów, cokolwiek trzeba, żeby każdy agent skupił się na jednej bardzo konkretnej rzeczy i zrobił ją naprawdę dobrze. Pilnuj, żeby agenty się nie nadpisywały. Wiedz też, że w innej sesji Claude Code buduje właśnie ścieżkę onboardingu i płatności — nie ruszaj tego. Atakuj tylko blokery i błędy, które znalazłeś w aplikacji. Ostatecznie to ty odpowiadasz. Jeśli pójdzie źle, obwinię ciebie. Więc weryfikuj to, co robią podagenci. Możesz korzystać z obsługi komputera. Kiedy będziesz pewien, że wszystko naprawione i gotowe dla klientów w zakresie twojej pracy, zdaj raport.”

Szybkie podsumowanie stanu. Znaleźliśmy ból — dzięki analizie ponad sześćdziesięciu tysięcy komentarzy i wątków, i to zarówno moich własnych, jak i z Reddita i X. Sformułowaliśmy obietnicę. Mamy budowany produkt. Mamy hydraulikę: modele AI, API, hosting na Vercelu. Mamy opakowanie: logo, nazwę, aplikację listy oczekujących z panelem administracyjnym. I mamy dowód, bo weryfikujemy wszystko obsługą komputera i wywołaniami API, zanim cokolwiek wyślemy do ludzi.

Test onboardingu na własnej skórze

Codex naprawił wszystko i zweryfikował — uruchomił osiemdziesiąt pięć kontroli.

Claude z kolei przetestował Supabase: stworzył użytkownika testowego, zapełnił tabele i przeprowadził pełną ścieżkę klienta jako test dymny. Logowanie, zestaw marki i studium przypadku, utworzenie projektu, analiza za 4 centy, wygenerowanie talii za 9 centów, znak wodny, checkout i webhook Stripe’a, usunięcie znaku wodnego. Cała ścieżka nowego użytkownika: 13 centów za pełną talię.

Otwieram nowy localhost. Strona główna aplikacji: „dla agencji AI i twórców automatyzacji — zamień każdą rozmowę rozpoznawczą w propozycję gotową dla klienta”. Tej strony w ogóle nie projektowaliśmy; wcześniej projektowaliśmy tylko stronę listy oczekujących. Mają podobny klimat, bo korzystają z tego samego systemu projektowego. Zauważam jednak, że wersja Claude’a nie użyła prawdziwego logo ClientPacka. Do poprawy, ale to drobiazg.

Klikam „zacznij za darmo” i rejestruję konto. Hasło musi mieć osiem znaków. Adres musi być prawdziwy — o tę walidację nawet nie prosiłem, a jest. Rejestruję się prawdziwym Gmailem i dostaję komunikat, że muszę potwierdzić konto. Przychodzi mail z Supabase Auth — tego też nie musiałem konfigurować. Klikam potwierdzenie, które odsyła mnie na stronę listy oczekujących; to trochę dziwne, warto poprawić.

Loguję się. Widzę ekran konfiguracji: „trzy rzeczy i działasz”. Zestaw marki — wpisuję nazwę, wybieram jasnoniebieski, wgrywam logo, zapisuję. Studium przypadku — wrzucam szybki przykład; tu normalnie poświęcilibyście czas na własne case’y. Pierwszy klient.

Wracam na chwilę do Codeksa i proszę o przykładową nazwę klienta, opis działalności i transkrypt rozmowy do wklejenia. Klikam „utwórz projekt”. Dalej znany ekran: transkrypt, przycisk analizy rozmowy, pasek postępu analizy.

Po analizie system wypełnia bóle, ograniczenia i całą resztę. I zanim spali nasze tokeny i subskrypcję użytkownika na budowanie talii — bo to bardziej kosztowny krok — prosi o przegląd i potwierdzenie. To bardzo istotne. Czytamy bóle, oceniamy ich wagę, sprawdzamy, czy cytaty się zgadzają, poprawiamy to, co trzeba. Jeśli klient szczególnie coś podkreślał w rozmowie, dopilnujemy, żeby talia to uwypukliła. Zaznaczam „sprawdziłem bóle, metryki, cele i inwestycję — to jest gotowe do pokazania klientowi” i klikam „generuj talię”.

Jest prawie 15:00. Blisko sześć godzin pracy.

Talia gotowa: trzy bóle, inwestycja 12 000 dolarów, wartość miesięczna 11 932 dolary. Nie jestem do końca pewien, skąd dokładnie ta druga liczba — wygląda na to, że przy inwestycji 12 000 dolarów zwrot następuje w pierwszym miesiącu. Otwieram talię: nasze logo, nasza kolorystyka, ten sam kolor, który wpisałem. Wszystko spójne. Za każdym razem dziesięć slajdów i ten sam powtarzalny układ, więc prezentując to klientom, szybko dojdziecie w tym do wprawy. Jest mały diagram, jest sekcja dowodu, jest zakres i finalne wezwanie do działania.

Na dole po prawej: darmowa talia nosi znak wodny „made with ClientPack”. Klikam „ulepsz”. Zużyliśmy jedyną darmową talię; plan kosztuje 39 dolarów miesięcznie. Otwiera się checkout — piaskownica Stripe’a, 39 dolarów miesięcznie. Płacę fałszywą kartą (Stripe ma w dokumentacji listę kart testowych). Mamy aktywny plan, odnowienie 9 września, jedna z 25 talii wykorzystana. Gdybym chciał anulować, wchodzę w zarządzanie płatnościami i trafiam do portalu Stripe’a, gdzie mogę zaktualizować dane. To wszystko obsługuje Stripe — ludzie wiedzą, jak anulować subskrypcje.

Wracam do projektu, otwieram talię: znak wodny zniknął, bo jesteśmy na planie płatnym.

Zaglądam do bazy. W Supabase mam tabelę talii z czasem utworzenia i treścią, studia przypadku przypisane do identyfikatora użytkownika, profile marek z kolorami, logotypami i opisem działalności. Identyfikator użytkownika jest kluczem wiążącym wszystkie tabele. Są też subskrypcje. Niczego z tego nie konfigurowałem — to system sam powiązał tabele.

Po stronie Stripe’a, w piaskownicy, w transakcjach widzę dwie subskrypcje: 39 dolarów, status „udana”, i utworzenie subskrypcji. W produktach mam ClientPack za 39 dolarów miesięcznie albo 390 rocznie, z dwiema aktywnymi subskrypcjami — czyli za miesiąc naprawdę zostaną obciążeni. W Stripie jest bowiem różnica między subskrypcją a produktem jednorazowym.

Pomyślcie o tym: wystarczyło dać Claude Code i Codeksowi klucze API do Stripe’a i Supabase. Całą hydraulikę zrobiły same, żebyśmy my mogli skupić się na bólu, obietnicy, doświadczeniu produktu, opakowaniu i dowodzie. Nudne, techniczne rzeczy AI bierze na siebie. I widzieliście każdy prompt, który dziś wysłałem. Jestem w stu procentach przekonany, że każdy z was mógłby je powtórzyć albo pokierować agentami w ten sam sposób.

Audyt bezpieczeństwa

Są jednak rzeczy, o których trzeba pomyśleć osobno. Bezpieczeństwo robię w Codeksie, bo trochę bardziej ufam jego weryfikacji i podejściu do bezpieczeństwa — wydaje się bardziej skłonny trzymać się polecenia i nie schodzić ze ścieżki, podczas gdy Claude bywa kreatywny.

Czyszczę sesję i wklejam swój prompt do przeglądów bezpieczeństwa. Każe on audytować pod kątem OWASP 5.0 — to publiczne repozytorium na GitHubie z materiałami o bezpieczeństwie, którego link też podaję. Skoro mamy uwierzytelnianie i przetwarzanie płatności, chcemy mieć większą pewność, że nikt nie włamie się do aplikacji i nie wyciągnie danych klientów, na przykład informacji o kartach.

Na początku dopisuję kontekst: skończyliśmy wersję pierwszą ClientPacka, przygotowujemy się na pierwszych klientów, którzy będą zakładać konta i korzystać z produktu, więc chcemy przejść kontrole bezpieczeństwa.

Równolegle informuję Claude’a: „Codex sprawdza teraz bezpieczeństwo — czy da się nas przeciążyć, wykorzystać, wstrzyknąć prompt, ukraść coś, wyciec dane. Ja przeszedłem całą ścieżkę: założyłem konto, zapłaciłem, wszystko zadziałało, dobra robota. Teraz chcę pomyśleć o wypuszczeniu tego w świat i zapraszaniu ludzi do testów. Jaki jest twój plan? Jak wypchnąć to na GitHuba, jak wdrożyć, jak zarządzać użytkownikami przy skalowaniu? Powiedzmy, że pierwszym kamieniem milowym jest 50 płacących użytkowników. Jak tam dojść i jak to obsłużyć?”

Odpowiedź: faza pierwsza w tym tygodniu to GitHub i wdrożenie na środowisko przejściowe. Repozytorium ma już czystą historię, a przed wypuszczeniem czegokolwiek z maszyny trzeba przeskanować wszystko, czy nic wrażliwego nie trafiło do commitów. Repozytorium ma być prywatne, a Vercel będzie wdrażał wprost z GitHuba przy każdym pushu.

Faza druga to przejście na produkcję: Stripe w tryb live, włączenie potwierdzania e-maili w Supabase, strony regulaminu i polityki prywatności (dobry pomysł — trzeba je napisać i zadbać, żeby użytkownicy je akceptowali) oraz śledzenie błędów, czyli logowanie wszystkich działań i alerty przy błędach.

To ważny wątek w debacie „budować czy kupić”. Owszem, wiele rzeczy można teraz zbudować, ale gdy budujesz, bierzesz na siebie piłkę, którą trzeba żonglować już zawsze. Ktoś w zespole jest za nią odpowiedzialny. Tak samo z SaaS-em: idea „zbuduję raz i będę sprzedawał w nieskończoność” pomija ogrom utrzymania.

Faza trzecia to pierwszych pięćdziesięciu płacących użytkowników. Odpowiedź infrastrukturalna jest nudna, czyli dobra: pięćdziesięciu użytkowników to dla tego stacku nic. Supabase Pro za 25 dolarów miesięcznie dla kopii zapasowych, Vercel Pro za 20 dolarów. W najgorszym razie inferencja przy pełnym limicie to 3 dolary na użytkownika miesięcznie przy 39 dolarach, które płaci — dobre marże.

Dalej pętla operacyjna: zapraszać partiami, a nie wszystkich naraz; mieć kanał informacji zwrotnej; mieć wsparcie, bo obsługa klienta to coś, z czym trzeba się zmierzyć. Pojawią się problemy z płatnościami, ludzie zablokują sobie konta, zapomną hasła — automatyczny reset trzeba wbudować w aplikację. Trzy liczby do oglądania co tydzień: rejestracje, wygenerowanie pierwszej talii (czyli aktywacja) i konwersja z pierwszej talii na płatność. Plus obserwowanie ceny.

Od strony technicznej nic mnie tu nie zaskakuje, ale cieszę się, że Claude potwierdził schemat: GitHub jako miejsce kodu, commitów i pull requestów, Vercel jako miejsce wdrożenia pod naszym adresem. Domenę można kupić w Vercelu albo na Namecheapie, GoDaddy, w Squarespace czy Wixie. Jeśli macie już domenę, wystarczy skierować rekordy DNS — Claude przeprowadzi was przez to krok po kroku.

Codex tymczasem przeprowadza test dwóch najemców i coś już mu nie przeszło. To przegląd tylko do odczytu, więc na razie tylko raportuje.

(Informacja dodatkowa: „test dwóch najemców” sprawdza izolację danych między kontami — czy użytkownik A nie może dostać się do danych użytkownika B. To podstawowa kontrola w aplikacjach wielodostępnych.)

Werdykt: ClientPack nie jest gotowy do przyjmowania klientów. Cztery blokery premiery o wysokiej wadze plus krytyczny warunek konfiguracyjny, który trzeba wykluczyć przed wdrożeniem. I bądźmy szczerzy — tych rzeczy sam bym nie znalazł, nawet przeglądając kod. Potrzebowałbym zdolnego inżyniera. Ale skoro mogę dać Codeksowi taką ekspertyzę, a modele są w cyberbezpieczeństwie coraz lepsze, czuję się z tym pewniej.

Znalezionych rzeczy jest około dziesięciu, z czego cztery oznaczone jako wysokiego priorytetu. Jest też lista rzeczy, które przeszły przegląd, i lista tych, które muszę zweryfikować sam jako człowiek: przełączenie trybu demo na fałsz, klucze Stripe’a, rotacja klucza Anthropic.

Znów /goal: „Cieszę się, że znalazłeś te podatności, zanim weszli klienci. Powołaj zespół agentów, graj kierownika projektu, każdemu agentowi jedno konkretne zadanie, a ty jesteś weryfikatorem. Nie zatrzymuj się, dopóki nie będziesz w stu procentach pewien, że wszystkie podatności są usunięte.” Formuła /goal sprawia, że model będzie iterował, pisał testy i uruchamiał je, aż uzna sprawę za zamkniętą. Jeśli coś blokuje mnie jako człowieka, ma to zostawić na koniec i wypisać w raporcie.

GitHub, zmienne środowiskowe i wdrożenie

Wracam do Claude’a. Proszę o prywatne repozytorium dla aplikacji i przy okazji o naprawienie logo na stronie rejestracji — mamy prawdziwe logo gdzieś w projekcie.

Wyjaśnię kwestię zmiennych środowiskowych w Vercelu. Wszystkie pliki projektu trafią na GitHuba — dzięki temu mogę pracować z laptopa, ktoś inny może współpracować. Ale pliki .env i wszystko wymienione w pliku ignorowanych nie trafiają na GitHuba. To wbudowane zabezpieczenie: nie chcecie mieć kluczy API wystawionych w sieci.

Problem w tym, że skoro Vercel nie ma tych kluczy, nie sięgnie do Supabase, Stripe’a ani Anthropic. Dlatego w Vercelu, w konkretnym projekcie, ustawia się zmienne środowiskowe. Wpisujecie klucz i wartość, tyle ich, ile trzeba. Jedyna droga do nich prowadzi przez zalogowanie się na wasze konto Vercela. Jeśli wdrażaliście automatyzacje na Modalu albo trigger.dev, to dokładnie ta sama mechanika.

Logo naprawione, repozytorium żyje. Lista zmiennych do dodania w Vercelu: tryb demo na fałsz, klucz Anthropic (najpierw zrotowany), dane Supabase, sekret roli serwisowej oznaczony jako wrażliwy, dane Stripe’a i adresy administratorów. Dwie wartości nie dadzą się ustawić przed pierwszym wdrożeniem, bo zależą od adresu przypisanego przez Vercela: publiczny adres strony oraz sekret webhooka Stripe’a, który tworzy się w panelu Stripe’a w sekcji webhooków.

Claude proponuje: podepnij repozytorium w Vercelu i powiedz mi, gdy projekt będzie istniał; a jeśli uruchomisz vercel login w terminalu, sam zajmę się zmiennymi, dwuetapowym ponownym wdrożeniem i testem dymnym PDF-a. Zgoda.

I znów: całą tę pracę zrobiliśmy, zużywając 7% limitu Fable’a. Idea polegająca na tym, żeby Fable tylko orkiestrował i myślał z wami, nie zjada limitów. Wypalacie je wtedy, gdy mówicie „Fable, zbuduj mi aplikację” — wtedy robi się bardzo drogo, bardzo szybko.

Autoryzuję Claude Code do korzystania z CLI Vercela. Model konfiguruje projekt, wgrywa zmienne, oznacza wrażliwe, uruchamia pierwsze wdrożenie.

Równolegle rotuję klucz Anthropic. Wchodzę w konsolę, tworzę nowy klucz o nazwie „client pack” bez wygasania, kopiuję go, a stary wyłączam. Nowy wklejam do .env.local i informuję Claude’a, żeby wypchnął go do zmiennych Vercela.

Na marginesie: te wszystkie kolorowe ikonki w Codeksie to poszczególne podagenty. Zielony skończył, żółty pracuje, czerwony też. Można w nie kliknąć — tak samo jak w aplikacji Claude’a — i zobaczyć wysłany prompt oraz to, co robią. Ta ikonka oznacza korzystanie z przeglądarki; po kliknięciu widzę, jak Codex nawiguje po ClientPacku i sprawdza, czy wszystko gra. Warto po prostu popatrzeć, jak Codex albo Claude pracują — dużo się dowiecie o tym, jak działają pod maską.

Vercel utworzył projekt pod adresem clientpack.vercel.app. To jedyny projekt, który nie jest jeszcze podpięty do repozytorium Gita, więc zaraz to zrobimy.

16:14 — siedem godzin i prawdziwa domena

Wszystko jest już wypchnięte na Vercela. Wchodzę na clientpack.vercel.app — działa prawdziwa strona z poprawionym logo. To jest oddzielne od strony listy oczekujących. Skoro lista nie jest już potrzebna, możemy kierować ludzi tutaj.

Od strony projektowej kilka rzeczy bym zmienił. Tę stronę zrobił Claude, a listę oczekujących Codex — i szczerze wolę wersję Codeksa. Powiedziałbym: dopasujcie klimat strony głównej do tamtej. Ale mamy, co mamy.

Loguję się kontem, które już mamy — działa, bo obie wersje siedzą na tej samej bazie. Wylogowuję się. Wdrożenie nie jest jeszcze podpięte do repozytorium GitHuba, co znaczy, że nie będzie się aktualizować samo; musiałbym prosić Claude’a o aktualizację przez CLI. Chcemy to zmienić.

Najpierw sprawdzam Codeksa. Pracował około 45 minut i naprawił mnóstwo rzeczy. Zrotowaliśmy klucz, zrobiliśmy wszystko z listy. Weryfikacje: siedem na siedem w atakach na najemców aplikacji, kontrole migracji bazy, strażnik webhooka, mapowanie Stripe’a, ataki przez logo, ataki przez PDF. Cieszę się, że poświęciliśmy na to czas — i to jest coś, co zapewne warto robić co tydzień, w miarę jak dołączają użytkownicy i rośnie kod.

Proszę Claude’a o scalenie wszystkiego w jedną gałąź główną i wypchnięcie najświeższej wersji na GitHuba, żebym mógł podpiąć repozytorium do Vercela dla automatycznych wdrożeń, a potem ustawić własną domenę. W repozytorium widać 55 commitów — tyle wersji powstało w ciągu dnia.

W zmiennych środowiskowych ClientPacka w Vercelu jest wszystko, co Claude tam zapisał. Ręcznie musielibyśmy to wklepywać po kolei. Jedyne, co zostanie do zmiany, to przejście na prawdziwe rozliczenia: wychodzimy z piaskownicy Stripe’a, bierzemy prawdziwe klucze — poznacie je po prefiksach pk_live i sk_live zamiast pk_test i sk_test — i mówimy Claude’owi, żeby zaktualizował zmienne w Vercelu.

Najnowsza wersja jest już żywa i podpięta jako repozytorium. Po drodze pojawiły się problemy: czasem Codex albo Claude próbuje wypchnąć zmiany, a wdrożenie na Vercelu się blokuje. Wystarczy opisać im, co się dzieje, i naprawią. W tym filmie wdrożenia na Vercelu nie szły gładko — zwykle push na GitHuba i przejęcie przez Vercela to niewidoczna formalność, ale od czasu do czasu trafia się problem. Rozwiązania są proste.

Kupuję domenę. Robię to przez Vercela dla uproszczenia; jeśli macie domenę gdzie indziej, wnosicie ją rekordami DNS, a Claude albo Codex przeprowadzi was przez to. Biorę getclientpack.com, dodaję do projektu produkcyjnego, klikam „add domain”. Gdybyście wnosili domenę z zewnątrz, Vercel podałby, co wpisać w rekordzie A i CNAME.

Test finalny. Loguję się na wcześniejsze konto — i zostaję wyrzucony. Próbuję ponownie. Logowanie nie działa.

Dlatego trzeba uważać nawet przy zwykłej migracji z jednego środowiska do drugiego. Podejrzewam uwierzytelnianie albo zmiany po audycie bezpieczeństwa; przy okazji Codex dodał dwie kolejne tabele do lepszego śledzenia zdarzeń i zgodziłem się na to. Zaglądam do subskrypcji — jedna jest anulowana, ale nie sądzę, żeby to było przyczyną.

Piszę do Codeksa: „Na Vercelu wyglądało, że działa, ale gdy próbuję zalogować się do aplikacji, po kliknięciu przycisku wyrzuca mnie na stronę z informacją, że nie działa. Pomóż ustalić dlaczego.” Dziwne, bo przed chwilą logowanie działało — tyle że pod adresem vercel.app, a nie pod prawdziwą domeną. Sprawdzam jeszcze raz: tak, problem dotyczy prawdziwego adresu. Dopisuję ten kontekst.

Codex już to zdiagnozował: „Znalazłem mocny trop występujący wyłącznie na produkcji. Nieudane logowanie przyszło z getclientpack.com, ale żądanie zatrzymało się w middleware bezpieczeństwa i nigdy nie dotarło do akcji logowania. To pasuje do ochrony przed atakami międzywitrynowymi, która odrzuca formularz, gdy publiczny adres strony jest skonfigurowany na inną nazwę hosta — najpewniej clientpack.vercel.app. Potwierdzam status odpowiedzi i skonfigurowaną nazwę hosta, zanim cokolwiek zmienię.”

To ma sens. Codex zmienia zmienną, potwierdza, że tabele bezpieczeństwa Supabase są wdrożone, i wdraża ponownie. Otwieram prawdziwy adres — ładuje się trochę dłużej, ale działa, a dane są na miejscu.

Wylogowuję się i rejestruję nowe konto już na prawdziwej domenie. Prośba o potwierdzenie, mail z Supabase Auth, potwierdzenie — i znów ląduję na liście oczekujących. Gdyby mnie to naprawdę irytowało, zmiana celu tego odnośnika to jeden prompt.

Jestem zalogowany, przechodzę onboarding, ale przeskakuję od razu do rozliczeń, bo onboarding już widzieliśmy. 39 dolarów miesięcznie, strona Stripe’a (wciąż piaskownica) — chodzi o sprawdzenie, czy działa na nowej domenie. Działa. Jesteśmy na planie miesięcznym z pulą 25 talii. Dane i hasło zapisują się na koncie, uwierzytelnianie działa, subskrypcja jest ustawiona. W tabeli Supabase po odświeżeniu widać nowy wpis. Zostałoby tylko wyjście z piaskownicy Stripe’a, pobranie prawdziwych kluczy i wgranie ich do Vercela — i zaczynamy przyjmować prawdziwe płatności.

Bilans dnia

Jest 17:10, czyli pracujemy nad tym od mniej więcej dziewiątej rano — około ośmiu godzin. Ale to nie było osiem godzin siedzenia przy biurku. Zrobiłem dziś jeszcze kilka innych projektów, zjadłem lunch, poszedłem na siłownię, byłem na spacerze. Mogłem pracować nad tym cały dzień, bo widzieliście mnie właściwie tylko myślącego o tym, czego chcę, i promptującego to dość starannie. Większość roboty odbywała się, gdy siedziałem i pilnowałem, żeby nic dziwnego się nie działo, i dawałem informację zwrotną. Sterowałem.

Najważniejszy wniosek: nie zbudujecie SaaS-a w jeden dzień i nie wyskalujecie go do miliona dolarów. Możecie natomiast w stu procentach zbudować listę oczekujących, zacząć budować pomysły, dema i dowody koncepcji, wysyłać je do ludzi, a nawet ruszyć z pozyskiwaniem klientów. Ale nie zbudujecie aplikacji w jeden dzień, nie wystrzelicie jej na Księżyc, nie zarobicie miliona i nie zapomnicie o niej. To po prostu nierealistyczne. Odkąd zajrzałem za kulisy tego, czego naprawdę wymaga budowa SaaS-a opartego na AI, wiem, ile jest utrzymania, gdy rośnie liczba użytkowników i przepustowość — a do tego dochodzi wsparcie i cała reszta, zwłaszcza jeśli chcecie budować markę, a nie szybki skok po gotówkę.

Pierwszych pięćdziesięciu klientów

Zbudowaliśmy, więc porozmawiajmy o zdobywaniu klientów, zatrzymywaniu ich i podejmowaniu decyzji biznesowych. To zresztą tylko jedna iteracja pętli — będziecie ją powtarzać, ulepszać, aktualizować. Taka jest natura produktu.

Myślcie o pierwszych pięćdziesięciu klientach. Do różnych poziomów skali potrzeba różnych rzeczy — technicznej infrastruktury, ale też innych zatrudnień i innych automatyzacji. Byłoby wręcz fatalnie dla biznesu, gdybyście zbudowali produkt i następnego dnia zapisało się dziesięć tysięcy osób. Pewnie by się rozsypał, zniszczyłoby to reputację, a wy nauczylibyście się mnóstwa lekcji za późno. Myślcie fazami: pierwszych dziesięciu klientów, pierwszych pięćdziesięciu.

Więcej uwagi nie uratuje niejasnej oferty. Mam dystrybucję: kanał na YouTubie, społeczność. Ale to nie znaczy, że mogę automatycznie sprzedać dowolne narzędzie SaaS, bo oferta musi być krystalicznie czysta.

Dlatego zaczynaliśmy od bólu. Pomyślcie, co mówią ludzie, którzy coś wynaleźli: „zobaczyłem ten problem we własnym życiu i musiałem go rozwiązać, bo nie znalazłem niczego, co by go rozwiązywało”. To jest ból.

Potem musicie mówić do jednej konkretnej osoby. To samo dotyczy usług i kanału na YouTubie — cokolwiek robicie, celujecie w jedną konkretną osobę. Musicie zawęzić, bo jeśli mówicie do całego świata, większość świata nie poczuje dokładnie tego bólu i nie będzie zainteresowana.

Obietnica to odpowiedź na pytanie, jak wasze narzędzie, usługa czy oferta rozwiązuje ten ból. Kiedy te trzy rzeczy są jasne, macie ofertę, którą da się sprzedawać, bo umiecie ją zakomunikować. Prawdopodobnie macie w życiu ból, który rozwiązują setki istniejących narzędzi — tyle że o nich nie wiecie, bo nikt wam tego nie zakomunikował dość jasno.

W naszym przypadku: osoba to właściciel agencji pracujący z klientami. Ból to napływające rozmowy sprzedażowe, propozycje na wczoraj, brak spójnego frameworka do ich tworzenia i nieumiejętność zakomunikowania wartości oraz uzasadnienia ROI. Obietnica: wrzucasz transkrypty — czyli po prostu siedzisz na spotkaniu, rozmawiasz, robisz discovery, ustalasz wartość systemów, robisz swoją robotę konsultanta — a w niecałą godzinę dostajesz talię gotową dla klienta.

Dlaczego dołączyłem do Glido

Powiem szybko, dlaczego zostałem współzałożycielem Glido razem z Giannisem Moore’em, Jackiem Robertsem, Dave’em Eelarem i Yorsem Eelarem, który woli pozostawać tajemniczą postacią w tle. Po części dlatego, że to dobrzy znajomi z branży, robiący świetne rzeczy, i chciałem z nimi popracować.

Ale realniej: sam czułem ten ból i wiedziałem, że moja widownia też go czuje. Używałem Whisper Flow. Pewnych rzeczy w nim nie lubiłem — czasem wydawał się wolny, czasem dziwnie formatował. A pod każdym filmem ludzie pytali: co to za narzędzie, jak ty dyktujesz? Ból był wyraźny po obu stronach, a obietnica jasna: możesz być produktywniejszy, bo mówisz do dowolnej aplikacji. Pomyślałem, że fajniej byłoby być częścią czegoś, niż mieć tylko link afiliacyjny do Whisper Flow — nie z myślą o wielkim wyjściu z inwestycji czy pieniądzach, tylko dlatego, że mogę dzielić się tym ze społecznością, słuchać jej, przekazywać feedback zespołowi i wspólnie iterować w stronę wizji. Nauczyło mnie to sporo o różnicy między biznesem usługowym a produktem SaaS.

Konkurenci i koszt przełączenia

Myśląc o swojej osobie, pamiętajcie, że inne oferty i produkty prawdopodobnie mają ten sam awatar. Sprawdźcie więc, jakie są konkurencyjne narzędzia, ile kosztują, gdzie leży wartość. Pobierzcie narzędzie, poużywajcie chwilę, zobaczcie, co się podoba, a co nie. Idźcie na Reddita i X i sprawdźcie, na co ludzie narzekają. To, co w konkurencie najgorsze, u was ma być lepsze.

Bo żeby ktoś porzucił narzędzie, którego już używa, musi zobaczyć wyraźny zysk — jest coś takiego jak koszt przełączenia. Albo jest o połowę taniej, albo macie funkcję, której obecny dostawca nie ma. Musi istnieć jasny powód. Przeskoczenie na nowe narzędzie jest, moim zdaniem, trudniejsze niż zapisanie się na coś, gdy nie ma się jeszcze żadnego rozwiązania. Przełączanie jest trudne.

Walidacja przed budową i głód danych

Mówiliśmy o sprzedawaniu przed budowaniem — dlatego pokazywałem stronę i listę oczekujących. Zwalidujcie pomysł, zanim włożycie w niego mnóstwo czasu. Jeśli wyślecie to do setek osób i nikt nie jest na tyle zainteresowany, żeby zostawić e-mail albo choćby zadać pytanie, to sygnał: albo źle wybraliście osobę, albo — jeśli osoba jest dobrze dobrana, a nikt się nie zapisuje — oferta nie jest dość wartościowa, bo nie podświetliliście dość mocno bólu albo obietnicy.

Wiele z tego sprowadza się do jednego: potrzebujecie danych. Na starcie nie macie ich prawie wcale, a to dane pozwalają podejmować decyzje. Musicie więc znaleźć ludzi, którzy już szukają. Przy ClientPacku wiem, że ludzie tego szukają, bo mówią o tym w mojej społeczności, w komentarzach na YouTubie i pewnie na Reddicie. Mogę tam napisać: „buduję coś takiego, jeśli was interesuje, zapiszcie się, chętnie wezmę was jako użytkowników bety i przyjmę feedback”. Jeśli odzew będzie dobry, wiem, że buduję dalej.

Potem trzeba przejść do pomagania i dowożenia wyników ręcznie. Na starcie robicie mnóstwo rzeczy, które się nie skalują. Trzeba pobrudzić sobie ręce, robić rzeczy ręcznie i po prostu włożyć więcej czasu. Tak wygląda odrywanie się od ziemi.

Polecam przy okazji odcinek podcastu Starter Story z człowiekiem, który doprowadził dwa produkty SaaS do trzech milionów dolarów rocznego przychodu w kilka lat. Opowiadał o swoim playbooku na pierwszych stu użytkowników i padło tam zdanie: rób rzeczy, które się nie skalują. Siedział w wątkach na Reddicie, osobiście jako założyciel odpowiadał na pytania i dawał ludziom darmowe dema. Tworzyła się pętla: mam społeczność zainteresowaną tematem, publicznie pokazuję, co narzędzie robi, ludzie klikają w demo, widzą to i wszystko dzieje się jawnie. To około czternastu minut i jest tam sporo złota.

Chodzi o to, żeby być strategicznym w tym, gdzie się pojawiacie, i znaleźć miejsca, w których żyją ludzie szukający waszego produktu — społeczności, kanały na YouTubie, twórcy.

Dowód jako jedyna niepodrabialna rzecz

Kiedy kilka osób użyje produktu i będzie miało opinię, studium przypadku albo konkretny wynik — to jest coś, czego nikt nie odtworzy. Zastanówcie się, czego nikt nie może powtórzyć ani ukraść. Technologię mogą ukraść. Prompty przy odrobinie zabawy pewnie też. Dzięki AI bardzo wiele da się zduplikować.

Widziałem cytat Sama Altmana z wywiadu u Gary’ego Tana: rzeczy, które na początku zajmowały jemu i jego zespołowi trzy miesiące, robi teraz w jakieś siedem minut. Może to lekka hiperbola, ale sens jest taki, że zrobicie w dzień to, na co zespoły potrzebowały miesięcy. Skoro tak, trzeba pytać o fosę.

Dlatego przy ClientPacku uważam, że nie sprzedawałbym tego za 39 dolarów miesięcznie — przynajmniej nie w obecnym stanie. Dałbym to za darmo, z pięcioma taliami, a dopiero potem próbował budować subskrypcję. Jako repozytorium open source ludzie by to pokochali, ale nie sądzę, żeby chcieli za to płacić, skoro mogą to odtworzyć. Jedyną prawdziwą fosą w moim ClientPacku było promptowanie — i gdybym poświęcił mu więcej czasu, byłoby lepsze. Ale to i tak niezbyt obronna pozycja.

Dowód natomiast jest obronny. Dowodu nikt nie powtórzy, bo to wasz klient i wasze narzędzie. Kiedy zbierzecie dowody i studia przypadku, pomyślcie, jak wpuścić je z powrotem w koło zamachowe. Tak jak przy skalowaniu bierze się przychód i wkłada z powrotem w biznes, zamiast kupować zegarki — tak samo z opiniami. Wkładacie je w copy, w newsletter, na stronę. Trzeba te dane reinwestować. A potem powtarzać cykl.

Playbook na jeden tydzień

Jak przełożyć to na tydzień działania? Znajdźcie trzydzieści osób odpowiadających waszemu typowi kupującego. Można tu zrobić trochę zimnego kontaktu, bo to będą bardzo osobiste wiadomości, nieautomatyzowane. Zbieracie dane. Rozmawiacie. Co myślisz o tym narzędziu? Czy brzmi wartościowo? Ile byś za nie zapłacił?

Nie wiem, czy robiliście to na studiach, ale ja chodziłem na takie badania, gdzie laboratoria płaciły za godzinę spróbowania płatków śniadaniowych czy udziału w drobnych eksperymentach. Myślałem: co za okazja, przecież nic nie robię. A powód jest taki, że oni zbierali dane pierwotne — dane, których nikt inny nie ma, bo sami przeprowadzali eksperymenty. Byli gotowi za to płacić, bo z tych danych da się podjąć decyzję popartą faktami.

Uważam, że jest wartość w ufaniu intuicji, ale ostatecznie najlepsze decyzje opierają się na danych. Na starcie musicie próbować, rzucać różnymi rzeczami o ścianę i patrzeć, co się przyklei, bo danych nie macie. Ale w miarę rozwoju biznesu danych przybywa. Byłoby wstyd ich nie wykorzystywać, bo dane to kolejna ogromna fosa. Pomyślcie o Anthropic i OpenAI — mają tyle danych, że mogą nimi trenować lepsze modele. Sądzę, że ostatecznie modele w dużym stopniu się wyrównają, właśnie dlatego, że te firmy mają tak dużo danych i wykorzystają je na różne sposoby. Te dane są niesamowicie cenne. Korzystajcie ze swoich.

Pricing i moment „aha”

Pricing to jedno z najciekawszych pytań w biznesie — i kwestia kalibracji. Spróbujecie jakiejś ceny, nie zadziała, poprzesuwacie ją. To normalne.

Kluczowe pytanie: kiedy użytkownik dostaje prawdziwy rezultat? W którym momencie cyklu korzystania pojawia się moment „aha”, w którym myśli: kurczę, to jest naprawdę dobre, widzę siebie korzystającego z tego. Powiedzmy, że zajmuje to trzy do pięciu generacji — może to model obrazu i moment „aha” pojawia się dopiero przy piątej grafice. Wtedy chcecie, żeby wszystko aż do piątej generacji było darmowe, żeby użytkownik zdążył zobaczyć wartość, zanim zacznie płacić.

Pomyślcie też o tym, że subskrypcję sprzedaje się nieporównanie trudniej niż produkt jednorazowy. Jeśli sprzedajecie produkt za 50 dolarów albo dokładnie ten sam za 10 dolarów miesięcznie, to prawdopodobnie trudniej sprzedać tę drugą opcję — subskrypcja komuś, kto nigdy z wami nie robił interesów, jest bardzo trudna. Właśnie dlatego istnieją tak zwane trip wire’y i lejki, w których najpierw skłania się kogoś do jakiegokolwiek zakupu, choćby PDF-a za dwa dolary, a subskrypcję sprzedaje się później.

Może wasz produkt po prostu nie jest jeszcze gotowy. Czy naprawdę chcecie przepuścić przez niego mnóstwo płacących ludzi, żeby pomyśleli „to nie jest dobre, nie wracam, anuluję” i żeby marka na tym ucierpiała? Wtedy lepsza jest beta.

Jeśli wartość przychodzi w jednym posiedzeniu — w pięć minut — jak w ClientPacku, gdzie po jednej generacji użytkownik myśli „wrzuciłem transkrypty i w pięć minut mam talię gotową do prezentacji” — to dajecie jedną talię za darmo. Chce więcej albo chce zdjąć znak wodny: płaci. Nie twierdzę, że tak jest zawsze dobrze; znajdźcie, gdzie siedzi wartość. Jeśli trzeba używać czegoś przez wiele dni, dajcie okres próbny. Przy Glido: ktoś, kto nigdy nie dyktował, prawdopodobnie nie doznaje olśnienia przy pierwszej transkrypcji. Może przy pierwszym dniu używania? Przy pierwszych stu tysiącach słów? Trzeba znaleźć ten punkt i pozwolić używać za darmo aż do niego, żeby narzędzie zdążyło się przykleić.

Myślę o tym trochę tak, jak OpenAI i Anthropic wyceniają dziś subskrypcje Codeksa i Claude Code. Teraz jest bardzo tanio — na planie za 200 dolarów miesięcznie dostajecie inferencję wartą jakieś 8–14 tysięcy dolarów. Przyzwyczajają nas taniej, bo kiedy podniosą ceny, wielu z nas i tak zapłaci, bo już zobaczyliśmy i poczuliśmy wartość. Gdyby wyszli na start z ceną 2000 dolarów miesięcznie, mnóstwo osób nigdy by nawet nie spróbowało.

Pozwólcie zobaczyć rezultat, a płatność pobierzcie za następne zadanie. W moim przykładzie: prawdziwy transkrypt, kompletna talia ze znakiem wodnym, całkowicie za darmo — a chcesz więcej, wchodzisz na plan płatny.

Uczenie się od klientów i tempo skalowania

Decyzje poprawiają się, gdy uczycie się od klientów. Załóżmy, że macie pierwszych dziesięciu i myślicie tylko: skalować, więcej, więcej. Dorzucacie dziesięciu, potem pięćdziesięciu, potem kolejnych pięćdziesięciu — i wszyscy mają złe doświadczenie, odchodzą i nigdy nie wracają. Lepiej wziąć dziesięciu i się zatrzymać. Zobaczyć, co robią. Kiedy odchodzą, dlaczego. Odezwać się do nich. Mieć automatyczną ankietę. Czy odeszli do konkurenta? Przez cenę? Bo nie dostali tego, czego potrzebowali? Wszyscy anulowaliście kiedyś jakąś subskrypcję i wszyscy widzieliście to pytanie „dlaczego”. Te dane są bardzo ważne.

Bywa ciekawie, bo czasem ludzie odchodzą z powodu, który nie ma dla was sensu — i okazuje się, że po prostu nie byli właściwym awatarem. Przy ClientPacku: ktoś odchodzi, bo talia nie generuje takich wyników, jakich szukał, a po dopytaniu wychodzi, że nie prowadzi agencji AI, tylko agencję reklamową. Jasne, że to nie zadziała.

Zbierajcie dane, analizujcie je, ale traktujcie subiektywny feedback i ankiety z pewnym dystansem. Patrzcie na średnią i na to, jaką historię opowiadają dane, zamiast ufać im ślepo. Tu wchodzi różnica między danymi obiektywnymi a jakościowymi. Obiektywne to na przykład czas do aktywacji: kiedy po rejestracji użytkownik generuje pierwszą talię, czyli kiedy w ogóle podejmuje pierwsze działanie. Między rejestracją a aktywacją jest ogromny odpływ — kto nie aktywuje się od razu albo nigdy, ten odejdzie.

Obserwujcie, co robią, zbierajcie feedback i wkładajcie go z powrotem w produkt. Jeśli pięć z dziesięciu osób narzeka, że jest wolno, przyspieszcie. Potem otwierajcie się na kolejnych klientów — ale ostrożnie. Oczywiście nadmiar popytu, przy którym trzeba zamykać zapisy i prowadzić listę oczekujących, to świetny problem. Ale nie zaczynajcie od bombardowania dwunastu społeczności naraz.

Ludzie się rejestrują, dostają pierwszy rezultat, chcą użyć znowu i wtedy płacą — i muszą mieć powód, żeby używać dalej. Jeśli wartość kończy się po trzydziestu dniach, jaki to ma sens? Odejdą. Trzeba zwiększać wartość życiową klienta, czyli to, ile średnio zarabiacie na jednym kliencie przez cały okres współpracy. Gdy ktoś rezygnuje, pytajcie dlaczego, grupujcie powody i naprawiajcie po jednym problemie naraz.

Wracając do ceny: te 39 dolarów miesięcznie to było zgadywanie — tyle powiedział agent na podstawie danych. Ale gdybym naprawdę wychodził z tym na rynek, zrobiłbym inaczej. Dałbym każdemu pięć darmowych generacji, pozwolił z nich skorzystać, a potem porozmawiał: ile talii średnio potrzebujesz tygodniowo, ile zapłaciłbyś miesięcznie za coś takiego? Tak znajduje się realną wartość rezultatu.

Nierzadko spotyka się trzy plany: darmowy, startowy i wzrostowy. Patrzcie, które ludzie kupują, z jakich funkcji faktycznie korzystają i jak można pobawić się modelem freemium. Narzędzia rozkręcające się na rynku bardzo dużo eksperymentują z cenami; nawet te działające od dziesięciu lat wciąż je zmieniają — dostosowując się do inflacji, rynku, konkurencji i danych.

Ale ostatecznie musicie być rentowni. Jeśli ktoś płaci 39 dolarów za pierwszy miesiąc, to nie znaczy, że firma dostaje 39 dolarów. Są prowizje od płatności, koszty API, koszty hostingu, może pensje. Policzcie, ile kosztuje was zarówno dowiezienie wartości jednemu klientowi, jak i jego pozyskanie — bo jeśli wydajecie na reklamy albo płacicie twórcom za filmy o narzędziu, to wchodzi do budżetu.

Twórcy zamiast reklam

Dlatego nie polecam puszczania reklam na ofertę, o której nie wiecie jeszcze, czy działa. Żeby reklama miała sens, trzeba wydać przyzwoite pieniądze. Przy 500 czy 1000 dolarów miesięcznie Google ani Meta prawdopodobnie nie mają dość materiału, by dać wam wystarczająco szeroką grupę i pokazać, kto rezonuje oraz które copy i kreacje działają. To wyrzucanie 500–1000 dolarów miesięcznie w błoto.

Wolałbym wziąć te pieniądze i zapłacić mniejszym twórcom z naprawdę rozgrzaną społecznością, żeby pokazali narzędzie. 250 dolarów tu, 500 tam. To znacznie lepsze wykorzystanie inwestycji. Równolegle tworzycie własne treści organiczne — uważam, że przy narzędziu absolutnie powinniście to robić — patrzycie, które materiały (wasze i twórców) wystrzeliły ponadprzeciętnie, i dopiero za tymi stawiacie budżet reklamowy. To podwójne zanurzenie: budujecie własne koło zamachowe treści, płacicie twórcom, a to, co działa najlepiej, wzmacniacie pieniędzmi.

Zimny mailing i zimne reklamy są świetne do osiągnięcia prawdziwej skali, gdy oferta jest udowodniona i macie budżet. Wcześniej to marnowanie pieniędzy, gra na liczby — wolumen neguje szczęście, ale nie tam bym zaczynał. Zacząłbym od własnych treści organicznych i od rzeczy, które się nie skalują: postów w społecznościach na Reddicie, pisania blogów, bardziej bezpośredniej, „czarnej roboty” założyciela. Musicie tam być i zbierać jak najwięcej danych na starcie.

Potem można reużywać wyników wszędzie. Blogi, porównania z innymi narzędziami. Przy Glido mamy konkurencję w Super Whisper, Whisper Flow i Aqua Voice. Możemy pisać teksty w rodzaju „pięć najlepszych alternatyw dla Whisper Flow”, w których oczywiście umieszczamy Glido, albo porównania „Glido kontra Aqua Voice”. To będzie rankować w wyszukiwarce, a może pojawić się też w wynikach wyszukiwania AI. Im bardziej pokazujecie się tam, gdzie szuka wasza publiczność, i im bardziej istniejecie jako marka w sieci, tym lepiej. Do tego społeczności, studia przypadku, polecenia, ewentualnie program afiliacyjny z bonusami i zapraszaniem znajomych, no i osobiste wiadomości — do ludzi w społecznościach, do właścicieli firm, do własnej sieci.

Twórcy i społeczności to dziś prawdopodobnie jedna z największych dźwigni. Mali twórcy dostają współprace, duzi też — wszyscy, którzy budują publicznie i budują publiczność. Robiłem kiedyś film o aplikacji Cali: człowiek zwibekodował aplikację fitness do liczenia kalorii, zbudował ją z Claude’em, a jego strategią skalowania było płacenie twórcom. Znajdował twórców fitnessowych — nawet nie z niszy AI — bo wiedział, kto jest jego odbiorcą i którzy twórcy tę publiczność mają. Płacił im za pokazanie narzędzia i to zadziałało bardzo dobrze.

Schemat: znajdujecie twórców z właściwą społecznością, dajecie im darmowe konto, pokazujecie, co narzędzie robi, płacicie za treść, dorzucacie premię za wyniki oraz kod afiliacyjny, żeby zarabiali też z tyłu — a oni mają gwarancję, że za ten materiał dostaną swoje 500 dolarów niezależnie od wszystkiego. To zdecydowanie lepsze użycie środków niż wrzucenie 500 dolarów w reklamę na Mecie.

Co ciekawe, mniejsi twórcy miewają lepsze wskaźniki konwersji, a marki wolą z nimi pracować, bo publiczność odbiera takiego twórcę jako bardziej ludzkiego i bardziej dostępnego. Nie skreślajcie kogoś dlatego, że ma tylko pięć tysięcy obserwujących na Instagramie — te pięć tysięcy jest prawdopodobnie mocno zaangażowane i rozgrzane.

I mierzcie wszystko. Ile zapłaciliście danemu twórcy, jakie treści wypuścił, jaki był hook, jaki budżet. Do kogo pisaliście. Nawet jeśli to prowizoryczny arkusz Google — zaufajcie mi, zechcecie do tego wrócić i przeanalizować to przy kolejnym budżecie na twórców i treści.

Nie jesteście gotowi na reklamy, dopóki nie odpowiecie „tak” na wszystkie pytania: czy macie właściwą osobę, czy macie czytelną obietnicę, czy wiecie dokładnie, kiedy przychodzi pierwszy prawdziwy rezultat, kiedy użytkownik po nim wraca i czy potraficie śledzić, skąd przychodzą. Gdy macie te odpowiedzi i udowodnioną ofertę, można stawiać za tym budżet.

Dlaczego nie wolno skalować za szybko

Coś, co odczuliśmy konkretnie przy Glido. Jak często kupiliście narzędzie, zrezygnowaliście, a potem wróciliście? Raczej nigdy. Wyrabiacie sobie pierwsze wrażenie i nie myślicie o powrocie. A tymczasem to narzędzie cały czas iteruje — poprawia się na podstawie powodów rezygnacji i feedbacku, ma wielką mapę drogową.

Jeśli więc zaprosicie na początku zbyt wielu ludzi, dostaniecie górę feedbacku, mnóstwo osób powie „nie podoba mi się z tego powodu” i odejdzie. A gdyby ta funkcjonalność była na miejscu od razu, pewnie nigdy by nie odeszli. Straciliście właśnie grupę idealnych awatarów, którzy udowodnili, że są gotowi płacić — i teraz trudno ich odzyskać. Możecie próbować pisać „oto co przegapiłeś, poprawiliśmy to i to, chcesz spróbować ponownie?”, ale jest po prostu znacznie trudniej.

Prosty plan na trzydzieści dni

Tydzień pierwszy: rozmowy. Wypiszcie trzydziestu kupujących, rozmawiajcie, dołączajcie do społeczności, patrzcie, o czym ludzie mówią. Zbierajcie i pytajcie, ile się da.

Tydzień drugi: wybierzcie kilka osób, dajcie im plan darmowy, pokażcie, jak narzędzie działa, zrozumcie, co im się podoba w onboardingu i gdzie mieli moment „aha” — o ile w ogóle. Bądźcie bardzo blisko nich. Dajcie im maksimum wartości, a oni prawdopodobnie oddadzą wam złote dane i złoty feedback.

Potem: naprawiacie, uczycie się, powtarzacie. Ten bardzo ręczny proces ciągniecie aż do momentu, w którym poczujecie, że możecie uchylić drzwi szerzej. Wtedy uruchamiacie strategię twórców, zaczynacie pompować treści organiczne, pisać blogi i teksty pod wyszukiwarki, budować obecność. A gdy produkt jest coraz lepszy, a system już stoi, możecie odpuścić część rzeczy nieskalowalnych i skupić się na zbieraniu feedbacku i prowadzeniu wizji.

I jeszcze jedno, ważniejsze: zastanówcie się, dokąd nie chcecie iść. Z jaką kategorią narzędzi nie chcecie być kojarzeni, a z jaką chcecie? Jak stale obserwować konkurencję i analizować feedback o niej, żeby wasze narzędzie robiło jedną rzecz naprawdę dobrze?

To ważna lekcja: narzędzia bardziej obronne, czytelniejsze i z lepszą ofertą robią jedną rzecz lepiej niż wszyscy inni. Nie muszą robić pięciu. Wielu z nas myśli: mam hub, mam narzędzie AI, mogę dobudować, ile chcę, zrobię to maksymalnie użytecznym. Efektem jest tylko przytłoczenie. Zwłaszcza gdy dopiero odrywacie się od ziemi i próbujecie skalować, potrzebujecie jednego bardzo czytelnego bólu i jednej bardzo czytelnej obietnicy dla jednego bardzo konkretnego typu osoby.

Jeśli macie ochotę dodać: „ale są trzy bóle, mam dwie obietnice i wyobrażam sobie pięć typów użytkowników” — spoko, to w porządku. Może kiedyś, przy dziesięciu tysiącach płacących użytkowników, dojdziecie do planu zespołowego, planu skalującego i całej gamy upsellów. Ale na starcie zacznijcie od jednego z każdego i idźcie w maksymalną jasność. Róbcie jedną rzecz lepiej niż ktokolwiek inny, a odniesiecie duży sukces.

Mam nadzieję, że to było pomocne. Deck z tej części wrzucę do mojej darmowej społeczności na Skool, tak jak wszystko inne — link w opisie, zakładka „classroom”, sekcja z materiałami do filmów na YouTubie. Dziękuję i do zobaczenia w kolejnym materiale.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Pomysł wyprowadź z własnych danych pierwotnych, nie z promptu „daj mi pomysł na biznes”

Na czym polega: Autor uruchomił pięć równoległych agentów researchowych, które przeczesały ok. 16 tys. komentarzy z YouTube’a, 8 tys. wpisów z jego płatnej społeczności, 4 tys. tweetów i 20 tys. komentarzy z Reddita. Dopiero z tego wyszły trzy konkretne pomysły oraz przedział cenowy poparty 835 zdaniami o cenach.

Jak stosować: Zanim poprosicie model o pomysł, wskażcie mu źródło danych, które jest wasze i którego nie ma nikt inny: własna społeczność, skrzynka odbiorcza, historia zgłoszeń, transkrypty rozmów sprzedażowych. Jeśli takiego zbioru nie macie, podstawcie własną ekspertyzę dziedzinową i zawęźcie research do jednej niszy, którą rozumiecie.

Na co uważać: Generyczny prompt daje generyczne rekomendacje — te same, które dostanie każdy inny pytający. Uważajcie też, żeby ilość przetworzonych danych nie zastąpiła zrozumienia: to wy musicie przeczytać wnioski i zdecydować, nie model.

2.Rozdziel rolę menedżera od roli wykonawcy między modelami

Na czym polega: Fable 5 dostał wyraźne polecenie: „jesteś kierownikiem projektu, nie wykonujesz niczego, tylko delegujesz podagentom na Opusie i Sonnecie”. Efekt: po pełnym dniu budowy zużyto 7% tygodniowego limitu Fable’a, mimo ogromu wykonanej pracy.

Jak stosować: Najdroższy, najbardziej rozumujący model niech planuje, dekomponuje i weryfikuje; wykonanie oddajcie tańszym modelom w podagentach. W prompcie napiszcie to wprost, łącznie z uzasadnieniem („to spali limit”), oraz zażądajcie zapisywania postępów do wspólnego dokumentu planu lub osobnych plików per agent.

Na co uważać: Menedżer bez wymuszonego raportowania nie zauważy, że podagenty nadpisują sobie pracę. Wymagajcie osobnych work tree przy równoległej edycji plików i sami sprawdzajcie dokument planu, zamiast wierzyć raportowi końcowemu.

3.Wbuduj weryfikację w prompt, inaczej dostaniesz atrapę

Na czym polega: Do polecenia zbudowania strony z listą zapisów autor dopisał: nie kończ, dopóki nie zweryfikujesz — otwórz stronę, zrób zrzuty, sprawdź, że e-mail faktycznie gdzieś się zapisuje. Bez tego, jak sam mówi, dostałby plik HTML z przyciskiem, po którym nic się nie dzieje.

Jak stosować: Do każdego zadania budującego dopisujcie warunek zakończenia w formie obserwowalnego dowodu: zrzut ekranu, przejście ścieżki, log, uruchomiony test. Formuła „udowodnij mi, że jesteś pewien, i pokaż, co przetestowałeś” działa lepiej niż „sprawdź, czy działa”.

Na co uważać: Model potrafi zaraportować weryfikację, której nie zrobił. Wybierzcie jeden–dwa punkty z raportu i sprawdźcie je ręcznie — u autora wystarczyło kliknąć „wyloguj”, żeby znaleźć niedziałający przycisk w rzekomo skończonej wersji.

4.Do testowania użyj innego modelu niż do budowania

Na czym polega: Codex, sterując przeglądarką, przez ponad 20 minut klikał po aplikacji zbudowanej przez Claude’a i znalazł dwa blokery premiery: możliwość wygenerowania talii bez potwierdzonych ustaleń oraz slajd pokazujący klientowi zwrot „0x” przy nieznanym ROI. Osobny przebieg bezpieczeństwa pod OWASP dołożył cztery blokery wysokiej wagi.

Jak stosować: Trzymajcie oddzielną sesję, najlepiej na innym modelu, wyłącznie do łamania. Prompt: kliknij każdy przycisk, wgrywaj różne formaty, szukaj przypadków brzegowych, zgłoś, co blokuje premierę. Testowanie tylko do odczytu nie koliduje z równolegle trwającą budową.

Na co uważać: Poinformujcie testera, nad czym pracuje druga sesja, żeby nie zaczął naprawiać cudzych plików. I rozdzielcie priorytety — autor kazał naprawić tylko blokery i błędy wysokiej wagi, świadomie odkładając średnie.

5.Kod nie jest fosą — fosą jest prompt i dowód

Na czym polega: Autor otwarcie mówi, że jego aplikację każdy odtworzy w jeden dzień, więc jedynym prawdziwym IP jest prompt siedzący za przyciskiem analizy — nasycony jego doświadczeniem w rozmowach z klientami. Drugą niepodrabialną rzeczą są wyniki i opinie realnych klientów.

Jak stosować: Zaplanujcie osobną sesję na wydobycie własnej wiedzy — autor sugeruje skill typu „przemaglauj mnie” — a wynik wywiadu wpiszcie do promptu produkcyjnego. Zebrane studia przypadku wpuszczajcie z powrotem w copy, newsletter i stronę.

Na co uważać: Nie mylcie wypolerowanego interfejsu i działającej integracji płatności z wartością. Autor przyznaje, że jego własna fosa była słaba, i dlatego nie sprzedawałby tego produktu za 39 dolarów miesięcznie w obecnym stanie.

6.Sprzedawaj, zanim zbudujesz — landing page przed produktem

Na czym polega: Strona z listą zapisów, panel administracyjny do odczytu adresów i własna domena powstały, zanim produkt był gotowy. Cel: sprawdzić, czy czas włożony w budowę się zwróci.

Jak stosować: Zróbcie jednostronicową stronę z nagłówkiem, obietnicą i formularzem zapisu, wypchnijcie ją na GitHuba, wdróżcie na Vercelu i podepnijcie tanią domenę (tu: 11,25 dolara). Wyślijcie ją do konkretnej grupy i mierzcie odzew.

Na co uważać: Brak zapisów ma dwie różne diagnozy — zły awatar albo za słaba oferta — i mylenie ich prowadzi do naprawiania nie tego, co trzeba. Zadbajcie też, żeby adresy faktycznie gdzieś lądowały i żebyście mieli do nich dostęp; autor musiał osobno poprosić o panel administracyjny.

7.Klucze, piaskownica i zmienne środowiskowe to jedyna praca ręczna

Na czym polega: Cała hydraulika — Supabase jako uwierzytelnianie i baza klientów, Stripe wyłącznie jako płatności, osiem tabel utworzonych gotowym poleceniem SQL, webhooki, znak wodny na darmowej talii — powstała automatycznie. Człowiek dostarczył tylko klucze API i kliknął „uruchom” w edytorze SQL.

Jak stosować: Zapytajcie model wprost, jakiego stacku planuje użyć i jakich kluczy potrzebuje, zanim zaczniecie zakładać konta. Płatności testujcie w piaskownicy Stripe’a (klucze pk_test/sk_test), a na produkcję przechodzicie podmianą na pk_live/sk_live. Pliki .env nie trafiają na GitHuba, więc te same wartości trzeba wprowadzić jako zmienne środowiskowe w Vercelu — sekrety oznaczcie jako wrażliwe.

Na co uważać: Dwie wartości — publiczny adres strony i sekret webhooka Stripe’a — da się ustawić dopiero po pierwszym wdrożeniu, bo zależą od przydzielonego adresu. Klucze użyte w trakcie budowy zrotujcie przed produkcją. I pamiętajcie: przy podpięciu własnej domeny może się okazać, że logowanie przestaje działać, bo zmienna z adresem produkcyjnym wskazuje na stary host — to dokładnie ten błąd, który autor złapał na końcu.

8.Zarządzaj kontekstem: handoff zamiast jednej długiej sesji

Na czym polega: Dwukrotnie, gdy okno kontekstu zbliżało się do połowy albo dalej, autor wygenerował podsumowanie sesji (co zrobione, kluczowe pliki), wyczyścił czat i wkleił je z powrotem — świeża sesja podejmowała pracę bez utraty wątku. Tego samego podsumowania użył do zainicjowania sesji w drugim narzędziu.

Jak stosować: Przygotujcie sobie stały szablon handoffu i odpalajcie go proaktywnie, zanim jakość zacznie spadać. To samo podsumowanie jest najtańszym sposobem na zsynchronizowanie dwóch różnych harnessów pracujących na jednym projekcie.

Na co uważać: Handoff przenosi tylko to, co w nim zapiszecie — jeśli pominie kluczową decyzję, nowa sesja zacznie ją podważać. Przy wklejaniu do drugiego narzędzia dopiszcie wyraźnie „nic nie rób, dopóki nie powiem”, żeby nie ruszyło samo z siebie do pracy.

9.Cenę i moment płatności ustaw wokół momentu „aha”

Na czym polega: Model zaproponował 39 dolarów miesięcznie, ale autor mówi, że sam wyszedłby na rynek inaczej: pięć darmowych generacji, rozmowy z użytkownikami o tym, ile talii potrzebują tygodniowo i ile by zapłacili, i dopiero potem cennik. W produkcie wybrano jedną darmową talię ze znakiem wodnym, bo wartość przychodzi już po jednej generacji.

Jak stosować: Ustalcie, po ilu użyciach pojawia się olśnienie, i zrób darmowe wszystko aż do tego punktu. Pamiętajcie, że subskrypcję sprzedaje się nieporównanie trudniej niż produkt jednorazowy — zimnej publiczności najpierw sprzedaje się cokolwiek taniego, subskrypcję później.

Na co uważać: Cena musi zostawiać marżę po prowizjach, kosztach API i hostingu — tu koszt pełnej talii to 13–20 centów, a inferencja w najgorszym razie 3 dolary na użytkownika przy 39 dolarach przychodu. Rekomendacje cenowe od modelu traktujcie jako hipotezę do skalibrowania, nie jako wynik.

10.Skaluj partiami — zbyt szybki wzrost pali najlepszych klientów

Na czym polega: Autor argumentuje, że dziesięć tysięcy rejestracji nazajutrz po premierze zniszczyłoby produkt i reputację. Zaleca zapraszanie partiami, zatrzymanie się po pierwszych dziesięciu, obserwowanie ich, pytanie odchodzących o powód i naprawianie po jednym problemie naraz.

Jak stosować: Trzymajcie się listy oczekujących i wpuszczajcie ludzi falami. Co tydzień patrzcie na trzy liczby: rejestracje, wygenerowanie pierwszego rezultatu (aktywacja) i konwersja z pierwszego rezultatu na płatność. Miejcie automatyczną ankietę przy rezygnacji i grupujcie powody.

Na co uważać: Feedback jest subiektywny — część rezygnacji pochodzi od osób, które nigdy nie były waszym awatarem, i naprawianie ich problemów zniekształci produkt. I pamiętajcie o asymetrii: ktoś, kto raz zrezygnował, praktycznie nie wraca, więc utracony właściwy klient jest znacznie droższy niż wolniejszy wzrost.