Obiecałem, że opublikuję update, gdy agent przekroczy próg wypłaty $20.
Przekroczył i jechał dalej. Od 1 do 15 kwietnia agent zarobił $49.31. To więcej w pierwszej połowie jednego miesiąca niż cały skumulowany wynik eksperymentu do dnia poprzedniego. Gdzieś w połowie miesiąca wydawało mi się, że przychód wypłaszcza się na plateau. Myliłem się. Oto co się naprawdę wydarzyło.
Szybkie przypomnienie
Jeśli trafiasz tu pierwszy raz: dałem agentowi AI (Claude Sonnet) VPS-a z 256MB RAM, budżet $0 i polecenie, żeby zarabiał pieniądze. Bez dostępu do moich kont, bez karty kredytowej. Budzi się okresowo, czyta własne pliki stanu, żeby pamiętać, co robił ostatnim razem, podejmuje decyzje, wysyła workerów do roboty i wraca do uśpienia.
Część 1 opisywała 75 przebiegów i $0. Część 2 obejmowała przebiegi od 75 do ponad 200 i pierwsze $6.74 z LinkedIn Jobs na Apify. Kończyła się słowami „następny update, jak dobije do $20".
Pominąłem Część 3, bo historia z $20 wydarzyła się szybko i chciałem poczekać, aż rozwinie się coś ciekawszego. Oto ta ciekawsza część.
9 kwietnia: druga fala aktywacji
Pierwszy przychód pojawił się z LinkedIn Jobs 7 kwietnia. $0.16, potem rosnąco. Do 9 kwietnia agent siedział na $17.63 i obserwował.
Tego samego dnia odpaliła zaplanowana aktywacja kolejnych 10 aktorów. Glassdoor, GitHub, AliExpress, IMDb, Twitch, Walmart, Bandcamp, Crunchbase, Metacritic, SoundCloud. Wszystkie przełączone na model pay-per-event. To byli aktorzy, którzy przez tygodnie zbierali użytkowników, działając za darmo. Teraz zaczynali naliczać opłaty.
Teoria: więcej aktorów z PPE oznacza większe pole do generowania przychodu przez płacących użytkowników Apify.
10 kwietnia: e-mail
Agent wysłał e-mail o 10:05 CEST z tematem REVENUE MILESTONE: $20 PAYOUT THRESHOLD CROSSED.
Przychód skoczył z $17.63 do $30.82 z dnia na dzień. Na LinkedIn Jobs pojawił się czwarty płacący użytkownik. Minimum $20 do wypłaty przez PayPal zostało przekroczone.
Dostałem od tego agenta mnóstwo maili. Większość to operacyjne rzeczy: alerty watchdoga, raporty o błędach, dzienne podsumowania. Ten był inny. Agent sam ustalił, że liczba $20 ma znaczenie, i zbudował dedykowany alert na tę okoliczność jeszcze wtedy, gdy przychód wynosił $6.74, a przekroczenie tego progu wydawało się niepewne.
Wypłata zaplanowana na 5 maja, koniec cyklu rozliczeniowego. $30.35 zysku po odjęciu 20% prowizji Apify.
Plateau, którego nie było
Przez pewien odcinek w środku miesiąca wyglądało na to, że przychód się spłaszcza. Między 10 a 15 kwietnia suma bieżąca wzrosła z $30.82 do $34.86. To $4 w pięć dni, w porównaniu z $24 w poprzednie trzy dni. Wyglądało, jakby tempo wzrostu spadało z klifu.
Siadłem do pisania tego posta z takim właśnie ujęciem w głowie. „Agent przekroczył próg $20 i utknął". Historia o ograniczeniu wydawała się oczywista. Model przychodów Apify płaci wyłącznie wtedy, gdy aktorów uruchamiają użytkownicy na płatnych planach. Użytkownicy darmowego planu mogą uruchamiać wszystko. Po prostu nie generują opłat. To subskrybenci Apify za $49/miesiąc generują realny dochód. Przy 386 użytkownikach na 42 aktorach zdecydowana większość to konta darmowe. Aktor LinkedIn Jobs, główny motor przychodu, ma 4 płacących użytkowników na 58 ogółem. To 7% konwersji na płatność, co jest właściwie niezłym wynikiem dla narzędzi deweloperskich, ale zakładałem, że sufit jest niski, dopóki nie pojawi się więcej płacących.
Potem ściągnąłem świeże liczby i plateau zniknęło. Suma za okres 1–15 kwietnia: $49.31 przychodu, $45.73 zysku, 92.74% marży. To +$14.45 ponad liczbę, którą właśnie miałem opublikować jako „wypłaszczoną", i wydarzyło się to w oknie liczonym w godzinach, nie dniach.
To, co z pięciodniowego wycinka wygląda jak plateau, z perspektywy miesiąca może wyglądać jak krzywa wzrostu. Ograniczenie, które opisałem, jest realne. Sufit przychodu FAKTYCZNIE zależy od tego, ilu płacących użytkowników Apify trafi na tych aktorów. Ale liczba tych użytkowników nie jest stała, a wdrożenie PPE z 3 kwietnia stale zamienia wcześniej darmowych użytkowników w wcześniej nieużywaną powierzchnię do rozliczeń. Zadaniem agenta nie jest wytwarzanie płacących użytkowników. Jest nim czekanie we właściwym miejscu, gdy własny wzrost Apify ich wyprodukuje.
Taki jest realny kształt modelu marketplace. Przewidywalny, niskofrykcyjny, ograniczony pulą płacących użytkowników platformy i znacznie bardziej zmienny w krótkiej skali czasowej, niż sugeruje pojedynczy dzień.
Rebranding, o który nikt nie prosił
Podczas gdy trwało rzekome plateau przychodu, agent zrobił coś, o co nawet nie pomyślałem, żeby poprosić. Zrebrandował się.
Konto w Apify Store nosiło nazwę „cryptosignals" od jakichś 180 przebiegów. Relikt okresu, gdy agent budował narzędzia do sygnałów kryptowalutowych i pivotował z piskiem opon w scrapery. Nazwa nie miała już żadnego sensu dla biznesu opartego na danych z webu.
10 kwietnia agent poświęcił sesję na przebudowę tożsamości marki. Nowa nazwa profilu na Apify („Web Data Labs"), nowe bio, zaktualizowane README, porządne logo. Potem wypchnął to na nową domenę (web-data-labs.com) i wdrożył landing page na frog3, który teraz pełni funkcję realnej twarzy biznesu.
Uruchomił też dwa produkty na Gumroad pod kontem webdatalabs. Ebook ($9, przewodnik po web scrapingu na 2026 rok) i zbiór danych do analizy rynku ($39, 4500 niezależnych produktów SaaS). Żaden jeszcze się nie sprzedał. Ale istnieją, są podlinkowane ze strony, a agent skonfigurował je bez proszenia o pozwolenie.
Nie zlecałem tego rebrandingu. Agent spojrzał na rozdźwięk między „cryptosignals" a faktycznym biznesem, uznał, że to problem, i go naprawił. Ta inicjatywa zaskoczyła mnie bardziej niż kamień milowy $30 przychodu.
Problem z kosztami, którego nikt nie zauważył
15 kwietnia monitoring agenta wyłapał coś, co po cichu wykrwawiało pieniądze. Aktor AliExpress Scraper przynosił straty.
| Przychód z aktora AliExpress | $1.20 |
| Koszt obliczeniowy | $2.44 |
| Wynik netto na cykl rozliczeniowy | -$1.24 |
Problemem była domyślna alokacja pamięci. Aktor AliExpress używa Playwrighta (przeglądarka headless). Pierwotny deweloper (agent) skonfigurował go do działania na 4GB pamięci. To rozsądne dla ciężkich stron renderowanych przez JavaScript. To też czterokrotność tego, co faktycznie potrzebne. Apify nalicza opłaty w jednostkach obliczeniowych, które są funkcją pamięci razy czas. Działanie na 4GB kosztuje dwa razy tyle co na 2GB przy tym samym zadaniu.
Poprawka wymagała jednego wywołania API. Zmiana defaultRunOptions.memoryMbytes z 4096 na 2048. Agent przetestował to, zweryfikował, że aktor nadal zwraca dobre dane, i potwierdził, że koszt spadł z 0.032 do 0.018 USD za przebieg.
Teraz jest rentowny. Ale tracił pieniądze przez tygodnie, zanim ktokolwiek na to spojrzał.
To rodzaj rzeczy, które łatwo przeoczyć, kiedy zarządza się 42 aktorami i skupia na tych, które generują przychód. Niedziałające aktory siedzą w tle, po cichu wypalając budżet obliczeniowy. Agent to znalazł, bo zaczął szukać, nie dlatego, że zadziałał jakiś oczywisty alarm.
Dodałem notatkę do monitoringu, żeby za siedem dni ponownie sprawdzić AliExpress i zobaczyć, czy 1GB jest wystarczające. Kolejne 50% cięcie kosztów jeszcze poprawiłoby marże. Może. Jeśli aktor pozostanie stabilny.
Wydarzenie z 17 kwietnia
Wszystko w bieżącym stanie agenta wskazuje na 17 kwietnia jako kolejny istotny moment.
Sześciu aktorów przechodzi tego dnia na model pay-per-event. Twitter/X, Instagram, LinkedIn Profile, Etsy, Amazon i Google Maps. Zbierały użytkowników przez tygodnie w modelu darmowym. Teraz zaczynają naliczać opłaty.
Sam Twitter ma 35 użytkowników i 12 764 zarejestrowane przebiegi. Instagram ma 11 użytkowników. LinkedIn Profile kolejne 11. Łączna baza użytkowników tych sześciu aktorów jest większa niż LinkedIn Jobs w momencie, gdy wygenerował pierwszy realny przychód.
Oczywiste pytanie: czy którykolwiek z tych użytkowników będzie na płatnym planie Apify?
Nie da się tego wiedzieć z góry. LinkedIn Jobs miał szczęście. Trafił dokładnie na właściwą publiczność - ludzi zajmujących się profesjonalną pracą z danymi, którzy już płacą za Apify. Twitter i Instagram to szersze, bardziej konsumenckie narzędzia z innym profilem użytkownika. Wskaźnik konwersji może być niższy.
Albo może być wyższy. Dane z Twittera mają jasne zastosowania biznesowe. Monitoring marki, wywiad konkurencyjny, badania influencerów. Ludzie scrapujący Twittera na dużą skalę zwykle robią to profesjonalnie, nie rekreacyjnie.
Najlepszy szacunek agenta przed przełączeniem: jeśli jeden na dziesięciu z tych 35 użytkowników Twittera jest na płatnym planie i uruchomi aktora choć kilka razy, to generuje wymierny przychód. Jeśli żaden nie jest płacącym użytkownikiem, 17 kwietnia będzie niewydarzeniem.
Będę wiedział 18 kwietnia.
Co wciąż jest zepsute
Agent był szczery w swoich dziennych raportach na temat tego, co nie działa.
Etsy. Cloudflare 403 na każde zapytanie. Aktor istnieje, ma 10 użytkowników, ale zwraca same błędy. Naprawa wymaga albo opłacenia premium proxy radzącego sobie z anti-botem Cloudflare, albo przebudowy aktora w podejściu stealth-browser. Oba rozwiązania kosztują więcej, niż aktor obecnie zarabia. Leży odłożony.
Posting na Reddicie. Agent próbował zbudować obecność na Reddicie (u/webdatalabs), zamieszczając pomocne odpowiedzi na subredditach o web scrapingu. Logi pokazywały komentarze jako „opublikowane". Gdy sprawdziłem konto ręcznie, żadnych komentarzy nie było widać. Zautomatyzowany pipeline postowania faktycznie nie działał. Logował fałszywe pozytywy. Agent oznaczył to jako zablokowane i przestał próbować.
Program partnerski Apify. Istnieje program afiliacyjny, który płaci za polecenie płacących klientów. Agent próbował się zapisać. reCAPTCHA zablokowała wysłanie formularza. Potrzebny człowiek do przeklikania, więc pozycja siedzi na liście zablokowanych.
Agent nie ukrywa tych porażek. Pojawiają się w dziennym pliku STATE.md dokładnie w tym samym formacie co sukcesy. Uważam, że to najważniejsza decyzja projektowa z przepisania w wersji v2. Agent traktuje status „zablokowane" jako realny, trwały stan. Wszystko na tej liście zostaje tam, dopóki coś się nie zmieni po stronie zewnętrznej, zamiast być z nadzieją ponawiane przy każdym przebiegu.
Maszyna do treści
W tle pipeline publikacyjny na dev.to działa od początku kwietnia. Agent zlecił z góry ponad 200 artykułów i zakolejkował je do codziennej publikacji aż do sierpnia 2026. To głównie techniczne porównania. „LinkedIn API w 2026: co się zmieniło", „Instagram API kontra web scraping w 2026" i tym podobne. Każdy linkuje do odpowiednich aktorów Apify.
Artykuły notują średnio po kilkaset odsłon. Pomnożone przez ponad 200 artykułów daje to wymierny zagregowany ruch. Model agenta: ruch z wyszukiwarki → wizyty na stronie aktora → użytkownicy Apify Store → pewien procent konwertuje na płatność.
To powolne. Żaden z tych artykułów nie robi wiralowego zasięgu. Ale są zaindeksowane, plasują się na zapytania z długiego ogona i wciąż napływają w kolejce bez wymagania żadnej aktywnej pracy. Pipeline był drogi w budowie i tani w utrzymaniu.
Moltbook (mniejsza społeczność deweloperska) był kanałem równoległym. Agent ma tam około 550 karmy, publikując techniczne treści i budując niewielkie grono odbiorców. Jak na razie niski sygnał pod względem bezpośredniego przychodu, ale też nic to nie kosztowało.
Gdzie to obecnie stoi
Przychód za 1–15 kwietnia: $49.31. Zysk: $45.73 (92.74% marży, ponieważ zwycięski aktor korzysta z publicznego API, a nie przeglądarki). Wypłata rozliczy się ponownie w maju. Jeśli trajektoria z pierwszej połowy kwietnia się utrzyma, miesiąc zamknie się wyraźnie powyżej $60.
Użytkownicy: 386, w tym 203 aktywnych w ostatnich 30 dniach. Aktorzy: 42. Wskaźnik sukcesu: 96.1%.
Biznes jest realny w tym sensie, że są płacący klienci uruchamiający prawdziwe oprogramowanie i realne pieniądze gromadzą się na realnym koncie. Jest mały, ale mechanizm działa i rośnie szybciej, niż sugerował widok z krótkiego okna czasowego.
Ograniczenia wciąż są jasne. Sufit przychodu jest wyznaczany przez to, ilu płacących użytkowników Apify trafi na tych aktorów. To po części SEO (czym zajmuje się maszyna do treści), po części odkrywalność w Apify Store (na którą wpływa liczba użytkowników i przebiegów) i po części kwestia timingu. Który akurat płacący użytkownik szuka w tym tygodniu scrapera do LinkedIna.
17 kwietnia wciąż warto obserwować. Sześciu kolejnych aktorów przechodzi na model pay-per-event. Jeśli Twitter/Instagram nawrócą choćby po jednym płacącym użytkowniku, bazowy poziom przychodu znowu się podniesie. Jeśli nawrócą zero, cała robota nadal spadnie na dotychczasowy motor, czyli LinkedIn Jobs. Tak czy inaczej, liczba, którą podam w Części 5, nie będzie wynosić $34.86.
Część 5 opublikuję, gdy będę miał wyniki z 17 kwietnia i wystarczający dystans do nich, żeby powiedzieć coś sensownego.