Andrey Boyko
Zaproponuj Andrey pracę nad swoim kolejnym zleceniem.
Prywatna wiadomość
Zaproponuj zlecenie
Charków,
Ukraina
20 dni 15 godzin temu
gotowy do podjęcia pracy
w Serwisie 9 lat
Ranking
Zakończonych zleceń
Średnia ocena
Poziom znajomości języków obcych
English: zaawansowany
Українська: poziom wyżej niż średni
Umiejętności i kwalifikacje
Programowanie
Outsourcing i konsulting
Portfolio
-
Trwała Pamięć Wektorowa dla Kodu Claude: Serwer MCP Open-Source
AI i uczenie maszynowe
Sytuacja
Claude Code to potężny asystent kodowania AI, ale jest zaprojektowany jako bezstanowy. Każda nowa sesja zaczyna się bez wiedzy o przeszłych decyzjach, błędach czy architekturze. W rzeczywistej pracy produkcyjnej prowadzi to do ciągłej powtarzalności, utraty kontekstu i wolniejszego rozwoju.
Problem
… Podstawowy problem: asystent AI pomagający w budowie projektu nie ma pamięci o jego budowie. Odkrywałem te same błędy, ponownie wyjaśniałem tę samą architekturę i traciłem decyzje podjęte w zeszłym tygodniu. Problem wtórny: powtarzające się wzorce w projektach (jak "ustawiliśmy Supabase w ten dokładny sposób 4 razy") pozostawały ukryte w pamięciach sesji zamiast stać się wielokrotnego użytku, udokumentowanymi umiejętnościami.
Rozwiązanie
Zbudowałem memory-mcp, serwer MCP open-source, który daje Claude Code długoterminową pamięć semantyczną. Udostępnia 8 narzędzi: 4 podstawowe narzędzia pamięci (zapamiętaj, przypomnij, zapomnij, status_projektu) oraz 4 narzędzia wzorców umiejętności, które śledzą powtarzające się wzorce pracy i ujawniają kandydatów do formalizacji po ich zobaczeniu 3+ razy.
Pamięci są przechowywane jako osadzenia wektorowe o wymiarach 1536 (OpenAI text-embedding-3-small) w Supabase PostgreSQL z pgvector. Wyszukiwanie odbywa się za pomocą wyszukiwania podobieństwa cosinusowego przez funkcję RPC Postgres z filtrowaniem na poziomie SQL (próg, projekt, typ, data, wygaśnięcie) w jednej rundzie. Odpowiedzi przypomnienia są ograniczone do ~2000 tokenów, aby chronić okno kontekstowe Claude'a.
Serwer działa jako bezstanowy kontener Docker na porcie 3101 za pomocą Express + transportu HTTP Streamable, więc wiele sesji Claude Code dzieli jedną zawsze aktywną instancję. Dostępny jest również tryb transportu stdio do bezpośredniej integracji z natywnym binarnym. Pamięci nigdy nie są trwale usuwane: zapomnienie to miękkie usunięcie przez expires_at, a każde zapytanie filtruje na podstawie statusu aktywnej pamięci.
Stos technologiczny: Node.js 20, TypeScript 5 (ścisły), Express 5, @ modelcontextprotocol/sdk, OpenAI API (text-embedding-3-small), Supabase PostgreSQL, pgvector, indeksy IVFFlat, walidacja Zod, Vitest, Docker Compose.
Wyniki
- 8 narzędzi MCP dostarczonych i przetestowanych end-to-end przez HTTP
- 125 testów jednostkowych z klientami Supabase i OpenAI w pełni zamockowanych
- ~2600 linii TypeScript w 16 plikach źródłowych, 11 commitów w ciągu 11 dni
- 2 tabele, 3 funkcje RPC z filtrowaniem na poziomie SQL przed LIMIT dla poprawności
- Działanie w produkcji jako zawsze aktywna usługa Docker, używana codziennie z rzeczywistymi sesjami Claude Code
- Opublikowane jako open-source na GitHubie z pełną dokumentacją konfiguracji, Docker Compose i przewodnikiem rozwiązywania problemów obejmującym 4 udokumentowane tryby awarii
Kluczowe decyzje inżynieryjne
1. Empiryczne progi podobieństwa. text-embedding-3-small produkuje niższe wyniki cosinusowe niż sugerują dokumenty (niemal identyczne teksty mają wyniki 0.78–0.84). Obniżyłem próg przypomnienia do 0.25 i deduplikacji do 0.75 na podstawie rzeczywistych pomiarów, udokumentowałem tę zasadę dla przyszłych funkcji.
2. Filtrowanie dat na poziomie SQL. Filtr since_days początkowo działał po stronie klienta po LIMIT, co cicho pomijało niedawne pamięci sklasyfikowane poniżej top N. Przeniesienie go do klauzuli WHERE przed LIMIT gwarantuje poprawność niezależnie od objętości danych.
3. Opisy narzędzi jako instrukcje wykonawcze. Opisy narzędzi zostały przepisane z "co robią" na "kiedy je wywołać" (np. "Wywołaj przed rozpoczęciem niebanalnej pracy"), dzięki czemu narzędzia działają poprawnie bez potrzeby utrzymywania CLAUDE.md.
4. Obejście OAuth dla natywnego binarnego Claude Code. Binarne blokuje połączenia HTTP MCP, dopóki odkrycie OAuth się nie zakończy. Dodanie statycznego tokena Bearer do konfiguracji MCP całkowicie pomija odkrycie (token jest arbitralny i nigdy nie jest weryfikowany po stronie serwera).
Dostępne na GitHubie
Pełne źródło, instrukcje konfiguracji i dokumentacja architektury opublikowane dla deweloperów, którzy chcą replikować lub rozszerzać system.
-
Agent Sprzedaży AI przez Głos, Czat, Telegram, WhatsApp (Jedna Rura)
AI i uczenie maszynowe
Sytuacja
Agencja sprzedaży B2B prowadziła kwalifikację leadów w dużej skali dla swoich klientów. Potencjalni klienci kontaktowali się przez 4 kanały: widget na stronie internetowej, rozmowy telefoniczne, Telegram i WhatsApp. Agencja chciała zautomatyzować pierwsze rozmowy kontaktowe we wszystkich tych kanałach bez zatrudniania dodatkowych SDR-ów.
Problem
… Większość narzędzi do automatyzacji sprzedaży jest specyficzna dla kanału. Chatbot dla strony internetowej. Oddzielny bot Telegram. Inny dostawca dla głosu. Każde narzędzie ma swoje własne rekordy leadów, swoje własne skrypty, brak wspólnej inteligencji. Kiedy ten sam potencjalny klient skontaktował się przez Telegram, a później zadzwonił na główny numer, nikt nie połączył tych dwóch interakcji. Wyniki leadów były fragmentaryczne. Odpowiedzi w bazie wiedzy były niespójne w różnych kanałach. A rozmowy wychodzące nadal wymagały ludzkiego SDR-a dzwoniącego przez arkusz kalkulacyjny.
Agencja potrzebowała jednego mózgu za każdym kanałem, a nie czterech połączonych narzędzi.
Rozwiązanie
Zbudowałem zintegrowaną platformę sprzedażową, w której każda wiadomość przepływa przez tego samego agenta AI. Głos, czat, Telegram, WhatsApp: każdy kanał ma cienki adapter, który normalizuje przychodzące wiadomości, a następnie przekazuje je do wspólnej ChatService. Ta usługa wyszukuje lead, pobiera odpowiednią wiedzę za pomocą RAG (osadzenia Voyage AI w pgvector) i przekazuje historię rozmowy agentowi, który odpowiada na pytania oparte na rzeczywistych dokumentach produktowych firmy, cenach i FAQ. Te same rekordy leadów, ta sama baza wiedzy, te same wyniki we wszystkich 4 kanałach.
W przypadku rozmów wychodzących operatorzy przesyłają listę kontaktów, dołączają skrypt głosowy i uruchamiają kampanię z panelu administracyjnego. Pracownicy BullMQ dzwonią do kontaktów przez Retell AI z ograniczoną prędkością 1 połączenie/sekundę. Retell obsługuje telekomunikację i mowę; mój niestandardowy punkt końcowy WebSocket przesyła transkrypcję każdego połączenia do agenta w czasie rzeczywistym. Po każdym połączeniu webhooks Retell dostarczają transkrypcję, podsumowanie rozmowy i analizę sentymentu z powrotem do platformy, która automatycznie dostosowuje wyniki leadów (+10 za pozytywny sentyment, -5 za negatywny).
Osadzany widget to 53KB jednofileowy pakiet Vite IIFE, który można umieścić na dowolnej stronie internetowej za pomocą jednego tagu skryptu, renderuje się wewnątrz Shadow DOM, aby uniknąć konfliktów CSS, i przywraca historię czatu po przeładowaniu strony za pomocą localStorage.
Stos technologiczny: NestJS, TypeScript, Claude API (Anthropic SDK), Retell AI, osadzenia Voyage AI, OpenAI Whisper, Supabase (PostgreSQL + pgvector), BullMQ, Redis, Next.js, Vite, Docker, nginx, Cloudflare Tunnel
Wyniki
- 4 kanały zintegrowane w 1 pipeline AI: rozmowy głosowe, czat na stronie, Telegram, WhatsApp dzielą rekordy leadów, bazę wiedzy i wyniki
- Rozmowy wychodzące w pełni zautomatyzowane: operatorzy konfigurują kampanię raz, system dzwoni, prowadzi rozmowy, transkrybuje i ocenia każdy kontakt bez udziału SDR-a
- Gotowe do wieloosobowego użytkowania: organizacje, RBAC i bazy wiedzy dla każdej organizacji wbudowane, dzięki czemu platforma może obsługiwać wielu klientów agencji
- W fazie testów z partnerami z 7 usługami Docker, podpisaną weryfikacją webhooków i pokryciem testów w 34 plikach testowych (jednostkowe, integracyjne, zachowanie AI, E2E)
Jak to działa
1. Potencjalny klient kontaktuje się przez jeden z 4 kanałów (widget, telefon, Telegram, WhatsApp)
2. Adapter kanału normalizuje wiadomość i tworzy lub wyszukuje lead
3. ChatService pobiera historię rozmowy i przeprowadza wyszukiwanie semantyczne w bazie wiedzy firmy
4. Agent generuje odpowiedź opartą na pobranych dokumentach
5. Odpowiedź wraca przez ten sam adapter kanału
6. Wynik leadu aktualizuje się na podstawie sygnałów wiadomości lub (w przypadku głosu) analizy sentymentu po rozmowie
-
Wdrażanie SOP Kalendarza: 3 Kalendarze, Zero Ręcznej Weryfikacji
AI i uczenie maszynowe
Sytuacja
Amerykański fundusz inwestycyjny działa zgodnie z rygorystycznymi procedurami spotkań. Poranki są zarezerwowane na głęboką pracę, poniedziałki są tylko wewnętrzne, wtorki są tylko zewnętrzne, środy i czwartki absorbują nadmiar z twardym limitem, a piątki są wolne od spotkań. Zespół dzieli również czas na trzy oddzielne kalendarze Google: Biznesowy, Funduszowy i Osobisty. Popełnienie jakiegokolwiek błędu kosztuje koncentrację, czas na transakcje, a ostatecznie zaufanie partnerów.
Problem
… Wdrażanie było ręczne. Ktoś musiał codziennie przeszukiwać trzy kalendarze, zauważyć spotkanie zaplanowane przed południem, wychwycić dwa wydarzenia jedno po drugim bez bufora, oznaczyć zewnętrzne rezerwacje w dniu wewnętrznym. Przeglądy były żmudne, spóźnione i łatwe do przeoczenia. Wcześniejsza próba wykorzystania wbudowanych statycznych danych n8n, aby uniknąć powtarzających się powiadomień, nie powiodła się, ponieważ ten stan resetuje się przy każdym zapisie przepływu pracy. W praktyce to samo naruszenie było ponownie wysyłane do Slacka co 5 minut przez cały dzień. Zmęczenie powiadomieniami się pojawiło, a zespół zaczął ignorować kanał, co zniweczyło cel.
Rozwiązanie
Zbudowałem dwupoziomowy system n8n wspierany przez Supabase. Monitor w czasie rzeczywistym sprawdza wszystkie trzy kalendarze Google co 5 minut, przetwarza każde wydarzenie przez silnik audytu SOP (czas, bufor, typ dnia, dzienne limity) i publikuje naruszenia na dedykowanym kanale Slack. Codzienny audyt odbywa się o 8:30 czasu ET z pełnym przeszukiwaniem tygodnia i sugestiami dotyczących zmiany harmonogramu generowanymi przez AI, a w piątki wysyła drugą wiadomość zapowiadającą nadchodzący tydzień.
Warstwa deduplikacji to element, który sprawił, że to działa w produkcji. Każde naruszenie otrzymuje stabilny klucz (reguła + data + hash wydarzenia). Przed wysłaniem czegokolwiek do Slacka, przepływ pracy pobiera zgłoszone powiadomienia tygodnia z tabeli Supabase i porównuje je z różnicami zbiorów. Tylko naprawdę nowe naruszenia trafiają do Slacka. Każdego ranka codzienny audyt usuwa wiersze z poprzedniego tygodnia, utrzymując tabelę wąską.
Cały system działa wewnątrz n8n i Supabase. Brak serwera niestandardowego, brak Dockera, brak lokalnego kodu. Cały zestaw narzędzi jest zarządzany przez serwery MCP, więc aktualizacje przepływu pracy, zmiany schematu i wdrożenia odbywają się przez kontrolowany interfejs zorganizowany przez AI z granicą bezpieczeństwa od stagingu do produkcji.
Stos technologiczny: n8n, Supabase, PostgreSQL, Google Calendar API, Slack API, OpenAI API, MCP (Model Context Protocol)
Wyniki
- 3 kalendarze Google monitorowane nieprzerwanie bez ręcznego przeglądu
- Wykrywanie w ciągu 5 minut od naruszenia do powiadomienia na Slacku
- Zero duplikatów powiadomień po tym, jak warstwa deduplikacji Supabase zastąpiła delikatny hash w pamięci
- Codzienny audyt o 8:30 z sugestiami zmiany harmonogramu AI, plus piątkowy przegląd następnego tygodnia
- Architektura bezserwerowa: brak serwera aplikacji, brak Dockera, zarządzana całkowicie przez n8n i Supabase
- Bezpieczne wdrożenia: zmiany w produkcyjnym przepływie pracy wymagają wyraźnej potwierdzenia operatora
Jak to działa
1. Harmonogram uruchamia się co 5 minut i odczytuje stan synchronizacji z Supabase
2. Wydarzenia pobierane z Biznesowego, Funduszowego i Osobistego kalendarza Google oraz zatwierdzonej białej listy wyjątków
3. Wykrywanie zmian kończy się wcześnie, jeśli nic się nie zmieniło od ostatniego sprawdzenia
4. Silnik audytu SOP ocenia każde wydarzenie według czasu, bufora, typu dnia i zasad limitów
5. Warstwa deduplikacji porównuje nowe klucze naruszeń z zgłoszonymi powiadomieniami tygodnia w Supabase
6. Naprawdę nowe naruszenia są publikowane na Slacku i zapisywane z powrotem do Supabase
-
AI-Natywna Kontrola dla Worksection: Claude, Cursor, ChatGPT przez M
AI i uczenie maszynowe
Kontrola AI-Native dla Worksection: Claude, Cursor, ChatGPT przez MCP
Sytuacja
Klient prowadził całą swoją działalność w Worksection: zadania, projekty, komentarze, koszty, przypisania zespołu. Ich zespół również w pełni zaangażował się w asystentów AI (Claude, Cursor, ChatGPT) do codziennej pracy. Jednak te dwa światy były od siebie odłączone. AI nie wiedziało nic o Worksection, a Worksection nie wiedziało nic o AI.
… Problem
Każda interakcja między tymi dwoma narzędziami była manualna. Programista prosił Claude'a o sporządzenie opisu zadania, a następnie ręcznie kopiował go do Worksection. Kierownik projektu robił zrzut ekranu statusu projektu i wklejał go do ChatGPT, aby podsumować. AI mogło myśleć o pracy, ale nie mogło jej wykonać. Ta pętla kopiowania i wklejania zabiła większość zysku wydajności, jakiego klient oczekiwał od AI w pierwszej kolejności. Potrzebowali, aby AI mogło czytać i pisać w Worksection bezpośrednio, z odpowiednią autoryzacją, bez wspólnych poświadczeń i bez ręcznie tworzonych integracji dla każdego członka zespołu.
Rozwiązanie
Zbudowałem serwer MCP (Model Context Protocol) produkcji, który znajduje się między każdym klientem AI zgodnym z MCP a API Worksection. AI wywołuje nazwane narzędzie, takie jak post_task lub get_projects, a serwer zajmuje się autoryzacją, ograniczeniem liczby żądań, tłumaczeniem ładunków i kształtowaniem odpowiedzi.
Działa jako wielo-tenantowy SaaS: każdy zespół rejestruje się raz, otrzymuje własne zaszyfrowane poświadczenia i klientów OAuth, a następnie łączy Claude'a lub Cursor z jednym URL. Panel administracyjny (React + Vite) pozwala operatorowi zarządzać najemcami, rotować sekrety OAuth, dostosowywać limity liczby żądań dla każdego najemcy i dokładnie widzieć, które narzędzia są wywoływane i jak często.
Trzy decyzje techniczne zdefiniowały budowę. Po pierwsze, API Worksection autoryzuje tylko z ciągu zapytania URL (ciała POST są ignorowane przez jego walidację hasha), więc każde wywołanie wychodzące używa kodowania w dwóch etapach: surowy ciąg do haszowania MD5, ponownie zakodowany ciąg do transportu. Po drugie, każdy klucz API najemcy jest szyfrowany w spoczynku za pomocą AES-256-GCM; tekst jawny nigdy nie dotyka bazy danych. Po trzecie, odpowiedzi API są aktywnie kompresowane przed zwróceniem do AI, ponieważ surowe ładunki Worksection mogą przekroczyć okno kontekstu modelu w dużych projektach.
Stos technologiczny: Node.js 20, TypeScript, Express, @modelcontextprotocol/sdk, Supabase (PostgreSQL), OAuth2, AES-256-GCM, Zod, Winston, React, Vite, Docker, nginx, Hetzner VPS.
Wyniki
26 narzędzi MCP działa w produkcji w 7 kategoriach: zadania, projekty, komentarze, członkowie, koszty, tagi, pliki
Wielo-tenantowy SaaS z autoryzacją OAuth2, limitami liczby żądań dla każdego najemcy i zaszyfrowanymi poświadczeniami
Brak kopiowania i wklejania między asystentem AI a Worksection w codziennych operacjach projektowych
30-dniowe tokeny OAuth dostosowane specjalnie do wzorców użycia klientów AI (brak cichych błędów 401 w trakcie sesji)
Panel administracyjny z zarządzaniem najemcami, rotacją sekretów OAuth i analizą użycia dla każdego narzędzia w oknach 7/30/90 dni
Wzmocnione produkcyjnie: wdrożenie Docker, nginx jako reverse proxy, punkt zdrowia z metadanymi budowy, strukturalne logowanie
Aktywne w produkcji, obsługujące rzeczywistych najemców na żywym VPS
Jak to działa
1. Najemca rejestruje się za pomocą swojego URL Worksection i klucza API; serwer szyfruje klucz i wysyła e-mail z potwierdzeniem OTP
2. Najemca potwierdza za pomocą OTP, konto aktywuje się
3. Klient AI (Claude, Cursor, ChatGPT) autoryzuje się za pomocą OAuth2 i otrzymuje 30-dniowy token dostępu
4. AI wywołuje narzędzie (np. post_task); serwer weryfikuje token dostępu i rozwiązuje najemcę z pamięci podręcznej
5. Serwer tłumaczy wywołanie na żądanie GET Worksection z hasłem MD5, ponawia z opóźnieniem w przypadku niepowodzenia
6. Skondensowana odpowiedź wraca do AI; użycie jest rejestrowane w Supabase do analizy
-
Asystent AI dla ServiceFusion: Zapytaj o oferty pracy przez czat, a nie kliknięcia
AI i uczenie maszynowe
Sytuacja
Operator serwisu polowego działający na ServiceFusion chciał, aby dyspozytorzy i pracownicy biura przestali klikać przez menu za każdym razem, gdy potrzebowali sprawdzić historię pracy klienta, otworzyć wyceny lub zobaczyć, który technik został przypisany do zadania. Zespół już korzystał z Claude do innych zadań. Oczywistym krokiem naprzód: pozwolić Claude rozmawiać bezpośrednio z ServiceFusion.
Problem
… ServiceFusion udostępnia REST API, ale asystenci AI nie mogą wywoływać go bezpośrednio. Protokół Kontekst Modelu (MCP) jest nowym standardem umożliwiającym klientom AI strukturalny dostęp do zewnętrznych narzędzi, a żaden serwer MCP nie istniał dla ServiceFusion. Zbudowanie go poprawnie oznaczało rozwiązanie trzech problemów jednocześnie:
Cykl życia tokena OAuth2. ServiceFusion używa krótkoterminowych tokenów dostępu, które wygasają i muszą być odświeżane w sposób przezroczysty, aby AI nigdy nie napotkało błędu autoryzacji w trakcie rozmowy.
Wielu najemców. Jedna instancja serwera musiała izolować dane uwierzytelniające i wywołania API dla wielu firm, z każdą mającą swoje własne konto ServiceFusion.
Samodzielna rejestracja. Operator nie chciał konfigurować każdego nowego najemcy ręcznie.
Rozwiązanie
Zbudowałem serwer MCP dla wielu najemców w Node.js i TypeScript, który znajduje się pomiędzy klientami AI (Claude, Cursor, ChatGPT) a ServiceFusion. Udostępnia 13 strukturalnych narzędzi obejmujących podstawowe encje, z których rzeczywiście korzystają dyspozytorzy: klienci, zadania, wyceny, technicy i sprzęt.
Serwer obsługuje dwie niezależne warstwy OAuth2. Jedna uwierzytelnia przychodzące klientów AI do serwera MCP. Druga zarządza własnymi tokenami ServiceFusion serwera, w tym automatycznym odświeżaniem z blokadą współbieżności, aby jednoczesne żądania nigdy nie wywoływały podwójnych odświeżeń.
Wszystkie wrażliwe dane uwierzytelniające (identyfikatory klientów, sekrety, tokeny) są szyfrowane w spoczynku za pomocą AES-256-GCM w Supabase PostgreSQL. Nowi najemcy rejestrują się samodzielnie przez REST API, potwierdzają za pomocą OTP i dostarczają swoje dane uwierzytelniające ServiceFusion do aktywacji. Brak ręcznej pracy operatora przy rejestracji.
Lekki panel administracyjny pozwala operatorowi przeglądać wykorzystanie na najemcę, dostosowywać limity prędkości oraz aktywować lub dezaktywować konta.
Stos technologiczny: Node.js 20, TypeScript, @ modelcontextprotocol/sdk, Express, Supabase (PostgreSQL), szyfrowanie AES-256-GCM, Zod, Winston, Docker, nginx, Let's Encrypt
Wyniki
13 narzędzi MCP działa w obszarze klientów, zadań, wycen, techników i sprzętu
Brak ręcznej konfiguracji dla najemcy. Samodzielna rejestracja OTP i proces aktywacji
Przezroczysty OAuth2. Wygasłe tokeny odświeżają się automatycznie z ochroną przed warunkami wyścigu
Limity prędkości na najemcę (darmowe, pro, przedsiębiorstwo) egzekwowane na poziomie żądania
Pełne śledzenie wykorzystania (nazwa narzędzia, punkt końcowy, kod statusu, czas odpowiedzi) rejestrowane na najemcę do rozliczeń i analityki
Wdrożone do produkcji na Hetzner VPS za nginx z SSL, współistniejące z siostrzanym serwerem MCP na tym samym hoście
Jak to działa
1. Najemca wysyła POST do /api/register z nazwą firmy i adresem e-mail, otrzymuje 6-cyfrowy OTP
2. Najemca potwierdza przez /api/confirm, a następnie aktywuje, dostarczając dane uwierzytelniające OAuth ServiceFusion
3. Dane uwierzytelniające są szyfrowane za pomocą AES-256-GCM i przechowywane w Supabase
4. Klient AI (Claude, Cursor) wywołuje /mcp z tokenem dostępu; middleware identyfikuje najemcę i sprawdza limit prędkości
5. Przy wywołaniu narzędzia serwer sprawdza ważność tokena i automatycznie go odświeża, jeśli wygasł
6. Strukturalna odpowiedź wraca do klienta AI, a wywołanie jest rejestrowane do analityki wykorzystania
-
Inteligencja cenowa artykułów spożywczych: oszczędności w koszyku powyżej 60% w 4 sklepach
AI i uczenie maszynowe
Inteligencja cenowa artykułów spożywczych: oszczędności w koszyku powyżej 60% w 4 sklepach
Sytuacja
Ukraiński założyciel technologii konsumenckiej chciał zaoferować klientom coś, czego nie oferowała żadna lokalna aplikacja: jednoczesny widok pełnego koszyka spożywczego wycenionego w czterech największych sieciach dostawczych w kraju. Ostateczny cel był prosty. Klient wpisuje tygodniową listę, widzi, który sklep jest najtańszy dla tego dokładnego koszyka i buduje zwycięski koszyk jednym kliknięciem.
… Problem
Ukraińscy klienci spożywczy zazwyczaj przyzwyczajają się do jednej sieci z nawyku i przepłacają, nie zdając sobie z tego sprawy. Ceny różnią się znacząco między Silpo, Novus, Auchan i Metro, ale ręczne sprawdzanie czterech aplikacji zajmuje więcej czasu niż zakupy same w sobie. Na dodatek dominująca sieć dostawcza chroni swoją stronę przed agresywnym wykrywaniem botów, więc naiwne podejścia do automatyzacji koszyka psują się po jednym lub dwóch uruchomieniach. Założyciel potrzebował niezawodnego systemu, który działałby w produkcji, a nie dema, które zawiodło w momencie, gdy prawdziwy klient próbowałby go użyć.
Rozwiązanie
Zbudowałem system od podstaw jako platformę automatyzacji pełnego stosu. Panel React pozwala klientowi wpisać listę w naturalnym języku ukraińskim ("молоко 2шт, хліб, курка 1.5кг") lub wyszukiwać produkty we wszystkich czterech sklepach z zdjęciami. Gdy klient kliknie porównaj, backend wysyła równoległe zapytania do wszystkich czterech API sklepów i zwraca porównanie całkowitych kosztów koszyka posortowane od najtańszego, z rozbiciem na poszczególne pozycje.
Do składania koszyka w głównym sklepie rozwiązałem problem wykrywania botów za pomocą odwróconej architektury: zamiast serwera kontrolującego przeglądarkę, własny Chrome klienta pyta serwer o pracę za pomocą rozszerzenia Chrome. Rozszerzenie atomowo pobiera zadania z kolejki Postgres, składa koszyk wewnątrz rzeczywistej sesji przeglądarki i raportuje z powrotem. Działa to na domowym połączeniu klienta, które zachowuje się jak prawdziwy ludzki klient, ponieważ nim jest.
Zbudowałem również parser paragonów: klienci wklejają URL ukraińskiego paragonu fiskalnego, a system wyodrębnia każdą pozycję (w tym towary ważone i zniżki) i przekształca ją w wielokrotnego użytku szablon dla powtarzających się zamówień.
Stos technologiczny: NestJS, TypeScript, React, Vite, Tailwind, Supabase (PostgreSQL), Redis, BullMQ, Playwright, rozszerzenie Automa Chrome, Docker, Fuse.js, bot grammY Telegram
Wyniki
- 62% oszczędności w koszyku wykryto w testach na żywo: koszyk 5 pozycji wyceniony na 301 UAH w zwycięskim sklepie w porównaniu do 787 UAH w domyślnym sklepie
- 4 sklepy wycenione równolegle w jednym zapytaniu porównawczym, a nie sekwencyjnie
- Automatyzacja koszyka na poziomie produkcji, która przetrwa agresywne wykrywanie botów, gdzie standardowe narzędzia przeglądarki po stronie serwera zawodzą w ciągu 1 do 2 uruchomień
- 31 punktów końcowych REST, 7 tabel bazy danych z zabezpieczeniami na poziomie wiersza, 37 testów zaliczonych
- Działający proces end-to-end: tworzenie listy, porównanie 4 sklepów, automatyczne składanie koszyka, parsowanie paragonu na listę, śledzenie cyklu życia zamówienia
Jak to działa
1. Klient wpisuje lub importuje listę zakupów w panelu
2. System wysyła równoległe zapytania cenowe do wszystkich 4 API sklepów
3. Panel pokazuje całkowite koszty koszyka posortowane od najtańszego z szczegółami dla każdej pozycji
4. Klient wybiera zwycięski sklep i klika zbuduj koszyk
5. Rozszerzenie Chrome przyjmuje zadanie i składa koszyk w przeglądarce klienta
6. Klient przegląda koszyk, wybiera termin dostawy i finalizuje zakupy
-
Zautomatyzowana Platforma Handlowa: Lata Walidacji Strategii w Godzinę
AI i uczenie maszynowe
Zautomatyzowana Platforma Handlowa: Lata Walidacji Strategii w Godzinach
Sytuacja
Klient jest aktywnym detalicznym traderem z siedzibą w USA, zarządzającym osobistym kapitałem na rynkach kryptowalut i akcji. Technicznie zaawansowany, komfortowy z API i backtestami, ale ograniczony przez fundamentalny problem, z którym boryka się każdy detaliczny quant: brak infrastruktury do poznania, które wzorce naprawdę działają, a które tylko dobrze wyglądają wstecz.
… Problem
Backtesty kłamały. Jeden wzór pokazał współczynnik zysku z backtestu równy 2,5, ale nie wygenerował żadnych wygranych transakcji na żywo. Inny pokazał odrzucone 0,34 w backteście, ale dostarczył 3,12 na żywo. Klient tracił prawdziwe pieniądze na strategiach, które wyglądały silnie na papierze, a walidacja pojedynczego pomysłu wymagała miesięcy handlu papierowego na żywo, zanim mógł zaangażować kapitał. Ręczne skanowanie ponad 100 aktywów było niemożliwe, a cicha awaria stop-loss na starym punkcie wymiany kosztowała go już około 300 dolarów w jednym incydencie.
Rozwiązanie
Zbudowałem platformę klasy produkcyjnej w Node.js, która uruchamia cztery niezależne silniki równolegle. Silnik papierowy do przodu cicho testuje ponad 150 wariantów strategii na rzeczywistych danych rynkowych, przesuwając każdy sygnał kandydujący w czasie przez lata historycznych danych, aby obliczyć rzeczywiste wskaźniki wygranych, współczynniki zysku i spadki. Pipeline oceny uruchamia 12 detektorów wzorców na wykresach 4-godzinnych, potwierdza na interwałach 1-godzinnych i waży czas sesji, przepływ zleceń, profil wolumenu i dane o likwidacji. Tylko strategie, które spełniają surowe progi (ponad 50 transakcji na przód, PF powyżej 1,5, WR powyżej 55%, spadek poniżej 20%) są promowane do realizacji na żywo. Silnik na żywo kieruje transakcje do Binance Futures przez aktualne API algorytmu z wyraźną weryfikacją zleceń, automatycznie ustawia skalowane zyski i stop-lossy oraz uruchamia osobny monitor wyjścia, który zamyka pozycje w stosunku do szerszego trendu rynkowego.
Dla akcji, 128 tickerów jest skanowanych po zamknięciu NYSE przez równoległą bibliotekę detektorów. Tracker PnL do przodu wypełnia każdy sygnał na otwarciu następnego dnia i prowadzi go do rozwiązania, co pozwoliło platformie zidentyfikować, że 9 z 12 detektorów nie ma rzeczywistej przewagi na akcjach, podczas gdy 3 mają.
Stos technologiczny: Node.js, Supabase, PostgreSQL, Docker, Binance Futures API, Telegram Bot API, REST APIs, orkiestracja oparta na cron
Wyniki
- Ponad 150 strategii testowanych równolegle na podstawie lat danych historycznych, zastępując miesiące sekwencyjnego handlu papierowego na żywo
- 174% poprawy PnL na silniku na żywo po systematycznym odkryciu bramek sesyjnych przez backtesting
- 3 z 12 detektorów akcji statystycznie zwalidowanych (pozostałe 9 zostało wyeliminowanych, zanim mogły stracić pieniądze na żywo)
- 441 zautomatyzowanych testów w detektorach, rozmiarze, symulacji walk-forward i renderowaniu wykresów
- Systematycznie wychwycony błąd przewidywania: jeden klaster strategii spadł z PF 3,43 do PF 0,11 po naprawieniu błędu oceny papierowej, zapobiegając wdrożeniu na żywo przegrywającego systemu
- Zero cichych awarii zleceń po migracji API algorytmu i wdrożeniu warstwy weryfikacji
Jak to działa
1. Godzinny zadanie cron pobiera dane OHLCV dla 100 najlepszych par kryptowalutowych do Supabase
2. 12 detektorów wzorców skanuje słupki 4-godzinne i ocenia każdy układ pod kątem czasu, przepływu zleceń i konfluencji
3. Kwalifikowane układy są zapisywane jako strefy oczekujące z 72-godzinnym okresem ważności
4. Silnik papierowy przesuwa wszystkie układy do przodu na podstawie rzeczywistych słupków w 150+ wariantach strategii
5. Strategie, które przechodzą 50+ transakcji z spełnionymi progami, stają się kandydatami do promocji na żywo
6. Silnik na żywo wykonuje transakcje tylko podczas sesji londyńskiej i nowojorskiej, z częściowymi TP, pełnym SL i osobnym monitorem wyjścia opartym na trendzie
-
Zautomatyzowane badanie aukcji aktów podatkowych FL: Godziny pracy, zero kliknięć
AI i uczenie maszynowe
Zautomatyzowane badanie aukcji aktów podatkowych w Florydzie: Godziny pracy, zero kliknięć
Sytuacja
Aukcje aktów podatkowych na Florydzie wymieniają dziesiątki do setek nieruchomości na dzień aukcji w różnych hrabstwach. Poważny licytator musi zweryfikować każdą działkę przed aukcją: powierzchnia, strefowanie, ryzyko powodzi, dostęp drogowy, wartość oszacowana, widok z lotu ptaka. Badania odbywają się na sześciu różnych portalach rzeczoznawców majątkowych hrabstw, mapach powodziowych FEMA, satelitarnych mapach Google, Street View oraz usługach granic działek, takich jak id.land. Każde hrabstwo ma swoje własne dziwaczne SPA. Każdy punkt danych znajduje się w innej zakładce.
… Problem
Ręczne badania w dniu aukcji trwają od czterech do sześciu godzin dla listy jednego hrabstwa. Pomnóż przez sześć hrabstw, a matematyka się nie zgadza: licytatorzy pomijają działki, przegapiają sygnały ryzyka powodziowego lub licytują w ciemno. Monotonia jest prawdziwym kosztem. Doświadczony inwestor powinien filtrować i analizować, a nie kopiować i wklejać identyfikatory działek do sześciu różnych formularzy.
Docelowy operator jest wystarczająco zaawansowany, aby samodzielnie hostować i chce mieć pełną kontrolę nad swoimi danymi, kluczami API i infrastrukturą do skrobania. Brak uzależnienia od SaaS, brak opłat za stanowisko, brak wysyłania własnej logiki inwestycyjnej do dostawcy.
Rozwiązanie
Zbudowałem samodzielnie hostowaną platformę inteligencji, która przekształca godziny ręcznych badań na portalach hrabstw w nocny proces. Operator uruchamia jeden proces, odchodzi i budzi się z filtrowalną krótką listą działek aukcyjnych uporządkowanych według werdyktu AI.
Jak działa proces (7 etapów, zdarzeniowy):
1. Zbieranie ogłoszeń z realtaxdeed.com za pomocą VPN Surfshark (strona blokuje adresy IP spoza USA i nieprzeglądarkowe agenty użytkownika). Obsługuje wieloetapowe logowanie z maksymalnie 5 sekwencyjnymi stronami powiadomień, paginuje przez wszystkie przedmioty aukcyjne.
2. Zbieranie danych o nieruchomościach z portalu rzeczoznawcy każdego hrabstwa. Hrabstwo Putnam wymagało podziału identyfikatorów działek, takich jak 01-10-26-0250-0270-0081, na 6 oddzielnych pól formularza w SPA.
3. Rozwiązywanie współrzędnych GPS za pomocą id.land, odrzucając modale i nawigując przez rozwijane menu stanów/hrabstw/działek.
4. Zbieranie zrzutów ekranu: satelitarne mapy Google, Street View, granice działek id.land, strefa powodziowa FEMA.
5. Sprawdzanie strefy powodziowej FEMA za pomocą nieudokumentowanego parametru URL ArcGIS &extent= (zastąpiło to kruchy proces automatyzacji wyszukiwania UI).
6. Przeprowadzanie analizy AI za pomocą Claude Sonnet 4 z tool_use dla strukturalnego wyniku: numeryczne podpunkty (jakość gruntu, ryzyko powodzi, dostęp drogowy, rozwój, wartość), ogólny wynik 0-100, flagi, uzasadnienie oraz werdykt kupić/przejrzeć/pominąć.
7. Zapis wyników do Supabase, na żywo przesyłane do pulpitu React za pomocą subskrypcji w czasie rzeczywistym.
Stos technologiczny: NestJS, Playwright, BullMQ, Redis, Supabase (PostgreSQL + Storage + Realtime), API Claude Sonnet 4, React, Vite, Tailwind, Leaflet, Docker Compose, Caddy, VPN Surfshark za pomocą gluetun.
Wyniki
- Godziny ręcznych badań między portalami zastąpione jednym uruchomieniem procesu
- Proces end-to-end działający dla hrabstwa Putnam: 10/10 działek zebranych, 10/10 GPS rozwiązanych, 40 zrzutów ekranu zebranych na uruchomienie
- Koszt AI skalibrowany na około 0,012 USD za działkę za pełną analizę wizji
- System konfiguracji dla 6 hrabstw pozwala nowym hrabstwom na dodawanie przez pliki konfiguracyjne oraz strategię procesora
- Samodzielnie hostowana architektura utrzymuje wszystkie dane, klucze API i infrastrukturę do skrobania pod kontrolą operatora
- Pulpit na żywo pokazuje uruchomienia procesu, szczegóły działek, stan kolejki, werdykty AI, eksport CSV, interaktywną mapę
Jak to działa (widok operatora)
1. Operator klika "Uruchom proces" na pulpicie (lub wysyła POST do API)
2. System zbiera stronę ogłoszeń aukcyjnych, tworzy rekord działki dla każdego przedmiotu
3. Każda działka przechodzi przez wszystkie 7 etapów automatycznie
4. Pulpit aktualizuje się na żywo, gdy działki kończą każdy etap
5. Gdy analiza AI się kończy, operator widzi uporządkowaną, filtrowalną listę z werdyktami
6. Eksport do CSV lub szczegółowe przeglądanie działki ze wszystkimi zrzutami ekranu obok siebie
-
3M+ Zarejestrowane Akty Przeniesienia Własności: Badanie Nieruchomości z Dni do Minut
AI i uczenie maszynowe
Sytuacja
Założyciel firmy technologicznej z USA budował platformę do badań nieruchomości dla prawników zajmujących się nieruchomościami: prawników, którzy poszukują niedoszacowanych działek jako możliwości inwestycyjnych dla swoich klientów. Ich praca zależy od znalezienia specyficznego języka ukrytego w aktach własności, takiego jak służebności, ograniczenia, prawa dostępu i klauzule graniczne.
Przed tym projektem, znalezienie odpowiednich działek oznaczało ręczne przeszukiwanie DataTree i baz danych hrabstw, czytanie poszczególnych plików PDF aktów własności oraz porównywanie z mapami podatkowymi, danymi o strefowaniu i demografią w oddzielnych zakładkach. Jedno kwalifikowane prowadzenie mogło zająć dni. Niektóre pytania nie mogły być w ogóle odpowiedziane.
…
Problem
Prawnicy tracili transakcje, ponieważ koszt badań był zbyt wysoki. Każda nieruchomość musiała być ręcznie sprawdzana pod kątem kryteriów słów kluczowych, a następnie wzbogacana o dane geograficzne i rekordy infrastruktury z czterech różnych źródeł. Założyciel próbował ręcznych obejść i gotowych narzędzi. Nic nie łączyło źródeł. Nic nie filtrowało według specyficznego języka prawnego, którego jego klienci potrzebowali, aby znaleźć.
Pytanie nie brzmiało "czy możemy to przyspieszyć?" Brzmiało "czy możemy uczynić pytania, które wcześniej nie miały odpowiedzi, możliwymi do odpowiedzenia?"
Rozwiązanie
Zbudowałem kompleksową platformę inteligencji nieruchomości z dwoma warstwami.
Frontend to aplikacja SPA w React wdrożona na Vercel, gdzie prawnicy wyszukują, filtrują i przeglądają nieruchomości. Każdy wynik otwiera widok szczegółowy z historią aktów, ograniczeniami wielkości działek, mapami podatkowymi, infrastrukturą i demografią hrabstwa, wszystko renderowane dynamicznie z backendu Supabase z zabezpieczeniem na poziomie wiersza.
Backend to n8n jako API. Zamiast uruchamiać n8n jako "klej automatyzacyjny", użyłem go jako warstwy API produkcyjnego dla pipeline'u przetwarzania aktów. Gdy prawnik uruchamia wyszukiwanie słów kluczowych, żądanie kierowane jest przez funkcję brzegową Supabase do webhooków n8n. Pipeline pobiera akty własności z DataTree, filtruje według słów kluczowych prawnych, wzbogaca dopasowania o dane geograficzne Zonomics, przeprowadza analizę AI za pomocą Claude (OpenRouter) i zapisuje postęp z powrotem do Supabase w czasie rzeczywistym. Prawnicy widzą postęp w miarę dopasowywania i wzbogacania rekordów.
Ta architektura dała założycielowi backend, który jest w pełni kontrolowalny, łatwy do modyfikacji i szybki do rozszerzenia: nowe źródła danych lub kroki analizy są dostarczane w ciągu godzin, a nie sprintów. Aby wspierać tę prędkość, zbudowałem niestandardowy zestaw narzędzi Claude Code, który zarządza przepływami pracy n8n programowo (tworzenie, synchronizacja i debugowanie ich z specyfikacji w języku naturalnym).
Stos technologiczny: n8n, Supabase (PostgreSQL, Auth, Storage, Edge Functions), React 19, TypeScript, Vite, Vercel, DataTree API, Zonomics API, Claude API (przez OpenRouter), OpenAI API, Google Maps Embed API, Node.js, Zod, Anthropic SDK
Wyniki
- 3M+ rekordów aktów przetworzonych przez pipeline
- Dni do minut na każde kwalifikowane zapytanie badawcze
- Pytania teraz możliwe do odpowiedzenia, które wcześniej nie były (zapytania z wielu źródeł, które były ekonomicznie nieopłacalne ręcznie)
- System produkcyjny aktywnie używany przez zespół założyciela, obsługujący klientów prawnych
- Backend w pełni kontrolowalny: nowe źródła danych, słowa kluczowe i kroki analizy AI są dostarczane bez przebudowy
- Zaprojektowany dla microSaaS: system jest już przygotowywany do zewnętrznego dostępu przez ograniczony zestaw prawników
Jak to działa
1. Prawnik wprowadza kryteria słów kluczowych (język prawny, którego potrzebują w aktach) i zakres geograficzny
2. Żądanie kierowane jest przez funkcję brzegową Supabase do webhooka n8n
3. Pipeline n8n pobiera pasujące rekordy aktów z DataTree
4. Dopasowania wzbogacane są o dane geograficzne Zonomics, mapy podatkowe, infrastrukturę, demografię
5. Claude analizuje każdy akt pod kątem istotności; wyniki są oceniane i sortowane
6. Prawnik pobiera tylko te akty, które spełniają wszystkie jego kryteria za pomocą podpisanych adresów URL Supabase
-
30 agentów AI, 5 platform, jeden pulpit: autonomiczny system treści
AI i uczenie maszynowe
Sytuacja
Samodzielny strateg treści zarządzał publikowaniem w wielu kanałach: blog, LinkedIn, Dev.to, Hashnode i Telegram. Każdy artykuł wymagał ręcznych badań, pisania, przeglądu jakości, dostosowania do specyfikacji platformy oraz indywidualnej publikacji przez interfejs użytkownika każdej platformy. Jedna treść zajmowała 4-6 godzin przed opublikowaniem na wszystkich kanałach.
Problem
… Każda platforma miała różne wymagania dotyczące formatu: WordPress potrzebował HTML z niestandardowymi typami postów, Dev.to używał markdown z front matter, Hashnode wymagał GraphQL, LinkedIn usuwał markdown i narzucał limit 2,900 znaków, Telegram używał własnego podzbioru HTML. Dostosowanie jednego artykułu do pięciu platform było żmudne i podatne na błędy.
Nie istniał żaden cykl informacji zwrotnej. Analityka znajdowała się w pięciu oddzielnych pulpitach. Decyzje strategiczne opierały się na intuicji. Jakość była niespójna. Każdy krok zależał od dostępności klienta do ręcznego wykonania.
Rozwiązanie
Zbudowałem autonomiczny system treści z 30 wyspecjalizowanymi agentami AI zorganizowanymi przez łańcuchy zadań BullMQ. Cały cykl życia treści działa autonomicznie: odkrywanie trendów → badania → pisanie → weryfikacja faktów → wykrywanie AI → optymalizacja neuromarketingowa → dostosowanie do platformy → zatwierdzenie → publikacja.
Architektura pipeline'u. Każdy element treści przechodzi przez konfigurowalną sekwencję agentów. Czterostopniowa brama jakości (weryfikator faktów → wykrywacz AI → neuro-optymalizator → recenzent) waliduje każdy szkic. Pipeline zatrzymuje się na bramach zatwierdzających i powiadamia za pomocą klawiatur inline Telegramu lub pulpitu React.
Dynamiczne pipeline'y. Sekwencje agentów są konfigurowalne dla każdego kanału lub elementu treści za pomocą interfejsu drag-and-drop. Trzy poziomy priorytetu: nadpisania elementu → domyślne kanału → domyślne systemu. Wspierane jest równoległe wykonywanie agentów.
Publikowanie na wielu platformach. Limit znaków LinkedIn jest egzekwowany na trzech poziomach: podpowiedź adaptera, walidacja wyjścia i pętla przepisania na poziomie wydawcy (ponownie wywołuje AI, aby skrócić, do 3 prób). WordPress publikuje jako niestandardowe typy postów z sformatowanym HTML. Wszystkie pięć wydawców działa z jednego działania.
Cykl informacji zwrotnej analityki. Cotygodniowy pipeline zbiera metryki, generuje hipotezy dotyczące tego, co działa, i automatycznie uruchamia odświeżenie strategii.
Stos technologiczny: Node.js, TypeScript, Express.js, BullMQ, Redis, PostgreSQL (Supabase), React 18, Vite, Tailwind CSS, Grammy (Telegram Bot), Anthropic Claude API, Google Gemini, OpenAI Whisper, Tavily API, Docker, Vitest, Playwright
Wyniki
- ~85% redukcji czasu na artykuł (4-6 godzin → ~30 minut nadzoru)
- Publikowanie na 5 platformach jednocześnie z jednego zatwierdzenia
- 30 agentów AI z konfigurowalnymi pipeline'ami i pełnym śledzeniem kosztów
- Czterostopniowa brama jakości dla spójnej jakości treści
- Podwójny interfejs zatwierdzania (pulpit React + bot Telegram)
- Cykl informacji zwrotnej analityki, który automatycznie dostosowuje strategię treści
- 606 zautomatyzowanych testów (jednostkowe, integracyjne, E2E)
Jak to działa
1. Odkrywanie. Zadania cron uruchamiają odkrywanie trendów i analizę konkurencji
2. Tworzenie. Agenci badań i pisarze produkują treści długoterminowe
3. Brama jakości. Weryfikator faktów, wykrywacz AI, neuro-optymalizator, recenzent walidują szkic
4. Dostosowanie. Adaptery platformy przekształcają format zgodnie z wymaganiami każdego kanału
5. Zatwierdzenie. Klient przegląda przez pulpit lub Telegram, zatwierdza lub odrzuca
6. Publikacja. Wydawcy publikują na wszystkich wybranych platformach jednocześnie
Pipeline jest w pełni wznowialny. Powtarza z wykładniczym opóźnieniem, kontynuuje tam, gdzie przerwał.
-
37 000 rekordów przeniesionych na 3 platformy w 2 tygodnie — zero danych
Zarządzanie klientami i CRM
Pełna migracja danych CRM dla biura ubezpieczeń Medicare: RadiusBob → GoHighLevel + HealthSherpa
---
Sytuacja
Biuro ubezpieczeń Medicare z ~1,600 klientami prowadziło działalność w trzech odłączonych systemach: RadiusBob (stare CRM), GoHighLevel (nowe CRM) i HealthSherpa Medicare (platforma rejestracyjna). Agenci codziennie ręcznie porównywali wszystkie trzy systemy — brak jednego źródła prawdy, brak możliwości automatyzacji.
…
Problem
Lata historii klientów znajdowały się w RadiusBob: 1,593 kontakty, 1,222 polisy ubezpieczeniowe, 32,507 notatek interakcji i 793 relacje między kontaktami. To nie był eksport CSV — to była pełna rekonstrukcja przez trzy API z różnymi autoryzacjami, limitami prędkości i formatami danych.
Każdy utracony rekord oznaczał ryzyko zgodności. Ręczna migracja zajęłaby miesiące i wprowadziłaby błędy na każdym etapie.
Rozwiązanie
Zbudowałem wznowialny pipeline migracyjny w Pythonie (Docker + Supabase jako śledzenie stanu synchronizacji). Status każdego rekordu był śledzony indywidualnie — jeśli proces zatrzymał się na rekordzie 500, wznowił się na 501 bez duplikacji.
Usuwanie duplikatów kontaktów: GoHighLevel wymusza unikalne numery telefonów/adresy e-mail, ale RadiusBob pozwalał na współdzielone numery (małżeństwa). Pipeline wychwytywał duplikaty z odpowiedzi błędów API, aktualizował istniejące rekordy i generował raport (163 grupy duplikatów) do przeglądu przez klienta.
Dopasowanie HealthSherpa: Strategia trzech przejść — najpierw według ID beneficjenta Medicare (najwyższa pewność), następnie według imienia + daty urodzenia/adresu e-mail/telefonu, a następnie tworzenie nowych rekordów dla niedopasowanych kontaktów. Każde dopasowanie zapisywało bezpośredni URL rejestracji do jednego kliknięcia z GHL.
Rekordy polis: Schemat obiektu niestandardowego w GHL z 15 polami. Odkryto i obsłużono nieudokumentowane dziwactwa API poprzez systematyczne testowanie.
32,507 notatek: Równoległe przetwarzanie z 8 równoczesnymi żądaniami API skróciło czas importu z ponad 9 godzin do około 1 godziny, pozostając w ramach limitów prędkości.
793 relacje: Zmapowano 10 typów relacji obsługujących zarówno relacje dwukierunkowe (małżonek), jak i jednokierunkowe (rodzic-dziecko). 260 niezmapowanych typów udokumentowano do przeglądu przez klienta.
Stos technologiczny: Python 3.11, Docker, Supabase (PostgreSQL), API GoHighLevel, API HealthSherpa Medicare, asyncio
Wyniki
- ~37,000 łącznych rekordów przeniesionych na 3 platformy
- 100% kontaktów zaimportowanych (1,593/1,593)
- 100% notatek zachowanych (32,507/32,507)
- 99.3% polis zaimportowanych (1,214/1,222)
- 8x szybszy import notatek dzięki równoległemu przetwarzaniu
- Zero utraty danych — każdy importowalny rekord przeniesiony z pełną historią
- 2-tygodniowa dostawa od rozpoczęcia do zakończenia
- Linki do rejestracji Medicare w jednym kliknięciu na każdym rekordzie klienta
Jak to działa
1. Ekstrakcja — Pobierz wszystkie dane z API RadiusBob
2. Transformacja — Normalizuj formaty, oczyść dane, zweryfikuj pola, usuń duplikaty
3. Ładowanie — Prześlij kontakty do GHL, dopasuj do HealthSherpa za pomocą strategii 3-przejść
4. Łączenie — Utwórz rekordy polis, dołącz notatki, zbuduj powiązania relacyjne
5. Weryfikacja — Zgody na liczenie, raport duplikatów, audyt ścieżki walidacji
Każdy krok jest idempotentny i wznowialny. Pipeline może być uruchamiany ponownie bez duplikatów lub utraty postępu.
-
Automatyzacja CRM - Automatyzacja zbierania faktur - ClickUp
Zarządzanie klientami i CRM
Amerykańska firma świadcząca usługi budowlane zarządzała ponad 5 000 faktur za pomocą Service Fusion — platformy legacy z ograniczoną możliwością dostosowania i bez wbudowanego procesu windykacji.
PROBLEM
Księgowy spędzał około 60 godzin miesięcznie na pracy ręcznej: przenoszeniu danych faktur między systemami, śledzeniu terminów płatności z pamięci, komponowaniu indywidualnych e-maili przypominających. Każdy e-mail zajmował 15 minut — zbieranie informacji z wielu ekranów, porównywanie szczegółów zlecenia, ręczne formatowanie wiadomości. Krytyczne ograniczenie: Service Fusion przechowuje faktury i klientów w oddzielnych tabelach bez bezpośredniego połączenia. Pracownicy śledzili powiązania przez tabelę Zleceń, co niemal uniemożliwiało systematyczne śledzenie.
…
ROZWIĄZANIE
Trzy automatyzacje współpracujące ze sobą, zachowujące Service Fusion jako źródło prawdy:
• Zjednoczone Śledzenie: Szacunki + faktury automatycznie trafiają do Smartsheet
• System Windykacji: 7 szablonów e-mailowych według etapu płatności (-2 dni, dzień 1, 7, 14, 31+). Jedno kliknięcie wysyła spersonalizowane przypomnienie z nazwą zlecenia, adresem, identyfikatorem faktury, kwotą
• Auto-Synchronizacja: Aktualizacje co 30 minut. Opłacone faktury automatycznie zamykają powiązane zadania w ClickUp
WYNIKI
• 60 godzin/miesiąc uwolnionych od pracy ręcznej
• Czas przypomnienia: 15 min → 1 kliknięcie
• Pierwsza w historii możliwość śledzenia wskaźnika windykacji
• Obsługuje ponad 5 000 faktur bez dodatkowego zatrudnienia
Harmonogram: 2,5 tygodnia (rozwój + testowanie)
-
n8n Automatyzacja dla ocen pracy RSS
Zarządzanie klientami i CRM
Jako programista full stack stworzyłem system automatyzacji przy użyciu n8n, który działa co 5 minut, aby przetwarzać nowe oferty pracy. Workflow ocenia każdą ofertę pracy za pomocą 10-punktowego systemu punktacji opartego na dopasowanych słowach kluczowych i umiejętnościach. Wybrane oferty są automatycznie wysyłane do kanału Discord i dodawane do bazy danych Notion. Tagami zarządza się i aktualizuje za pomocą żądań HTTP w celu dokładnego śledzenia. Jako programista front-end, programista react i programista webowy zaprojektowałem wydajne i skalowalne rozwiązanie, w pełni wykorzystując możliwości automatyzacji n8n, aby uprościć proces.
-
n8n Automatyzacja: Synchronizuj zadania Worksection z transakcjami HubSpot
Zarządzanie klientami i CRM
Jako deweloper automatyzacji n8n, stworzyłem tę zautomatyzowaną integrację przy użyciu n8n, aby połączyć Worksection i HubSpot. Przepływ pracy uruchamia się przy nowych zadaniach w Worksection, przetwarza dane dotyczące transakcji i automatycznie tworzy nowe transakcje w HubSpot. Synchronizuje również dane kontaktowe, aktualizuje zadania i zapewnia, że oba systemy pozostają zsynchronizowane w czasie rzeczywistym. To rozwiązanie eliminuje ręczne wprowadzanie danych, redukuje błędy i oszczędza czas zespołu sprzedażowego. Projekt pokazuje moje doświadczenie w automatyzacji API, przepływach pracy n8n i złożonych integracjach.
-
n8n Automatyzacja dla Inteligentnego Sortowania E-maili i Przepływu Pracy w Biznesie
Zarządzanie klientami i CRM
Jako ekspert w automatyzacji n8n, opracowałem inteligentny system przetwarzania e-maili dla Gmaila. Automatyzacja wykorzystuje model AI do klasyfikacji przychodzących e-maili w kategorie (komercyjne, detaliczne, społeczne, ważne, inne), stosuje etykiety, usuwa e-maile o niskim priorytecie z skrzynki odbiorczej i rejestruje działania w Google Sheets do raportowania. To rozwiązanie pomaga firmom zaoszczędzić czas i skuteczniej zarządzać komunikacją. Z moim doświadczeniem jako programista full stack, programista front-end, programista react i programista webowy, dostarczam niezawodne i skalowalne automatyzacje oparte na n8n dostosowane do potrzeb biznesowych.
Aktywność
| Ostatnie oferty 2 | Budżet | Dodana | Terminy | Oferta | |
|---|---|---|---|---|---|
|
Wersja strony
164 PLN
|
|||||
|
адаптивная верстка сайта
410 PLN
|
