AdRiser: SaaS bez backendu. 61 workflowów n8n robi robotę.
AdRiser monitoruje kampanie Allegro Ads: ROAS, wydatki, konwersje, alerty i P&L w jednym panelu PWA. Działa pod adresem adriser.pl. Nie ma pod nim ani jednej linijki backendu w Go czy Node. Backend to 61 workflowów n8n, baza Postgres i rozszerzenie Chrome jako fetch-proxy. Opisuję, jak to spięte i gdzie takie podejście się kończy.
Co AdRiser faktycznie robi
Sprzedawca na Allegro odpala kampanie Ads i po tygodniu nie wie, które zarabiają, a które przepalają budżet. Panel Allegro pokazuje surowe liczby, bez ROAS-u liczonego pod jego marżę i bez alertów. AdRiser zaciąga dane kampanii co 15 minut, liczy ROAS i P&L, pilnuje progów (spadek ROAS, przepalony budżet) i raz na 6 godzin generuje rekomendacje optymalizacji modelem Gemini na Vertex AI. Trzy plany: Manual 49 PLN miesięcznie (monitoring plus alerty), Automat 99 PLN miesięcznie (rekomendacje AI plus akcje automatyczne) i Agencja w wycenie indywidualnej.
Backend, którego nie ma
Klasycznie pod taki produkt napisałbym serwis: REST API, warstwa domeny, scheduler, integracje. W AdRiserze tej warstwy nie ma. Zamiast niej stoi 61 workflowów n8n, które wystawiają 43 endpointy webhookowe na 32 workflowach, plus baza adriser-db w Postgresie (około 40 tabel i 10 widoków). Front (Vite plus React, PWA) nie rozmawia z żadnym własnym API. Rozmawia z webhookami n8n.
Dlaczego tak, skoro to nietypowe. Trzy powody, wszystkie wynikają z tego, że robię to sam:
- Jeden język orkiestracji. CRUD, cron, integracja z Allegro, wywołanie Vertex AI i zapis do Postgresa to ten sam typ roboty: przesuń dane z A do B, policz coś po drodze. n8n robi dokładnie to, a ja widzę cały przepływ na jednym płótnie zamiast skakać po plikach serwisu.
- Zero boilerplate'u. Nie stawiam frameworka, routingu, migratora i deploya osobnego serwisu. Webhook to gotowy endpoint. Node Postgres to gotowa warstwa danych.
- Zmiana logiki bez deploya. Poprawka reguły alertu to edycja węzła w UI n8n, nie commit i redeploy. Dla solo-buildera to różnica między poprawką w 5 minut a w pół godziny.
To nie jest darmowe (o koszcie niżej), ale dla produktu, którego logika to w 90 procentach operacje na danych, opłaca się.
Rozszerzenie Chrome jako fetch-proxy na CORS
Najciekawszy kawałek to nie n8n, tylko obejście CORS-a. Część danych Allegro pociągam serwerowo, oficjalnym API przez OAuth (cron co 15 minut, token trzymany zaszyfrowany AES-256-GCM). Ale są wywołania, które mają sens dopiero z poziomu przeglądarki zalogowanego użytkownika, i te blokuje CORS: Allegro nie pozwala wołać swoich endpointów z obcego origina.
Można było postawić własny serwer-proxy. Zamiast tego napisałem rozszerzenie Chrome w manifeście MV3, które robi fetch w kontekście MAIN world strony. Z tego kontekstu żądanie nie jest cross-origin w sensie, który blokuje przeglądarka, więc CORS odpada, a ja nie utrzymuję dodatkowej infrastruktury proxy. Rozszerzenie jest cienkie: autoryzuje, przekazuje, nic nie cache'uje.
Backend nie musi być serwisem. Czasem to 61 workflowów i jedno cienkie rozszerzenie. Liczy się, czy przepływ danych jest czytelny i czy umiesz go utrzymać w pojedynkę.
Reszta stacku, krótko
- PWA offline-first. Service worker na Workboxie, cache w IndexedDB. Panel otwiera się i pokazuje ostatnie dane nawet bez sieci.
- Auth na Argon2id. Hasła hashowane Argon2id, sesja po stronie serwera.
- AI co 6 godzin. Cron odpala workflow, który zbiera dane kampanii i prosi Gemini o rekomendacje (co podbić, co wyłączyć). To sugestie, nie autopilot. W planie Automat część można wykonać jednym kliknięciem.
Gdzie to podejście się kończy (uczciwie)
Anti-hype, bo n8n jako backend ma realne granice i nie chcę sprzedawać tego jako srebrnej kuli:
- Latencja. Webhook n8n to nie jest najszybsza ścieżka na świecie. Do panelu, który odświeża się co kilkanaście minut, to bez znaczenia. Do czegoś, co musi odpowiadać w 50 ms pod obciążeniem, napisałbym zwykły serwis.
- Skala równoległa. Przy wielu kontach trzeba n8n w queue mode z workerami i PgBouncerem przed bazą. To działa, ale to już operacyjny narzut, nie magia.
- Logika w gorącej ścieżce. Ciężkie obliczenia per request lepiej trzymać w kodzie. n8n jest świetne do orkiestracji, słabsze do CPU-heavy logiki w pętli.
- Rozszerzenie to zależność od Chrome. Trik z MAIN world jest elegancki, ale wiąże mnie z modelem rozszerzeń przeglądarki. Gdyby to się zmieniło, wracam do proxy serwerowego.
AdRiser nie jest dowodem, że „nie potrzebujesz backendu". Jest dowodem, że dla konkretnego produktu, robionego przez jedną osobę, n8n plus Postgres plus cienkie rozszerzenie wystarczą, żeby ruszyć i utrzymać. Gdyby AdRiser urósł do skali, gdzie latencja albo ruch zaczynają boleć, część przepływów przepisałbym na serwis. Architektura ma być pod etap, nie pod ego.
AdRiser działa pod adriser.pl. Jeśli sprzedajesz na Allegro i chcesz widzieć ROAS pod swoją marżę, a nie surowe liczby z panelu Ads, to jest dla Ciebie.
Najczęstsze pytania
Czy n8n nadaje się na backend produkcyjnego SaaS?
Dla AdRisera tak, bo logika to w większości operacje na danych: pobierz z Allegro, policz ROAS, zapisz do Postgresa, oddaj do PWA. n8n w queue mode z workerami i PgBouncerem to obsługuje. Granica jest tam, gdzie potrzebujesz niskiej latencji per request albo ciężkiej logiki w gorącej ścieżce.
Po co rozszerzenie Chrome, skoro jest API Allegro?
Część danych pociągam serwerowo przez oficjalne API (OAuth, cron co 15 minut). Rozszerzenie rozwiązuje osobny problem: niektóre wywołania z poziomu przeglądarki użytkownika blokuje CORS. Extension MV3 robi fetch w kontekście MAIN world, więc omija CORS bez stawiania własnego proxy serwerowego.
Ile kosztuje AdRiser?
Trzy plany: Manual 49 PLN miesięcznie, Automat 99 PLN miesięcznie i Agencja w wycenie indywidualnej. Pierwsze 100 kont ma 50 procent zniżki na rozliczenie roczne.
Chcesz backend, który utrzymasz sam?
U Ciebie zaczynam od warsztatu procesu (90 minut, bezpłatny). Rozrysujemy przepływ i powiem wprost, czy w Twoim przypadku wystarczy n8n, czy lepiej zwykły serwis. Bez wciskania jednego słusznego stacku.
Zamów warsztat → Albo zobacz AdRiser live.