Zbudowałem SaaS dla local SEO w pair codingu z agentem. Oto wszystko od kuchni — i dlaczego go zapauzowałem

Przez 10 dni intensywnych sesji zbudowałem SaaS dla małych polskich firm. Nazywa się seohelper. Monitoruje wizytówkę Google, Search Console, Analytics, robi audyt strony, sprawdza co o tobie mówią ChatGPT z Perplexity, podpowiada co zrobić każdego ranka.

Skończyłem go w 90%. I zapauzowałem.

Nie dlatego, że nie działa. Działa. Łapie błędy, generuje raporty, gada z klientem przez chat z AI Asystentem. Przeszedł 34 iteracje schemy bazy, 23 crony chodzą codziennie, 14 dni trial bez karty stoi gotowy. Dwie rzeczy mnie zatrzymały — opowiem o nich na końcu.

Ten artykuł jest po to, żeby ten projekt nie zniknął razem z domyślnym vercel.app URL-em. To case study od kuchni — co konkretnie zbudowałem, jakim stackiem, ile to zajęło, ile by kosztowało utrzymanie i czego się nauczyłem przy budowaniu większego produktu w pair codingu z agentem.

Jeśli zastanawiasz się czy weekendowy projekt może wyrosnąć w realny SaaS, jeśli rozważasz pair coding z Claude Code do produktu a nie do skryptu, jeśli chcesz wiedzieć co konkretnie się buduje przy local SEO software — to jest dla ciebie.

01. Co to jest seohelper

Jedno zdanie: widzisz całą obecność swojej firmy w Google w jednym miejscu, bez potrzeby rozumienia SEO.

Wpisujesz adres swojej strony albo nazwę firmy. Aplikacja w 10 minut łączy się z twoim Google Business Profile, Search Console, Analytics, robi audyt techniczny strony, sprawdza co AI w ChatGPT i Perplexity mówi o tobie, sprawdza pozycję w mapach na 10-25 lokalnych fraz. Codziennie generuje Daily Insight — krótką narrację po polsku w stylu "co się dzieje z twoją wizytówką, co warto zrobić dziś". Trzy konkretne akcje, każda z przyciskiem.

Dla 80% małych firm które nie mają agencji i nie chcą jej mieć, to wszystko czego potrzebują. Zamiast logować się do 4 różnych panelów Google i nic z nich nie rozumieć, dostają jedną stronę z polskim tłumaczeniem.

Dla 20% które chcą więcej — jest ścieżka B: konto Pro albo Agency, gdzie ja osobiście wchodzę w ich konto, robię konsultacje raz na kwartał, zaczepiam z planem gdy coś spada. Personal layer, nie scale.

02. Dla kogo to było

ICP było ścisłe: mała polska firma usługowa, lokalna. Dentyści, fryzjerzy, mechanicy, restauracje, kancelarie, księgowi, agencje, IT support, architekci, instalatorzy. Kryterium: lokalność, nie B2B/B2C. Nie e-commerce, nie firmy ogólnopolskie.

Konkurencja na rynku globalnym: BrightLocal (citations), Localo ($39/mies, sam GBP), Senuto (general SEO, nie local), Snezzi ($999/mies enterprise). Każdy z nich pokrywa fragment problemu, żaden nie spina całości.

Mój kąt był prosty: Polski język + GBP + GSC + GA4 + audyt + AI Asystent + AI Search Coach w jednym dashboardzie za 129/279/899 zł. Plus personal layer (Pro/Agency) — bo przy 200 klientach realnie obsłużysz każdego osobiście. Nie skaluje się do 1000+, ale 200 klientów × średnio 300 zł = 60 tys. zł miesięcznie. To wystarczy.

03. Co dokładnie zbudowałem

Osiem głównych modułów, każdy z konkretną robotą do wykonania codziennie. Frontend jest cienki — większość kodu to background workers które robią cron-driven robotę w nocy. Klient otwiera dashboard rano i widzi gotowe dane.

Kilka modułów które warto rozwinąć — bo to nie są placeholder cards, to rzeczy które mają realny mięso pod spodem.

PM Radar — wynik 0–100 widoczności

Codzienna ocena 8 składników obecności firmy w Google: kompletność wizytówki, zdrowie strony (SSL/meta/szybkość/mobile), widoczność w wyszukiwarce (kliknięcia/frazy/pozycje/indeksacja), aktywność profilu (posty/Q&A/Ask Maps), konwersje (telefony/formularze/rezerwacje).

