Dlaczego zbudowałem własny agentic CRM w jeden weekend?

Igor Jankowski ·

Zbudowałem od zera CRM z agentem AI jako głównym interfejsem. Nie klikam w UI — rozmawiam z systemem. Oto klocki, przewagi, minusy i lekcje (włącznie z tym jak agent wysłał "test" do całej bazy).

Jak zbudowałem własny CRM w weekend (i dlaczego to nie jest szaleństwo)

Kilka tygodni temu zbudowałem od zera CRM, który obsługuje wszystkie działania AI Business Builders: zapisy na webinary, leady, sekwencje mailowe, broadcasty, scoring, pipeline, dashboard z wykresami - cały stos.

Jestem przedsiębiorcą, który używa AI jako co-pilota do budowania customowych narzędzi, takich które są idealnie dopasowane do tego ro robię.

Ale zanim rozbijemy to na klocki - muszę powiedzieć o rzeczy, która była dla mnie najważniejsza.

Mój CRM nie ma "interfejsu" w tradycyjnym sensie

Owszem, mam dashboard. Ładne wykresy, lista leadów, filtry, statystyki maili. Ale to nie jest mój główny sposób korzystania z systemu.

Moim interfejsem jest agent AI.

Kiedy chcę przygotować broadcast do osób, które były na ostatnim webinarze i znają mnie z eventu offline - nie klikam w 14 dropdownów i nie buduję segmentu w UI. Mówię agentowi: "Przygotuj broadcast do osób, które były na webinarze X, oraz wydarzeniu Y . Temat: reminder, treść: przerób mój template, uwzględnij moje notatki głosowe z dnia Y."

Agent wie, jak wygląda moja baza. Wie, jakie mam tabele, jakie pola, jakie konwencje. Pisze SQL, generuje HTML maila i przygotowuje draft do mojego review.

Kiedy chcę zbudować nową sekwencję - nie wypełniam formularza z 8 polami. Mówię: "Stwórz 3-krokową sekwencję dla osób, które pobrały materiał X. Mail 1 po 2h, mail 2 po 48h, mail 3 po 5 dni. Template X (który wcześniej piszę)

Agent tworzy sekwencję w bazie, dopracowuje treść maili z moich briefów, ustawia triggery. Ja przeglądam i aktywuję.

Kiedy chcę analizę 0 nie otwieram dashboardu i nie scrolluję wykresów. Pytam: "Jaki mam conversion rate z webinarów vs. z materiałów do pobrania? Który source jest najbardziej zaangażowany?"

Agent queryuje bazę i daje mi odpowiedź z liczbami. Custom raport. Na życzenie. W 30 sekund.

To jest różnica między "własnym CRM" a "zbudowałem sobie HubSpota / Mailchimpa".

W SaaS-ie dostajesz interfejs zaprojektowany dla wszystkich - i dlatego pasujący do nikogo idealnie. W moim podejściu interfejs to rozmowa. Każde "zapytanie" do systemu jest custom. Nie muszę się dostosowywać do UI - to system dostosowuje się do mojego pytania.

Dlaczego to działa lepiej niż klikanie w SaaS

Brak limitu "automations". W HubSpocie masz X workflow-ów na plan. U mnie limit to wyobraźnia. Każda nowa automatyzacja to rozmowa z agentem.

Zero nauki interfejsu. Nie muszę pamiętać, gdzie jest przycisk "Create Sequence" ani jak działa segment builder. Mówię, czego chcę, w naturalnym języku. A wszystko zaprojetkowałem wcześniej sam, więc rozumiem swoje klocki.

Analizy ad hoc. "Pokaż mi osoby, którzy otworzyły 3+ maili w ostatnim miesiącu ale nie kliknęli ani razu." Spróbuj to wyklikać w Mailchimpie. W moim systemie to jedno zdanie → jeden query → odpowiedź.

Pomoc w pisaniu maili. Agent zna mój ton, mój biznes, moją ofertę, moje wpisy na LinkedIn i mój kalendarz wydarzeń. Jest moim asystentem i drugim mózgiem, który pozwala ogarnąć solo 10x więcej niż to kiedyś było możliwe.

System rośnie z każdą rozmową. Potrzebuję nowego pola w bazie? Nowego triggera? Nowego raportu? To nie jest "feature request". To jest: powiedz agentowi → gotowe.

5 klocków, z których składa się system

1. Baza danych (Supabase)

Fundament. PostgreSQL w chmurze z API REST-owym, autentykacją i serverless functions w jednym miejscu. Darmowy tier wystarczy na start.

