InstaScaler zrodził się z bardzo konkretnej sytuacji, którą zna każdy twórca na Instagramie. Publikujesz coś wartościowego i piszesz pod spodem: „Napisz PLAN w komentarzu, a wyślę Ci materiał”. Komentarzy przychodzi kilkadziesiąt, a Ty przez godzinę kopiujesz ten sam link do kolejnych wiadomości, zamiast rozmawiać z ludźmi, którzy naprawdę potrzebują pomocy. Na rynku są narzędzia, które to robią, ale działają w modelu abonamentu, trzymają Twoje kontakty u siebie i zwykle oferują więcej, niż jest potrzebne. Zbudowałem więc własną konsolę: komentarz otwiera prywatną rozmowę, właściwa osoba dostaje właściwy link, a każda dostawa jest widoczna w logach. InstaScaler jest pierwszym narzędziem z serii GENIUS@WORK, ma stronę geniusat.work, a jego kod udostępniam na GitHubie na licencji MIT.
Problem: powtarzalna praca zabiera czas na rozmowę
Najważniejsza obserwacja była prosta: automatyzacja nie ma zastąpić człowieka, tylko oddać mu czas. Pierwszy etap kontaktu, czyli wysłanie materiału, odpowiedź na hasło i krótkie pytanie, jest powtarzalny. Prawdziwa wartość zaczyna się później, kiedy ktoś pisze o swoim problemie. Dlatego od początku założyłem, że InstaScaler prowadzi tylko ten pierwszy etap według scenariusza, który ustala właściciel konta, a w każdej chwili rozmowę może przejąć człowiek.
Drugą obserwacją było to, że twórca chce wiedzieć, co się wydarzyło. Narzędzie, które wysyła wiadomości w ciemno, budzi niepokój: czy dotarło, czy ktoś kliknął, czy nie wysłało się dwa razy? Stąd od pierwszej wersji logi dostaw, historia kontaktów i jasne statusy każdej wiadomości.
Od początku myślałem też o InstaScalerze jako o pierwszym elemencie większej serii. GENIUS@WORK to mój szyld dla narzędzi, które mają odciążyć twórców i małe firmy w powtarzalnej pracy, ale zostawić im kontrolę nad danymi i decyzjami. Każde narzędzie z tej serii ma być małe, zrozumiałe i możliwe do uruchomienia samodzielnie. InstaScaler był sprawdzianem, czy ten model ma sens: jeśli da się go wdrożyć i utrzymać bez mojej codziennej pomocy, kolejne narzędzia mogą iść tą samą drogą.
Decyzja: własne wdrożenie zamiast kolejnego abonamentu
Kluczowe było to, że InstaScaler nie jest usługą, do której się logujesz, tylko kodem, który uruchamiasz na własnym koncie Cloudflare i własnej bazie. Rozważałem model SaaS, bo łatwiej go sprzedać, ale odrzuciłem go z trzech powodów. Po pierwsze, kontakty i odpowiedzi ludzi należą do twórcy, a nie do mnie. Po drugie, przy niewielkiej skali nie ma sensu płacić miesięcznego abonamentu za coś, co mieści się w darmowych limitach infrastruktury. Po trzecie, otwarty kod buduje zaufanie, bo każdy może sprawdzić, co dzieje się z tokenami i danymi.
Ta decyzja wymusiła kolejną: projektowanie świadome limitów planu Free. InstaScaler nie ma stale działającego serwera, Redisa ani Hyperdrive. Działa na Cloudflare Workers, kolejce Queues, magazynie R2, Durable Objects i Workflows, a dane trzyma w serwerlessowej bazie Neon. Zakres jest celowo wąski: jeden administrator i do pięciu profesjonalnych kont Instagram. Wolałem zrobić jedną rzecz bardzo dobrze niż obiecać platformę dla agencji, której nie byłbym w stanie rzetelnie utrzymać.
Tylko oficjalne API i tylko to, na co pozwala Meta
Instagram nie lubi narzędzi, które udają człowieka. Dlatego InstaScaler korzysta wyłącznie z oficjalnego API Meta: nigdy nie pobiera danych ze stron, nigdy nie prosi o hasło do Instagrama i reaguje tylko na komentarze pod treściami połączonego konta. Tokeny są szyfrowane w spoczynku algorytmem AES-256-GCM. Do repozytorium dołączyłem też notatki do procesu App Review: jakie uprawnienia wnioskować, jak je uzasadnić i jak nagrać demonstrację, bo bez tego nikt poza testerami nie podłączy własnego konta.
Zasady Meta wpływają też na zachowanie produktu, i świadomie ich nie obchodzę. Sam komentarz nie otwiera standardowego okna wiadomości. Kolejne wiadomości wymagają interakcji z ostatnich 24 godzin, a czas pochodzi z Meta, a nie z ponowienia zadania. Brak wiarygodnej daty komentarza blokuje wiadomość otwierającą. Nie ma automatycznego DM po samym obserwowaniu konta. Te ograniczenia czasem utrudniają pracę, ale chronią konto twórcy i odbiorców przed spamem.
Ścieżki: quiz, który prowadzi do właściwego materiału
Po kampaniach komentarz → DM dodałem moduł Ścieżki. To prosty quiz w wiadomościach, maksymalnie dziesięć kroków: start, wiadomości z przyciskami, pytania z wyborem, tekstem albo adresem e-mail, warunki, akcje na tagach i zakończenie albo przekazanie rozmowy administratorowi. Odpowiedź prowadzi do właściwego materiału, kolejnego pytania albo do rozmowy z człowiekiem.
W tym module najważniejsze były zabezpieczenia przed pomyłką. Każda publikacja tworzy nową wersję ścieżki, a rozpoczęte rozmowy zostają przy swojej wersji, więc zmiana w edytorze nie psuje rozmowy, która właśnie trwa. Podgląd korzysta z tego samego silnika co prawdziwy quiz, ale nie wysyła wiadomości i nie zapisuje kontaktów. Publikację blokują pętle, brakujące połączenia i konflikty haseł z inną aktywną kampanią. Odbiorca zawsze może napisać STOP, a ręczna odpowiedź właściciela wstrzymuje automat.
Ostrożnie podchodzę też do tego, co oznaczają dane. Adres e-mail jest sprawdzany tylko składniowo, bez potwierdzenia własności i bez automatycznej zgody marketingowej. „Materiał wysłany” nie znaczy, że ktoś go kliknął, przeczytał albo coś kupił. Dane kontaktów nie trafiają do publicznych raportów. Wolę, żeby panel pokazywał mniej, ale prawdziwie. Fałszywie dobre liczby prowadzą do złych decyzji, a narzędzie ma pomagać decydować, nie poprawiać samopoczucie.
Niezawodność: lepiej nie wysłać niż wysłać dwa razy
Najwięcej pracy kosztowała mnie odporność na awarie. Webhook od Meta może przyjść dwa razy, sieć może się zerwać w połowie wysyłki, a zadanie może zostać przerwane. Przyjąłem prostą zasadę: lepiej oznaczyć wiadomość do sprawdzenia niż wysłać ją drugi raz. Każde zdarzenie najpierw trafia do R2 i do bazy, potem do kolejki. Atomowe przejęcie zdarzenia chroni przed podwójną wysyłką, a zadanie w toku jest ponawiane zamiast usuwane. Niepewna wysyłka nie jest powtarzana automatycznie, tylko trafia do przeglądu.
Druga zasada dotyczyła szybkości. Odpowiedź na webhook nie czeka na wysłanie wiadomości: zdarzenie jest zapisywane i przyjmowane od razu, a wysyłka dzieje się w tle przez prywatne powiązanie między usługami. Kolejne kroki quizu wykonują się po kolei w jednej transakcji z blokadą kontaktu. Usunięcie kontaktu usuwa jego profil i odpowiedzi, ale zostawia techniczny odcisk, który nie pozwala odtworzyć danych ze starego zdarzenia.
Pierwsza ścieżka w praktyce
Chciałem, żeby osoba bez doświadczenia technicznego mogła zbudować pierwszy quiz w kilka minut, więc przepływ w panelu ma pięć kroków. Najpierw wybierasz konto Instagram i sposób uruchomienia: komentarz pod postem albo słowo wysłane w wiadomości. Dostajesz gotowy, edytowalny przykład, a nie pustą planszę, bo pusta plansza paraliżuje. Potem dopasowujesz pytania, odpowiedzi i połączenia oraz ustalasz w zakładce Kwalifikacja, kiedy kontakt staje się wartościowym leadem. Trzecim krokiem jest przejście obu gałęzi w podglądzie. Dopiero potem zapisujesz szkic, poprawiasz wskazane błędy i publikujesz.
Kontakty, które przeszły przez ścieżkę, trafiają do bazy, gdzie można je filtrować po koncie, ścieżce, stanie rozmowy, tagu, adresie e-mail albo zainteresowaniu pomocą. Lista ścieżek pokazuje proste liczby: ile przebiegów się zaczęło, ile skończyło i ile spełniło warunki kwalifikacji. Nie dokładałem rozbudowanych wykresów konwersji, bo przy małej skali, dla której go projektuję (jeden administrator i najwyżej pięć kont), więcej mówi lektura samych odpowiedzi niż procenty.
Dokumentację traktuję jako część produktu, a nie dodatek. Obok README jest szczegółowa instrukcja po polsku, opis konfiguracji aplikacji Meta, polityka bezpieczeństwa i zasady współpracy przy kodzie. Przy narzędziu, które ktoś uruchamia samodzielnie na swoim koncie, dobra instrukcja jest odpowiednikiem działu obsługi klienta: jeśli jej zabraknie, otwarty kod staje się tylko teoretycznie dostępny.
Co było trudne i co wyszło
Najtrudniejsza była rozbieżność między tym, jak działa Instagram w dokumentacji, a tym, jak zachowuje się w praktyce: okna czasowe, opóźnione webhooki, różne typy kont. Każdy taki przypadek zamieniałem w test i opis w instrukcji, żeby następna osoba nie musiała odkrywać go od nowa. Repozytorium ma 81 commitów z okresu od 2 sierpnia do 9 września 2026 roku, testy jednostkowe i end-to-end oraz osobną politykę zgłaszania podatności.
Cały panel i strony publiczne są po polsku, z walidacją, szablonami kampanii, etykietami dostępności i polskim formatowaniem dat. Wygląd korzysta z marki delta240mvt, a fonty z polskimi znakami są serwowane lokalnie. Strona geniusat.work pokazuje nagranie prawdziwego panelu na danych demonstracyjnych, bez dźwięku i bez wysyłania wiadomości.
Rozważałem też, czy zrobić z InstaScalera płatną usługę z kontami użytkowników, rozliczeniami i obsługą wielu firm. Taki produkt miałby większy rynek, ale wymagałby zupełnie innej odpowiedzialności: przechowywania cudzych tokenów, obsługi wielu klientów i wsparcia technicznego dla każdego z nich. Wolałem dać ludziom narzędzie, które sami kontrolują, i opisać je tak dokładnie, żeby dało się je uruchomić bez mojej pomocy.
Dlaczego ten projekt ma dla mnie znaczenie
Do automatyzacji podchodzę zawsze tak samo: najpierw pytam, który kawałek pracy jest naprawdę powtarzalny, a który wymaga człowieka, i automatyzuję tylko ten pierwszy. Uczy też pokory wobec platform. Nie da się zbudować dobrego narzędzia wokół Instagrama, walcząc z jego zasadami, więc projektuję z nimi, a nie przeciwko nim. Dla mnie ważne jest również to, że ten kod jest otwarty. Każdy twórca może go uruchomić u siebie, sprawdzić i zmienić, bez uzależniania się ode mnie ani od kolejnego abonamentu. To jest taki rodzaj wolności, o który chodzi mi w całym delta240mvt.