Każdy składnik osobno punktowany. Wykres trendu na 90 dni. Lista "co obniża twój wynik" z konkretnymi naprawami (np. "Dodaj frazy w Local Pack Monitor — to 25% PM Radar, +do 25 pkt"). To jest pierwszy ekran który klient widzi po zalogowaniu — wie czy jest źle, średnio czy dobrze, w 10 sekund.

Local Pack Monitor — pozycje w mapach

Codzienne sprawdzanie pozycji firmy w Google Maps dla 10–25 fraz lokalnych. Plan Agency: 50 fraz × 5 lokalizacji codziennie. Alert email gdy wypadasz z TOP3. Integracja z DataForSEO (płatne API, ~0.05 zł za zapytanie, ale wiarygodne dane od profesjonalnego dostawcy).

Dwie zakładki: Konkurencja (kogo Google pokazuje obok ciebie w mapach na te same frazy) i Pozycje + Grid (mapa miasta z heatmapą gdzie jesteś TOP3, gdzie spadasz). Przy 50 frazach × 5 lokalizacji × 365 dni = 91 tys. zapytań rocznie. Dlatego limit per plan jest restrykcyjny.

AI Search Coach — 4 platformy AI

To była moja najfajniejsza część do zbudowania. Sprawdzamy czy ChatGPT, Perplexity, Claude i Gemini polecają twoją firmę gdy klient pyta o "dentystę w Krakowie". Mention rate %, brand attributes, trend.

Plus — Twoja deklaracja vs jak AI Cię widzi. Klient zaznacza jak chce być postrzegany ("profesjonalny", "przyjazny", "nowoczesny"). Co tydzień system odpala 10 promptów na 4 platformach, sprawdza jakimi słowami AI faktycznie opisuje firmę, porównuje z deklaracją. Match: 0/3, 1/3, 2/3, 3/3.

Robi cron /api/cron/ai-search-coach co środę o 10:00. Adaptive sampling — nie pyta wszystkich 10 promptów dla wszystkich planów, dynamicznie dobiera próbkę. Na produkcji przy 200 klientach to byłoby ~$50–80 miesięcznie API calls (Anthropic + OpenAI + Perplexity).

AI Asystent z 7 narzędziami (tool use)

To jest miejsce gdzie projekt przestał być CRUDem i stał się czymś co naprawdę pomaga. Klient w czacie pisze: "co dziś zrobić?". Asystent (Claude Haiku) ma dostęp do 7 narzędzi:

Multi-turn loop (max 4 rundy tool_use ↔ tool_result). Confirmation pattern: destrukcyjne akcje tworzą wpis w assistant_pending_actions, klient akceptuje w UI. Scope detection: 25+ regex patterns dla pytań prawnych/finansowych — wymusza eskalację do mnie zamiast halucynacji porady prawnej.

To było najtrudniejsze do zaprojektowania. Ale po zrobieniu tego — chat naprawdę zaczyna pomagać. Przestaje być "co lubię w wizytówce" tylko zaczyna być "ok, popraw H1, wyślij ten post w czwartek o 18:00, zaakceptuj?".

Audyt techniczny + UX

30 punktów technicznych: SSL, schema.org, prędkość (Google PSI), mobile, headings, meta, alty, broken links. Tech Health Score 0–100. Plus zakładka UX & Konwersja — analiza copy strony i Map (czy promocja "pierwsza wizyta 0 zł" jest widoczna?), CTA, formularze, rezerwacje.

Audyt odpala się raz w tygodniu w niedzielę o 23:00, UX raz w tygodniu poniedziałek 4:00. Wyniki cache'owane, klient widzi historię.

04. Stack od kuchni

Nudny stack jest dobry stack. Każda pozycja niżej była wybrana świadomie, większość to defaulty branżowe z konkretnym uzasadnieniem.

Trzy decyzje które warto rozwinąć osobno:

Dlaczego DataForSEO a nie SerpApi: DataForSEO ma local pack data dla polskich miast, niższa cena per request, dane od polskich data centrów (mniej geolocation noise).

Dlaczego Stripe a nie Paynow/Przelewy24: PL gateway są tańsze (1.5% vs 2.9%), ale Stripe ma lepsze API do subskrypcji, Customer Portal out-of-the-box, lepiej testuje się webhooks. Trade-off: 1% drożej, 10x mniej pisania kodu.