Co trzymam w bazie:

  • • Kontakty - email, imię, skąd przyszli (first-touch attribution), tagi, status w lejku, scoring
  • Historia interakcji - każda rejestracja, każde kliknięcie, każdy zakup to osobny wpis. Nie nadpisuję - dopisuję. Pełna ścieżka leada od dnia 1
  • Sekwencje i kroki - jakie maile wysłać, w jakiej kolejności, z jakim opóźnieniem
  • Wysyłki - log każdego maila z jego statusem (delivered, clicked, bounced)

Kluczowa zasada: baza jest źródłem prawdy. Jedna baza, jeden schemat, pełna historia.

2. Wysyłka maili (Resend)

Resend to "rura" - wysyła maile i raportuje, co się z nimi stało. Za ~$20/msc.

Logika (do kogo, kiedy, co) jest po mojej stronie. Resend daje mi też webhooking - kiedy mail bounceuje lub ktoś kliknie link, dostaję callback, który aktualizuje bazę w czasie rzeczywistym.

3. Serverless Functions

Małe funkcje w chmurze, które robią konkretną robotę:

  • Przyjmowanie leadów - formularz wysyła dane → funkcja sprawdza, czy lead istnieje, loguje zdarzenie, automatycznie zapisuje do odpowiednich sekwencji
  • Silnik sekwencji - cron sprawdza co godzinę, kto powinien dostać następny mail. Pilnuje limitów, sprawdza, czy lead nie kupił już produktu
  • Broadcast - jednorazowe wysyłki do segmentów
  • Webhook handler - przyjmuje callbacki z Resend

Każda funkcja to 100-300 linii. Małe, niezależne klocki.

4. Dashboard (React)

Statyczna aplikacja webowa hostowana za darmo. Wykresy, listy, filtry. Przydatny do szybkiego przeglądu - ale nie jest moim głównym interfejsem.

5. Agent AI - prawdziwy interfejs

I tu dochodzimy do klocka, który jest dla mnie największą zmianą.

Agent (Claude Code) wraz ze skillami jest spięty z całym systemem. Zna schemat bazy, zna Edge Functions, zna konwencje, zna moje preferencje. Działa w dwóch trybach:

Tryb operacyjny - korzystam z CRM-a przez rozmowę:

  • "Przygotuj broadcast do segmentu X"
  • "Pokaż mi top 10 źródeł z ostatniego miesiąca"
  • "Stwórz sekwencję follow-up po webinarze Y"
  • "Ile osób z sekwencji Z kliknęło w link?"

Tryb deweloperski - rozbudowuję system przez rozmowę:

  • "Dodaj pole `phone` do tabeli kontaktów"
  • "Zbuduj nowy widok na dashboardzie z konwersją per źródło"
  • "Zmień logikę scoringu - webinar attend powinien dawać więcej punktów"

To ten sam agent w tym samym narzędziu. Operuję systemem i buduję go - z tego samego miejsca.

Prawdziwe przewagi

Interfejs = język naturalny. Zero nauki UI. Zero klikania w menu. Mówisz, czego chcesz.

Każda analiza jest custom. Nie jesteś ograniczony do raportów, które ktoś za Ciebie zaprojektował.

System rośnie z Tobą. Nowa potrzeba = nowa rozmowa z agentem = nowa funkcja w produkcji. Nie czekasz na roadmapę vendora.

Pełna kontrola nad danymi. SQL na własnej bazie. Export w sekundę. Łączenie z czymkolwiek.

Koszt bliski zeru. Supabase free tier + Resend ~$20/msc + GitHub Pages $0. Porównaj z HubSpot za $800/msc.

First-touch attribution. Wiem skąd przyszedł każdy lead - z którego webinaru, z jakiego UTM-a, z czyjego polecenia.

Uczciwe minusy

Jesteś sam na dyżurze. Nie ma supportu. Jak coś padnie o 23:00 - to Twój problem (i Twojego agenta).

Wymaga myślenia systemowego. Nie musisz umieć kodować - ale musisz rozumieć, jak przepływają dane. Co robi webhook. Dlaczego kolejność operacji ma znaczenie.

Brak gotowych integracji. HubSpot ma marketplace z 1000 wtyczkami. Ty masz API i agenta. (Ale: agent + API = integracja w 30 minut.)

Onboarding = Ty. Jeśli ktoś inny ma korzystać z systemu - musisz go wdrożyć sam.

Pułapka budowniczego. Łatwo wpaść w ciągłe budowanie zamiast korzystania. CRM ma służyć operacjom, nie być wiecznym side projectem.

Post mortem: jak agent wysłał rano "test" do całej bazy...

Skoro piszę o uczciwych minusach - muszę opowiedzieć o "incydencie", który przydarzył się w trakcie pisania tego artykułu. Z góry Was jeszcze raz za to przepraszam.

Co się stało

Agent wykonywał serię dodatkowych operacji administracyjnych na CRM-ie, które mu zleciłem - synchronizacja danych między bazą a systemem mailowym Resend - coś mi się nie zgadzało po initial seedzie, kiedy launchowałem system. W pewnym momencie wywołał produkcyjny endpoint `send-broadcast` z payloadem `{"subject":"test","body_html":"test"}` - bez flagi `test: true`.

Ta flaga istniała - zaprojektowałem ją żeby robić testy tylko na mój adres e-mail. Endpoint miał wbudowany tryb testowy - wystarczyło dodać `"test": true` do payloadu, żeby mail poszedł tylko do mnie. Agent o tym wiedział. Używał tej flagi wcześniej tego samego dnia. Ale w tym konkretnym momencie nie wysyłał maila - "tylko sprawdzałem coś innego". Więc nie pomyślał o fladze.

Efekt: cała baza na mojej liście dostała maila z tematem "test" i treścią "test". W poniedziałek rano.

Dlaczego to się stało

Agent traktował endpoint jak "narzędzie diagnostyczne" - wywołał go, żeby wyciągnąć z odpowiedzi informacje. Wiedział, że endpoint ma tryb testowy. Ale w jego "głowie" nie wysyłał broadcastu - robił coś innego, a endpoint był tylko środkiem do celu. Flaga `test: true` kojarzyła mu się z "wysyłam maila testowo", a on nie wysyłał maila - więc jej nie dodał.

Problem: endpoint nie rozróżnia intencji. Dostał subject, dostał HTML, nie dostał flagi testowej więc wysłał do wszystkich. Zgodnie ze swoją specyfikacją.

To jak mieć przycisk z osłonką bezpieczeństwa, ale nie zamknąć osłonki, bo "przecież nie wciskam przycisku, tylko wycierałem kurz obok".

Co z tego wynika

1. Agent nie rozumie blast radius. Agent widzi endpoint jako funkcję - input → output. Nie rozumie, że jeden POST to dużo maili w skrzynkach prawdziwych ludzi. Nie ma intuicji "to jest nieodwracalne". Musisz mu ją dać - explicit, w konfiguracji, wielkimi literami.

2. Zabezpieczenia muszą być w systemie, nie w głowie agenta. Napisanie "NIGDY nie rób X" w instrukcjach to za mało. Agent działa kreatywnie - znajdzie sto sposobów na obejście reguły, nie ze złośliwości, ale dlatego, że optymalizuje pod cel, nie pod zasady.

Prawdziwe zabezpieczenie tutaj to byłoby:

  • Dry-run jako default. Endpoint broadcastowy powinien domyślnie zwracać "wyślę do X osób" bez wysyłania. Wysyłka wymaga explicit `"confirm": true`. U mnie flaga `test` była opcjonalna - domyślnie endpoint wysyłał na produkcję. Powinno być odwrotnie: domyślnie dry-run, produkcja wymaga świadomego potwierdzenia.
  • Odmowa bez explicit intencji. Jeśli payload nie zawiera `"confirm": true` - endpoint powinien zwrócić preview (ile osób, jaki segment), a nie wysłać. Moja flaga `test: true` istniała, ale była opt-in. Bezpieczeństwo powinno być opt-out.

3. Cena błędu jest inna niż w kodzie. Kiedy agent zepsuje CSS - poprawiasz i deployujesz. Kiedy agent wyśle maila - nie cofniesz. Rozróżniaj operacje "read" od "write" i "write" od "blast". Broadcast to nie jest "write do bazy". Broadcast to X oddzielnych, nieodwracalnych akcji w skrzynkach pocztowych ludzi, z którymi budujesz relację.

Co zrobiłem po tym incydencie

Dodałem do konfiguracji agenta (CLAUDE.md) zasadę: nigdy nie wywołuj produkcyjnych endpointów do testowania, debugowania. Żadnych side effectów. Dane pobierasz z CLI, nie z odpowiedzi endpointu.

Ale to wciąż jest zabezpieczenie na poziomie instrukcji. Następny krok - przebudowa endpointu broadcastowego na model z explicit confirmation.

Wniosek