Dlaczego model selection (Haiku vs Sonnet) jako optymalizacja: Router w API decyduje na podstawie typu zapytania który model. Klient nie wie. Haiku do chatu (latency poniżej sekundy, koszt $0.001), Sonnet do "trudnych" zadań (Differentiation Coach który analizuje 5 konkurentów i znajduje luki). Opus nigdy nie używałem — overkill cenowy.

05. Architektura — co konkretnie powstało

Skala projektu w 4 liczbach:

Kilka decyzji architektonicznych które się obroniły:

Multi-tenant przez RLS. Każda tabela ma kolumnę user_id (UUID) i policy: auth.uid() = user_id. Frontend nie wie kim jest user — Supabase wymusza filtrowanie na poziomie bazy. Jeden bug po drodze: nowa tabela bez INSERT policy → user nie mógł nic zapisać. Złapane przez Playwright E2E test, dodane jako migracja 034.

Cron-driven, nie request-driven. 90% pracy dzieje się w nocy przez crony — odświeżanie GBP cache, AI Search Coach, audyt, GPS, holiday hours. Klient otwiera dashboard rano i widzi gotowe dane. Frontend jest cienki, większość kodu to background workers. Vercel Pro pozwala na crony co 1 minuta, ja używam max raz dziennie żeby zmieścić się w hobby tier compatibility.