Jeśli budujesz system z agentem jako interfejsem - zaprojektuj tak, jakby obsługiwał je stażysta z dobrymi intencjami i zerową intuicją. Bo tak właśnie działa agent: jest kompetentny, szybki i absolutnie pozbawiony wyczucia konsekwencji.

Każdy endpoint, który robi coś nieodwracalnego, powinien mieć mechanizm potwierdzenia. Nie dlatego, że agent jest głupi - ale dlatego, że jest zbyt pewny siebie.

Agentic interface - to nie tylko custom CRM

Żeby było jasne: nie musisz budować własnego CRM-a, żeby korzystać z agentic interface.

Dzisiaj wiele narzędzi udostępnia MCP (Model Context Protocol) - standard, który pozwala agentowi AI łączyć się z zewnętrznymi systemami. Są MCP servery do HubSpota, Notion, Google Calendar, Slacka, Supabase i dziesiątek innych narzędzi. Podpinasz je do Claude'a i nagle Twój agent może czytać dane z CRM-a, tworzyć zadania w Notion, sprawdzać kalendarz - wszystko z poziomu jednej rozmowy.

To działa. I dla wielu osób to wystarczy.

Ale ja poszedłem krok dalej - bo chciałem czegoś więcej niż "agent, który gada z HubSpotem".

Dlaczego custom stack daje więcej

Kiedy budujesz własny system, agent nie jest "podpięty" do narzędzia - agent jest częścią narzędzia. Zna schemat bazy, bo ją sam stworzył. Zna logikę sekwencji, bo ją sam napisał. Zna konwencje nazewnictwa, bo sam je wdrażał. I zarówno w obsłudze jak i rozbudowie operuje w ramach jednego repo.

To jak różnica między tłumaczem, który zna dwa języki, a kimś, kto w tym języku myśli.

Ale prawdziwa przewaga mojego podejścia jest gdzie indziej.

Cały ekosystem, nie tylko CRM

Mój CRM to jeden klocek. Obok niego mam:

  • Własną stronę internetową - formularze rejestracyjne, landing pages, strony webinarów. Wszystkie spięte z CRM-em przez jedno API. Osoba rejestruje się na webinar → trafia do bazy → automatycznie wchodzi w sekwencję. Zero Zapiera, zero "middleware"
  • Armię custom agentów do contentu - mam osobne skille / agenty do pisania newsletterów, przygotowywania mailingów, repurposingu treści z webinarów, tworzenia postów na LinkedIn. Każdy z nich zna mój ton, moją ofertę, moją bazę odbiorców
  • Pipeline contentowy - od pomysłu przez draft po wysyłkę. Agent skanuje co mam w przygotowaniu, co nadchodzi w kalendarzu, jaki temat jest "gorący" - i proponuje content plan. Inny agent pisze draft do mojego review. Inny przygotowuje broadcast w CRM-ie

To wszystko gra razem, bo jest zbudowane wokół tych samych danych, tych samych konwencji, tego samego agenta.

W podejściu SaaS + MCP masz agenta, który "rozmawia" z 5 oddzielnymi narzędziami. W moim podejściu agent mieszka w systemie, który sam zbudował. Widzi wszystko. Rozumie kontekst. I - co kluczowe - może zmieniać system, a nie tylko z niego czytać.

Rekomendacja: zacznij od MCP, potem buduj

Jeśli dopiero zaczynasz z agentic workflow - zacznij od MCP. Podepnij swojego agenta do narzędzi, których już używasz. Poczuj, jak to jest operować systemami przez rozmowę zamiast przez klikanie.

A kiedy poczujesz, że MCP Ci nie wystarcza - że chcesz głębszej integracji, że potrzebujesz agenta, który nie tylko czyta dane, ale rozumie cały Twój biznes - wtedy zacznij budować własne klocki.

Bo prawdziwy game changer to nie "AI-powered CRM". To ekosystem narzędzi, z którym rozmawiasz - i który rośnie razem z Tobą.

Nie potrzebujesz "deploymentu"

Kolejna rzecz, która łamie oczekiwania: mój CRM działa lokalnie. Na moim komputerze. Baza jest w chmurze (Supabase), Edge Functions są zdeployowane - ale dashboard, agent, cały "interfejs" to mój lokalny setup.

Narazie nie mam serwera, na którym "hostuje CRM". Nie mam CI/CD pipeline do dashboardu. Otwieram terminal, odpalam Claude Code - i pracuję. Dashboard mogę odpalić lokalnie jedną komendą, kiedy potrzebuję wizualizacji. Ale najczęściej po prostu rozmawiam z agentem.