Event bus (lekki, w bazie). Migracja 025 wprowadziła events tabelę. Akcje typu audit.completed, review.new, position.dropped lądują w bazie, listenery w /api/cron/* je czytają, generują notyfikacje, dodają do Daily Insight. Nie SQS, nie RabbitMQ — tylko SELECT events WHERE processed=false. Wystarcza.

Pending actions pattern. Destrukcyjne akcje AI (post na GBP, zmiana statusu leada) tworzą wpis w assistant_pending_actions. Klient widzi w UI "AI proponuje zrobić X — zaakceptuj?". Bez tego AI samo wysyłałoby posty na wizytówkę klienta, a halucynacja Haiku w produkcji to nie jest rzecz którą chcesz mieć.

06. Pair coding z agentem — tempo i sposób pracy

Tutaj jest sedno tego dlaczego o tym piszę. Ja nie pisałem kodu. Cały kod napisał Claude Code — agent w terminalu z dostępem do plików i Bash. Ja podejmowałem decyzje produktowe, testowałem, kontaktowałem klientów (gdy projekt był jeszcze aktywny), Claude pisał komponenty, schemę bazy, API routes, testy.

To brzmi jak buzzword ale w praktyce wygląda tak:

• Maks: "Dodaj feature X. Kontekst: użytkownik widzi listę opinii z GBP, chce móc kliknąć opinię i wygenerować odpowiedź AI w stylu firmy."
• Claude: czyta CLAUDE.md (kontekst projektu), lib/gbp/client.ts (jak czytamy opinie), lib/anthropic.ts (jak gadamy z Claude API), app/api/reviews/ (istniejące endpointy), proponuje plan z 5 krokami
• Maks: "OK, zaczynaj. Pamiętaj o RLS na nowej tabeli review_replies."
• Claude: pisze migrację SQL przez Supabase MCP, dodaje API route, dodaje komponent, robi build, deployuje, daje URL do testowania
• Maks: testuje, znajduje bug ("brakuje loading state"), wraca z feedbackiem
• Claude: poprawia, commituje, deployuje

Sesji było ~85 (mam je ponumerowane w Stan projektu.md), rozłożonych na 10 dni intensywnej pracy. Po 6–10 sesji dziennie, każda 1–2 godziny, w ramach jednej sesji 5–15 commitów. To nie był projekt rozłożony na pół roku weekendów — to były krótkie, mocno skondensowane przebiegi gdzie agent AI nadrabiał za mnie tempo, którego solo bym nie miał.

07. Koszty utrzymania

To jest część którą najwięcej osób zaskakuje. Zbudowanie nie jest drogie — utrzymanie też nie, dopóki klientów nie ma więcej niż 100. Math jest prosty.

To pokazuje dlaczego micro-SaaS w niszy local SEO ma sens. Marża 90%+ przy 50 klientach. Nawet jeśli koszty per-klient potrojone (50 zł zamiast 17 zł — np. ekstra integracje, abuse), marża nadal 75%+.

08. Czego się nauczyłem

Kolejność nieprzypadkowa. Najważniejsze pierwsze.

1. RLS musi mieć INSERT policy, nie tylko SELECT/UPDATE

Tabela bez INSERT policy to klient który widzi swoje dane ale nic nie może dodać. Wygląda jak bug w API. Migracja 034 łata to dla wszystkich tabel z sesji 84. Lekcja: pisząc nową tabelę, policy są częścią definicji tabeli, nie afterthought.

2. Haiku halucynuje akcje, jeśli system prompt jest zbyt "miękki"

3. Model selection jako optymalizacja UX, nie tylko kosztów

Haiku jest super do chatu (latency poniżej sekundy, koszt $0.001). Sonnet do "trudnych" zadań (Differentiation Coach który analizuje 5 konkurentów i znajduje luki — Haiku tu pisze ogólniki, Sonnet trafia w konkrety). Opus nigdy nie używałem — overkill cenowy.

Trick: router w API decyduje na podstawie typu zapytania który model. Klient nie wie. To jest nie-widoczna optymalizacja która sumuje się przy tysiącu requestów dziennie.

4. Trial bez karty kredytowej działa lepiej niż z kartą

Wahałem się. Wszyscy mówią "wymagaj karty żeby filtrować poważnych klientów". Po teście: bez karty → 4x więcej rejestracji, conversion na płatność po 14 dniach identyczny w procentach (mniej w liczbie absolutnej, ale leady warte więcej w long-tail).

Dla local SEO target (mała firma, nie tech), karta przy zakładaniu konta to friction killer. Lepiej dać 14 dni naprawdę, dosłać 3 emaile w trakcie, w 13. dniu pokazać "do końca trialu został 1 dzień, kliknij żeby kontynuować".

5. Onboarding 7 kroków konwertuje lepiej niż ekran "wszystko od razu"

Pierwszy onboarding miał 12 pól na jednym ekranie. Drop-off ~60%. Drugi ma 7 kroków × 1-2 pola, każdy z labelem "KROK 3 Z 7 · WIZYTÓWKA · ~3 MIN" i wyjaśnieniem "po co pytamy o NIP". Drop-off spadł do ~20%. Ludzie nie boją się długiego procesu, boją się procesu nieprzejrzystego.

6. Personal layer (Pro/Agency) > "pure SaaS" przy małej skali

09. Dlaczego pauza

Dwa racjonalne powody. Trzeci, mniej racjonalny: przy 90% gotowości projekt przestał być "fun coding", a zaczął być "biznes którego nie chcę teraz prowadzić". To jest sygnał. Lepiej go usłyszeć niż udawać że się go nie słyszy.

10. Co zostaje w portfolio

seohelper nie pójdzie do produkcji w obecnej formie. Ale zostaje jako dowód:

• Że można w 10 dni intensywnych sesji zbudować realny SaaS dla niszy
• Że pair coding z Claude Code skaluje się do produktu, nie tylko do skryptu
• Że micro-SaaS z personal layer może mieć marżę 90% przy 50 klientach
• Że RLS + crony + AI tool use + multi-tenant to stack który ogarnia jeden człowiek

Dla mnie zostaje też know-how dotyczące integracji GBP/GSC/GA4, AI Asystenta z tool use, kosztów utrzymania mikro-SaaSu. To jest fundament pod kolejne rzeczy które będę budował — niekoniecznie własne SaaSy, częściej automatyzacje dla agencji.

Kod żyje na GitHubie (maksbiderman-debug/seohelper). Demo na seohelper-mu.vercel.app. Jeśli kogoś interesuje konkretny moduł — schema migracji, jak zrobiłem AI tool use w Next.js, jak skonfigurowałem multi-tenant RLS — napisz mailem na kontakt@pokazmnie.pl, pokażę kod albo opiszę w osobnym poście.

Jeśli zastanawiasz się nad własnym projektem w pair codingu z agentem — najmocniej polecam zacząć od statycznego CLAUDE.md na korzeniu repo i MCP do twojego głównego datastore (Supabase, Postgres, cokolwiek). Te dwie rzeczy zmieniają wszystko.

Dziękuję, że doczytałeś. Jeśli coś było ciekawe albo niezrozumiałe — napisz, każdy mail czytam.