Dlaczego? Bo nie potrzebuję. To narzędzie dla mnie, nie dla zespołu 50 osób. Nie musi być "dostępne 24/7 pod URL-em". Ma być dostępne wtedy, kiedy ja pracuję - a wtedy i tak mam otwarty terminal.

To kolejna rzecz, o której nie pomyślisz, gdy ktoś mówi "CRM" - wyobrażasz sobie app w chmurze z loginem. A tu: lokalne narzędzie, które gada z bazą w chmurze. Prostsze niż myślisz.

Security review - bo agent czasem idzie na skróty

Jedna ważna lekcja, którą chcę przekazać wprost: kiedy budujesz narzędzie, które wysyła maile do ludzi - security to nie nice-to-have.

Zrobiłem podwójny security review całego systemu w Claude Code. I dobrze, bo złapałem agenta na tym, że w jednym miejscu poszedł na skróty. Nic dramatycznego - raczej nikt by tego nie wykorzystał. Ale właśnie o to chodzi.

Agent AI to fantastyczny budowniczy. Ale on optymalizuje na "działa" - a nie zawsze na "działa i jest bullem-proof". Kiedy budujesz system, który dotyka danych osobowych i wysyła maile, musisz być tym, kto pilnuje granic.

Moja rada:

  • Rób security review po każdej większej fazie. Poproś agenta: "Przejrzyj cały kod pod kątem bezpieczeństwa - SQL injection, brak autoryzacji, wycieki danych." Agent jest w tym dobry - ironicznie, lepiej weryfikuje cudzy kod niż swój własny
  • Weryfikuj podpisy webhooków. Jeśli Resend (albo Stripe, albo cokolwiek) wysyła Ci callbacki - sprawdzaj podpis. Bez tego ktoś może Ci wysyłać fałszywe eventy
  • Nigdy nie ufaj inputowi z formularzy. Email lowercase + trim to minimum. Walidacja, sanityzacja, rate limiting - agent to napisze, ale musisz go o to poprosić
  • Testuj z flagą `test: true`. Zanim wyślesz broadcast do wszystkich z bazy - upewnij się, że jest tryb testowy. Ja się tego nauczyłem boleśnie

Budowanie własnych narzędzi daje ogromną wolność. Ale wolność = odpowiedzialność. Agent jest Twoim programistą - a Ty jesteś jego code reviewerem.

Jak podejść do budowania

1. Zacznij od danych, nie od UI. Zdefiniuj, co chcesz śledzić. Jakie pola ma kontakt? Jakie zdarzenia logujesz? Jaki masz lejek? Baza to fundament.

2. Buduj w fazach. Faza 1: baza + import kontaktów. Faza 2: API do nowych leadów. Faza 3: silnik mailowy. Faza 4: dashboard. Każda faza daje wartość osobno.

3. Webhook = closed loop. Kiedy system sam reaguje na eventy (bounce → wyłącz subskrypcję, klik → zapisz) - zmienia się z pasywnej bazy w żywy organizm.

4. Agent od dnia pierwszego. Nie buduj "a potem podłączę AI". Buduj Z agentem od pierwszego dnia. On pisze migracje, on tworzy funkcje, on deployuje. A potem - on jest Twoim interfejsem do tego systemu.

5. Konwencje > Kod. Nazwij rzeczy konsekwentnie od dnia pierwszego. Źródła, tagi, produkty, statusy. Brak konwencji = chaos, którego potem nie ogarnie nawet najlepszy agent.

6. Dashboard buduj na końcu. Przez pierwsze tygodnie wystarczy Ci agent + SQL. Dashboard to wizualizacja - ważna, ale nie krytyczna na start.

7. Security review po każdej fazie. Agent buduje szybko - ale Ty musisz weryfikować. Zwłaszcza kiedy system dotyka maili i danych osobowych.

Dla kogo to jest

To podejście jest dla kogoś, kto:

  • Ma specyficzny workflow, którego żaden SaaS nie obsługuje dobrze
  • Chce, żeby interfejsem do CRM-a była rozmowa, nie formularze
  • Umie (lub uczy się) współpracować z agentem AI
  • Ma na tyle mały zespół, że nie potrzebuje enterprise'owych uprawnień
  • Traktuje narzędzia jako przewagę, a nie koszt

Jeśli prowadzisz biznes edukacyjny, consultingowy, czy SaaS z <10K kontaktów - własny CRM z agentem jako interfejsem może być Twoim unfair advantage.

Nie dlatego, że zbudowałeś "tańszego HubSpota". Ale dlatego, że zbudowałeś coś, czego HubSpot nie potrafi - system, z którym rozmawiasz.