Andrey Boyko
Offer Andrey work on your next project.
Private message 
Offer work 
Kharkiv,
Ukraine
20 days 16 hours back
available for hire
on the service 9 years
Rating
Successful projects
Average rating
Language proficiency level
English: advanced
Українська: upper-intermediate
Skills and abilities
Programming
Outsourcing & consulting
Portfolio
-
Persistent Vector Memory for Claude Code: Open-Source MCP Server
AI & Machine Learning
The Situation
Claude Code is a powerful AI coding assistant, but it is stateless by design. Every new session starts without knowledge of past decisions, bugs, or architecture. In real production work, this leads to constant repetition, lost context, and slower development.
The Problem
… The fundamental issue: the AI assistant helping build a project has no memory of building it. I was rediscovering the same bugs, re-explaining the same architecture, and losing decisions made last week. A secondary problem: recurring patterns across projects (like "we have set up Supabase this exact way 4 times") stayed buried in session memories instead of becoming reusable, documented skills.
The Solution
I built memory-mcp, an open-source MCP server that gives Claude Code long-term semantic memory. It exposes 8 tools: 4 core memory tools (remember, recall, forget, project_status) and 4 skill-pattern tools that track recurring work patterns and surface candidates for formalization once seen 3+ times.
Memories store as 1536-dimension vector embeddings (OpenAI text-embedding-3-small) in Supabase PostgreSQL with pgvector. Retrieval runs a cosine-similarity search via a Postgres RPC function with SQL-level filtering (threshold, project, type, date, expiration) in a single round trip. Recall responses are token-capped at ~2000 tokens to protect Claude's context window.
The server runs as a stateless Docker container on port 3101 via Express + Streamable HTTP transport, so multiple Claude Code sessions share one always-on instance. A stdio transport mode is also available for direct native-binary integration. Memories never hard-delete: forget is a soft-delete via expires_at, and every query filters on active-memory status.
Tech Stack: Node.js 20, TypeScript 5 (strict), Express 5, @ modelcontextprotocol/sdk, OpenAI API (text-embedding-3-small), Supabase PostgreSQL, pgvector, IVFFlat indexes, Zod validation, Vitest, Docker Compose.
The Results
- 8 MCP tools shipped and end-to-end tested over HTTP
- 125 unit tests with Supabase and OpenAI clients fully mocked
- ~2,600 lines of TypeScript across 16 source files, 11 commits over 11 days
- 2 tables, 3 RPC functions with SQL-level filtering before LIMIT for correctness
- Production-running as an always-on Docker service, used daily with real Claude Code sessions
- Published open-source on GitHub with full setup documentation, Docker Compose, and troubleshooting guide covering 4 documented failure modes
Key Engineering Decisions
1. Empirical similarity thresholds. text-embedding-3-small produces lower cosine scores than docs suggest (near-identical text scores 0.78–0.84). I lowered recall threshold to 0.25 and dedup to 0.75 based on real measurements, documented the rule for future features.
2. SQL-level date filtering. The since_days filter originally ran client-side after LIMIT, which silently missed recent memories ranked below the top N. Moving it into the WHERE clause before LIMIT guarantees correctness regardless of data volume.
3. Tool descriptions as executable instructions. Tool descriptions were rewritten from "what they do" to "when to call them" (e.g., "Call before starting non-trivial work"), so tools work correctly without requiring a maintained CLAUDE.md.
4. OAuth workaround for native Claude Code binary. The binary blocks HTTP MCP connections until OAuth discovery completes. Adding a static Bearer token to the MCP config skips discovery entirely (the token is arbitrary and never validated server-side).
Available On GitHub
Full source, setup instructions, and architecture docs published for developers who want to replicate or extend the system.
-
AI Sales Agent Across Voice, Chat, Telegram, WhatsApp (One Pipeline)
AI & Machine Learning
The Situation
A B2B sales agency ran high-volume lead qualification for its own clients. Prospects reached out through 4 channels: the website widget, phone calls, Telegram, and WhatsApp. The agency wanted to automate first-touch conversations across all of them without hiring more SDRs.
The Problem
… Most sales automation tools are channel-specific. A chatbot for the website. A separate Telegram bot. A different vendor for voice. Each tool has its own lead records, its own scripts, no shared intelligence. When the same prospect reached out on Telegram and later called the main number, nobody connected the two interactions. Lead scores were fragmented. Knowledge base answers were inconsistent across channels. And outbound calling still required a human SDR dialing through a spreadsheet.
The agency needed one brain behind every channel, not four bolted-together tools.
The Solution
I built a unified sales platform where every message flows through the same AI agent. Voice, chat, Telegram, WhatsApp: each channel has a thin adapter that normalizes incoming messages, then hands off to a shared ChatService. That service looks up the lead, retrieves relevant knowledge via RAG (Voyage AI embeddings in pgvector), and passes conversation history to the agent, which answers questions grounded in the company's actual product docs, pricing, and FAQs. Same lead records, same knowledge base, same scoring across all 4 channels.
For outbound, operators upload a contact list, attach a voice script, and launch a campaign from the admin dashboard. BullMQ workers dial contacts through Retell AI at a rate-limited 1 call/second. Retell handles telephony and speech; my custom WebSocket endpoint feeds each call's transcript to the agent in real time. After each call, Retell webhooks deliver the transcript, call summary, and sentiment analysis back to the platform, which automatically adjusts lead scores (+10 for positive sentiment, -5 for negative).
The embeddable widget is a 53KB single-file Vite IIFE bundle that drops onto any website with one script tag, renders inside a Shadow DOM to avoid CSS conflicts, and restores chat history across page reloads via localStorage.
Tech Stack: NestJS, TypeScript, Claude API (Anthropic SDK), Retell AI, Voyage AI embeddings, OpenAI Whisper, Supabase (PostgreSQL + pgvector), BullMQ, Redis, Next.js, Vite, Docker, nginx, Cloudflare Tunnel
The Results
- 4 channels unified under 1 AI pipeline: voice calls, website chat, Telegram, WhatsApp share lead records, knowledge base, and scoring
- Outbound calling fully automated: operators configure a campaign once, the system dials, converses, transcribes, and scores every contact with no SDR involvement
- Multi-tenant ready: organizations, RBAC, and per-org knowledge bases built in, so the platform can host multiple agency clients
- Live in partner testing with 7 Docker services, signed webhook verification, and test coverage across 34 test files (unit, integration, AI behavior, E2E)
How It Works
1. Prospect reaches out on any of 4 channels (widget, phone, Telegram, WhatsApp)
2. Channel adapter normalizes the message and creates or looks up the lead
3. ChatService retrieves conversation history and runs semantic search against the company knowledge base
4. The agent generates a response grounded in retrieved documents
5. Response routes back through the same channel adapter
6. Lead score updates based on message signals or (for voice) post-call sentiment analysis
-
Calendar SOP Enforcement: 3 Calendars, Zero Manual Review
AI & Machine Learning
The Situation
A US investment fund runs on strict meeting SOPs. Mornings are protected for deep work, Mondays are internal-only, Tuesdays are external-only, Wednesday and Thursday absorb overflow with a hard cap, Fridays stay meeting-free. The team also splits time across three separate Google Calendars: Business, Fund, and Personal. Getting any of this wrong costs focus, costs deal time, and eventually costs trust with partners.
The Problem
… Enforcement was manual. Someone had to scan three calendars daily, spot a meeting booked before noon, catch two back-to-back events with no buffer, flag an external booking on an internal day. Reviews were tedious, late, and easy to miss. An earlier attempt used n8n's built-in static data to avoid repeat alerts, but that state resets on every workflow save. In practice, the same violation re-fired to Slack every 5 minutes all day. Alert fatigue set in and the team started ignoring the channel, which defeated the point.
The Solution
I built a two-tier n8n system backed by Supabase. A real-time monitor polls all three Google Calendars every 5 minutes, runs each event through an SOP audit engine (time-of-day, buffer, day-type, daily caps), and posts violations to a dedicated Slack channel. A daily audit runs at 8:30 AM ET with a full-week sweep and AI-generated rescheduling suggestions, and on Fridays it sends a second message previewing the coming week.
The deduplication layer is the piece that made this work in production. Every violation gets a stable key (rule + date + event hash). Before any Slack send, the workflow pulls the week's reported alerts from a Supabase table and set-differences against them. Only genuinely new violations reach Slack. Each morning the daily audit deletes the prior week's rows, keeping the table lean.
The entire system runs inside n8n and Supabase. No custom server, no Docker, no local code. The whole toolchain is managed through MCP servers, so workflow updates, schema changes, and deploys happen through a controlled AI-orchestrated interface with a staging-to-production safety boundary.
Tech Stack: n8n, Supabase, PostgreSQL, Google Calendar API, Slack API, OpenAI API, MCP (Model Context Protocol)
The Results
- 3 Google Calendars monitored continuously with zero manual review
- 5-minute detection from violation to Slack alert
- Zero duplicate alerts after the Supabase dedup layer replaced the fragile in-memory hash
- Daily 8:30 AM audit with AI rescheduling suggestions, plus Friday next-week preview
- Serverless architecture: no app server, no Docker, managed entirely through n8n and Supabase
- Safe deploys: production workflow changes gated behind explicit operator confirmation
How It Works
1. Scheduler fires every 5 minutes and reads sync state from Supabase
2. Events pulled from Business, Fund, and Personal Google Calendars plus the approved exceptions whitelist
3. Change detection exits early if nothing moved since the last poll
4. SOP audit engine evaluates every event against time, buffer, day-type, and cap rules
5. Dedup layer compares new violation keys against the week's reported alerts in Supabase
6. Genuinely new violations post to Slack and get written back to Supabase
-
AI-Native Control for Worksection: Claude, Cursor, ChatGPT via M
AI & Machine Learning
AI-Native Control for Worksection: Claude, Cursor, ChatGPT via MCP
The Situation
The client ran their entire operation in Worksection: tasks, projects, comments, costs, team assignments. Their team had also gone all-in on AI assistants (Claude, Cursor, ChatGPT) for daily work. But the two worlds were disconnected. The AI knew nothing about Worksection, and Worksection knew nothing about the AI.
… The Problem
Every interaction between the two tools was manual. A developer would ask Claude to draft a task description, then copy it into Worksection by hand. A PM would screenshot a project status and paste it into ChatGPT to summarize. The AI could think about the work, but it couldn't do the work. That copy-paste loop killed most of the productivity gain the client expected from AI in the first place. They needed the AI to read and write Worksection directly, with proper auth, no shared credentials, and no hand-rolled integration per team member.
The Solution
I built a production MCP (Model Context Protocol) server that sits between any MCP-compatible AI client and Worksection's API. The AI calls a named tool like post_task or get_projects, and the server handles auth, rate limiting, payload translation, and response shaping.
It ships as a multi-tenant SaaS: each team registers once, gets their own encrypted credentials and OAuth clients, and connects Claude or Cursor with a single URL. An admin panel (React + Vite) lets the operator manage tenants, rotate OAuth secrets, tune per-tenant rate limits, and see exactly which tools are being called and how often.
Three technical decisions defined the build. First, Worksection's API authenticates from the URL query string only (POST bodies are ignored by its hash validation), so every outbound call uses a two-pass encoding: raw string for MD5 hashing, re-encoded string for transport. Second, every tenant API key is encrypted at rest with AES-256-GCM; plaintext never touches the database. Third, API responses are actively compacted before returning to the AI, because raw Worksection payloads can overflow a model's context window on large projects.
Tech Stack: Node.js 20, TypeScript, Express, @ modelcontextprotocol/sdk, Supabase (PostgreSQL), OAuth2, AES-256-GCM, Zod, Winston, React, Vite, Docker, nginx, Hetzner VPS.
The Results
26 MCP tools live in production across 7 categories: tasks, projects, comments, members, costs, tags, files
Multi-tenant SaaS with OAuth2 auth, per-tenant rate limits, and encrypted credentials
Zero copy-paste between AI assistant and Worksection for daily project operations
30-day OAuth tokens tuned specifically for AI client usage patterns (no silent 401 failures mid-session)
Admin dashboard with tenant management, OAuth secret rotation, and per-tool usage analytics over 7/30/90 day windows
Production-hardened: Docker deployment, nginx reverse proxy, health endpoint with build metadata, structured logging
Active in production serving real tenants on a live VPS
How It Works
1. Tenant registers with their Worksection URL and API key; server encrypts the key and sends an OTP confirmation email
2. Tenant confirms via OTP, account activates
3. AI client (Claude, Cursor, ChatGPT) authenticates via OAuth2 and receives a 30-day bearer token
4. AI calls a tool (e.g., post_task); server validates the bearer token and resolves the tenant from cache
5. Server translates the call to a Worksection GET request with MD5-hashed auth, retries with backoff on failure
6. Compacted response returns to the AI; usage is logged to Supabase for analytics
-
AI Assistant for ServiceFusion: Query Jobs by Chat, Not Clicks
AI & Machine Learning
The Situation
A field service operator running on ServiceFusion wanted dispatchers and office staff to stop clicking through menus every time they needed to check a customer's job history, pull open estimates, or see which technician was assigned to a job. The team was already using Claude for other tasks. The obvious next step: let Claude talk directly to ServiceFusion.
The Problem
… ServiceFusion exposes a REST API, but AI assistants cannot call it directly. The Model Context Protocol (MCP) is the emerging standard for giving AI clients structured access to external tools, and no MCP server existed for ServiceFusion. Building one correctly meant solving three problems at once:
OAuth2 token lifecycle. ServiceFusion uses short-lived access tokens that expire and must be refreshed transparently, so the AI never hits an auth failure mid-conversation.
Multi-tenancy. A single server instance had to isolate credentials and API calls for multiple companies, each with their own ServiceFusion account.
Self-service onboarding. The operator did not want to configure every new tenant manually.
The Solution
I built a multi-tenant MCP server in Node.js and TypeScript that sits between AI clients (Claude, Cursor, ChatGPT) and ServiceFusion. It exposes 13 structured tools covering the core entities dispatchers actually use: customers, jobs, estimates, technicians, and equipment.
The server handles two independent OAuth2 layers. One authenticates incoming AI clients to the MCP server. The second manages the server's own ServiceFusion tokens, including automatic refresh with a concurrency lock so simultaneous requests never trigger duplicate refreshes.
All sensitive credentials (client IDs, secrets, tokens) are encrypted at rest with AES-256-GCM in Supabase PostgreSQL. New tenants self-register via REST API, confirm via OTP, and supply their ServiceFusion credentials to activate. No manual operator work per signup.
A lightweight admin panel lets the operator view usage per tenant, adjust rate limits, and activate or deactivate accounts.
Tech Stack: Node.js 20, TypeScript, @ modelcontextprotocol/sdk, Express, Supabase (PostgreSQL), AES-256-GCM encryption, Zod, Winston, Docker, nginx, Let's Encrypt
The Results
13 MCP tools live across customers, jobs, estimates, technicians, and equipment
Zero manual setup per tenant. Self-service OTP registration and activation flow
Transparent OAuth2. Expired tokens refresh automatically with race-condition protection
Per-tenant rate limits (free, pro, enterprise tiers) enforced at the request layer
Full usage tracking (tool name, endpoint, status code, response time) logged per tenant for billing and analytics
Deployed to production on Hetzner VPS behind nginx with SSL, coexisting with a sibling MCP server on the same host
How It Works
1. Tenant POSTs to /api/register with company name and email, receives a 6-digit OTP
2. Tenant confirms via /api/confirm, then activates by supplying ServiceFusion OAuth credentials
3. Credentials are encrypted with AES-256-GCM and stored in Supabase
4. AI client (Claude, Cursor) calls /mcp with a bearer token; middleware identifies the tenant and checks rate limit
5. On tool invocation, the server checks token validity and refreshes automatically if expired
6. Structured response flows back to the AI client, and the call is logged for usage analytics
-
Grocery Price Intelligence: 60%+ Basket Savings Across 4 Stores
AI & Machine Learning
Grocery Price Intelligence: 60%+ Basket Savings Across 4 Stores
The Situation
A Ukrainian consumer tech founder wanted to give shoppers something no local app offered: a single view of their full grocery basket priced simultaneously across the four biggest delivery-capable chains in the country. The end goal was simple. A shopper types a weekly list, sees which store is cheapest for that exact basket, and builds the winning cart in one click.
… The Problem
Ukrainian grocery shoppers typically default to one chain out of habit and overpay without knowing it. Prices vary meaningfully between Silpo, Novus, Auchan, and Metro, but checking four apps manually takes longer than the shopping itself. On top of that, the dominant delivery chain protects its site with aggressive bot detection, so naive cart-automation approaches break within one or two runs. The founder needed a reliable system that worked in production, not a demo that failed the moment a real shopper tried to use it.
The Solution
I built the system end-to-end as a full-stack automation platform. The React dashboard lets the shopper type a list in natural Ukrainian ("milk 2pcs, bread, chicken 1.5kg") or search products across all four stores with photos. When the shopper hits compare, the backend fires parallel requests to all four store APIs and returns a basket-total comparison sorted cheapest-first, with per-item breakdowns.
For cart assembly at the primary store, I solved the bot-detection problem with an inverted architecture: instead of a server controlling a browser, the shopper's own Chrome polls the server for work via a Chrome extension. The extension claims jobs atomically from a Postgres queue, assembles the cart inside the real browser session, and reports back. This runs on the shopper's residential connection, which behaves like a genuine human shopper because it is one.
I also built a receipt parser: shoppers paste a Ukrainian fiscal receipt URL, and the system extracts every line item (including weighted goods and discounts) and turns it into a reusable template for repeat orders.
Tech Stack: NestJS, TypeScript, React, Vite, Tailwind, Supabase (PostgreSQL), Redis, BullMQ, Playwright, Automa Chrome extension, Docker, Fuse.js, grammY Telegram bot
The Results
- 62% basket savings detected in live testing: a 5-item basket priced at 301 UAH at the winning store vs 787 UAH at the default store
- 4 stores priced in parallel in a single comparison request, not sequentially
- Production-grade cart automation that survives aggressive bot-detection where standard server-side browser tools fail within 1 to 2 runs
- 31 REST endpoints, 7 database tables with row-level security, 37 passing tests
- End-to-end flow working: list creation, 4-store comparison, automated cart assembly, receipt-to-list parsing, order lifecycle tracking
How It Works
1. Shopper types or imports a shopping list in the dashboard
2. System fires parallel price queries to all 4 store APIs
3. Dashboard shows basket totals sorted cheapest-first with per-item detail
4. Shopper picks the winning store and clicks build cart
5. Chrome extension claims the job and assembles the cart in the shopper's own browser
6. Shopper reviews the cart, picks a delivery slot, and checks out
-
Automated Trading Platform: Years of Strategy Validation in Hour
AI & Machine Learning
Automated Trading Platform: Years of Strategy Validation in Hours
The Situation
The client is a US-based active retail trader managing personal capital across crypto and equity markets. Technically sophisticated, comfortable with APIs and backtests, but constrained by a fundamental problem every retail quant faces: no infrastructure to know which patterns actually work versus which only look good in hindsight.
… The Problem
Backtests were lying. One pattern showed a backtest profit factor of 2.5 but produced zero winning trades live. Another showed a rejected 0.34 in backtest but delivered 3.12 live. The client was losing real money on strategies that looked strong on paper, and validating a single idea required months of live paper trading before he could commit capital. Manual scanning across 100+ assets was impossible, and a silent stop-loss failure on a legacy exchange endpoint had already cost him roughly $300 in a single incident.
The Solution
I built a production-grade Node.js platform that runs four independent engines in parallel. A forward paper engine silently tests 150+ strategy variants against real market data, walking each candidate signal forward across years of historical bars to compute real win rates, profit factors, and drawdown. A scoring pipeline runs 12 pattern detectors on 4-hour charts, confirms on 1-hour timeframes, and weighs session timing, order flow, volume profile, and liquidation data. Only strategies that clear strict thresholds (50+ forward trades, PF above 1.5, WR above 55%, drawdown under 20%) are promoted to live execution. The live engine routes trades to Binance Futures through the current algo API with explicit order verification, places scaled take-profits and stop-losses automatically, and runs a separate exit monitor that closes positions against the broader market trend.
For equities, 128 tickers are scanned after NYSE close through a parallel detector library. A forward-PnL tracker fills each signal at the next day's open and walks it to resolution, which is how the platform identified that 9 of 12 detectors have no real edge on stocks while 3 do.
Tech Stack: Node.js, Supabase, PostgreSQL, Docker, Binance Futures API, Telegram Bot API, REST APIs, cron-based orchestration
The Results
- 150+ strategies tested in parallel against years of historical data, replacing months of sequential live paper trading
- 174% PnL improvement on the live engine after systematic session-gating discovery through backtesting
- 3 of 12 stock detectors statistically validated (the other 9 were eliminated before they could lose money live)
- 441 automated tests across detectors, sizing, walk-forward simulation, and chart rendering
- Look-ahead bias caught systematically: one strategy cluster dropped from PF 3.43 to PF 0.11 after fixing a paper-evaluation bug, preventing live deployment of a losing system
- Zero silent order failures after the algo API migration and verification layer were deployed
How It Works
1. Hourly cron job pulls OHLCV data for top 100 crypto pairs into Supabase
2. 12 pattern detectors scan 4-hour bars and score each setup on timing, order flow, and confluence
3. Qualified setups are saved as pending zones with a 72-hour expiry window
4. Paper engine walks all setups forward against real bars across 150+ strategy variants
5. Strategies that pass 50+ trades with thresholds met become live promotion candidates
6. Live engine executes during London and NY sessions only, with partial TPs, full SL, and a separate trend-based exit monitor
-
Automated FL Tax Deed Auction Research: Hours of Work, Zero Click
AI & Machine Learning
Automated FL Tax Deed Auction Research: Hours of Work, Zero Clicks
The Situation
Florida tax deed auctions list dozens to hundreds of properties per auction day across multiple counties. A serious bidder has to vet each parcel before the auction: acreage, zoning, flood risk, road access, assessed value, aerial view. The research lives across six different county property appraiser portals, FEMA flood maps, Google Maps satellite, Street View, and parcel boundary services like id.land. Each county has its own quirky SPA. Each data point lives in a different tab.
… The Problem
Manual research on auction day runs four to six hours for a single county's list. Multiply by six counties and the math breaks: bidders either skip parcels, miss flood risk signals, or bid blind. The tedium is the real cost. An experienced investor should be filtering and analyzing, not copy-pasting parcel IDs into six different forms.
The target operator is sophisticated enough to self-host and wants full control over their data, API keys, and scraping infrastructure. No SaaS lock-in, no per-seat fees, no sending proprietary investment logic to a vendor.
The Solution
I built a self-hosted intelligence platform that turns hours of manual county-portal research into an overnight pipeline run. The operator triggers one run, walks away, and wakes up to a filterable shortlist of auction parcels ranked by AI verdict.
How the pipeline works (7 stages, event-driven):
1. Scrape listings from realtaxdeed.com behind a Surfshark VPN (the site blocks non-US IPs and non-browser user agents). Handles a multi-step login with up to 5 sequential notice pages, paginates through all auction items.
2. Scrape property data from each county's appraiser portal. Putnam County alone required splitting parcel IDs like 01-10-26-0250-0270-0081 into 6 separate form fields inside an SPA.
3. Resolve GPS coordinates via id.land, dismissing modals and navigating state/county/parcel dropdowns.
4. Capture screenshots: Google Maps satellite, Street View, id.land parcel boundary, FEMA flood zone.
5. Check FEMA flood zone using an undocumented ArcGIS &extent= URL parameter (replaced a brittle UI-search automation flow).
6. Run AI analysis via Claude Sonnet 4 with tool_use for structured output: numeric subscores (land quality, flood risk, road access, development, value), overall 0-100 score, flags, reasoning, and a buy/review/skip verdict.
7. Write results to Supabase, pushed live to a React dashboard via Realtime subscriptions.
Tech Stack: NestJS, Playwright, BullMQ, Redis, Supabase (PostgreSQL + Storage + Realtime), Claude Sonnet 4 API, React, Vite, Tailwind, Leaflet, Docker Compose, Caddy, Surfshark VPN via gluetun.
The Results
- Hours of manual cross-portal research replaced with a single pipeline trigger
- End-to-end pipeline working for Putnam County: 10/10 parcels scraped, 10/10 GPS resolved, 40 screenshots captured per run
- AI cost calibrated at approximately $0.012 per parcel for full vision analysis
- 6-county configuration system lets new counties drop in via config files plus a processor strategy
- Self-hosted architecture keeps all data, API keys, and scraping infrastructure under operator control
- Real-time dashboard shows pipeline runs, parcel details, queue health, AI verdicts, CSV export, interactive map
How It Works (operator view)
1. Operator hits "Trigger Pipeline" in the dashboard (or POSTs to the API)
2. System scrapes the auction listing page, creates a parcel record per item
3. Each parcel flows through all 7 stages automatically
4. Dashboard updates live as parcels complete each stage
5. When AI analysis finishes, operator sees a ranked, filterable list with verdicts
6. Export to CSV or drill into parcel detail with all screenshots side-by-side
-
3M+ Deed Records Processed: Property Research from Days to Minutes
AI & Machine Learning
The Situation
A US-based legal-tech founder was building a property research platform for real estate attorneys: lawyers who hunt for undervalued land parcels as investment opportunities for their clients. Their work depends on finding specific language buried inside deed records such as easements, restrictions, access rights, and boundary clauses.
Before this project, finding the right parcels meant manually searching DataTree and county databases, reading individual deed PDFs, and cross-referencing with tax maps, zoning data, and demographics across separate tabs. A single qualified lead could take days. Some questions couldn't be answered at all.
…
The Problem
Attorneys were missing deals because the research cost was too high. Every property had to be hand-checked against keyword criteria, then enriched with geo data and infrastructure records from four different sources. The founder had tried manual workarounds and off-the-shelf tools. Nothing connected the sources. Nothing filtered by the specific legal language his clients needed to find.
The question wasn't "can we make this faster?" It was "can we make questions answerable that weren't answerable before?"
The Solution
I built an end-to-end property intelligence platform with two layers.
The frontend is a React SPA deployed on Vercel where attorneys search, filter, and review properties. Each result opens into a detail view with deed history, lot-size restrictions, tax maps, infrastructure, and county demographics, all rendered dynamically from a Supabase backend with row-level security.
The backend is n8n-as-API. Rather than running n8n as "automation glue," I used it as the production API layer for the deed-processing pipeline. When an attorney runs a keyword search, the request routes through a Supabase Edge Function to n8n webhooks. The pipeline fetches deed records from DataTree, filters by legal keywords, enriches matches with Zonomics geo data, runs AI analysis via Claude (OpenRouter), and writes progress back to Supabase in real time. Attorneys see staged progress as records are matched and enriched.
This architecture gave the founder a backend that's fully controllable, easy to modify, and fast to extend: new data sources or analysis steps ship in hours, not sprints. To support that velocity, I built a custom Claude Code toolkit that manages n8n workflows programmatically (creating, syncing, and debugging them from natural-language specs).
Tech Stack: n8n, Supabase (PostgreSQL, Auth, Storage, Edge Functions), React 19, TypeScript, Vite, Vercel, DataTree API, Zonomics API, Claude API (via OpenRouter), OpenAI API, Google Maps Embed API, Node.js, Zod, Anthropic SDK
The Results
- 3M+ deed records processed through the pipeline
- Days to minutes per qualified research query
- Questions now answerable that weren't before (multi-source queries that were economically infeasible manually)
- Production system actively used by the founder's team, serving legal clients
- Backend fully controllable: new data sources, keywords, and AI analysis steps ship without rebuilding
- Architected for microSaaS: system is already being prepared for external access by a limited set of attorneys
How It Works
1. Attorney enters keyword criteria (legal language they need in deeds) and geographic scope
2. Request routes through Supabase Edge Function to n8n webhook
3. n8n pipeline fetches matching deed records from DataTree
4. Matches enriched with Zonomics geo data, tax maps, infrastructure, demographics
5. Claude analyzes each deed for relevance; results scored and sorted
6. Attorney downloads only the deeds that match all their criteria via signed Supabase URLs
-
30 AI Agents, 5 Platforms, One Dashboard: Autonomous Content System
AI & Machine Learning
The Situation
A solo content strategist was managing multi-channel publishing: blog, LinkedIn, Dev.to, Hashnode, and Telegram. Every article required manual research, writing, quality review, platform-specific reformatting, and individual publishing through each platform's UI. One piece of content consumed 4-6 hours before going live on all channels.
The Problem
… Each platform had different format requirements: WordPress needed HTML with custom post types, Dev.to used markdown with front matter, Hashnode required GraphQL, LinkedIn stripped markdown and enforced a 2,900-character limit, Telegram used its own HTML subset. Adapting one article for five platforms was tedious and error-prone.
No feedback loop existed. Analytics lived in five separate dashboards. Strategy decisions were gut-based. Quality was inconsistent. Every step depended on the client being available to execute manually.
The Solution
I built an autonomous content system with 30 specialized AI agents orchestrated through BullMQ job chains. The full content lifecycle runs autonomously: trend discovery → research → writing → fact-checking → AI detection → neuromarketing optimization → platform adaptation → approval → publishing.
Pipeline architecture. Each content item moves through a configurable agent sequence. A four-stage quality gate (fact-checker → AI detector → neuro-optimizer → reviewer) validates every draft. The pipeline pauses at approval gates and notifies via Telegram inline keyboards or React dashboard.
Dynamic pipelines. Agent sequences are configurable per channel or per content item through a drag-and-drop UI. Three-tier priority: item overrides → channel defaults → system defaults. Parallel agent execution supported.
Multi-platform publishing. LinkedIn's character limit enforced at three levels: adapter prompt, output validation, and a publisher-level rewrite loop (re-invokes AI to shorten, up to 3 attempts). WordPress publishes as custom post types with formatted HTML. All five publishers run from one action.
Analytics feedback loop. Weekly pipeline collects metrics, generates hypotheses about what's working, and auto-triggers strategy refresh.
Tech Stack: 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
The Results
- ~85% reduction in time per article (4-6 hours → ~30 minutes of oversight)
- 5-platform simultaneous publishing from one approval
- 30 AI agents with configurable pipelines and full cost tracking
- Four-stage quality gate for consistent content quality
- Dual approval interface (React dashboard + Telegram bot)
- Analytics feedback loop that auto-adjusts content strategy
- 606 automated tests (unit, integration, E2E)
How It Works
1. Discover. Cron jobs run trend discovery and competitor analysis
2. Create. Research and writer agents produce long-form content
3. Quality Gate. Fact-checker, AI detector, neuro-optimizer, reviewer validate the draft
4. Adapt. Platform adapters reformat for each channel's requirements
5. Approve. Client reviews via dashboard or Telegram, approves or rejects
6. Publish. Publishers push to all selected platforms simultaneously
The pipeline is fully resumable. It retries with exponential backoff, picks up where it left off.
-
37,000 Records Migrated Across 3 Platforms in 2 Weeks — Zero Data
Client Management & CRM
Full CRM data migration for a Medicare insurance brokerage: RadiusBob → GoHighLevel + HealthSherpa
---
The Situation
A Medicare insurance brokerage with approximately 1,600 clients ran operations across three disconnected systems: RadiusBob (legacy CRM), GoHighLevel (new CRM), and HealthSherpa Medicare (enrollment platform). Agents manually cross-referenced all three daily — no single source of truth, no automation possible.
…
The Problem
Years of client history lived in RadiusBob: 1,593 contacts, 1,222 insurance policies, 32,507 interaction notes, and 793 relationships between contacts. This wasn't a CSV export — it was a full reconstruction across three APIs with different authentication, rate limits, and data formats.
Any lost record meant compliance risk. Manual migration would take months and introduce errors at every step.
The Solution
I built a resumable migration pipeline in Python (Docker + Supabase as sync state tracker). Every record's status was tracked individually — if the process stopped at record 500, it resumed at 501 with zero duplication.
Contact deduplication: GoHighLevel enforces unique phone/email, but RadiusBob allowed shared numbers (married couples). The pipeline caught duplicates from API error responses, updated existing records, and generated a report (163 duplicate groups) for client review.
HealthSherpa matching: Three-pass strategy — first by Medicare Beneficiary ID (highest confidence), then by name + date of birth/email/phone, then creating new records for unmatched contacts. Each match saved a direct enrollment URL for one-click access from GoHighLevel.
Policy records: Custom Object schema in GoHighLevel with 15 fields. Discovered and handled undocumented API quirks through systematic testing.
32,507 notes: Parallel processing with 8 concurrent API requests cut import time from over 9 hours to approximately 1 hour while staying within rate limits.
793 relationships: Mapped 10 relationship types handling both bidirectional (Spouse) and directional (Parent-Child) associations. 260 unmapped types documented for client review.
Tech Stack: Python 3.11, Docker, Supabase (PostgreSQL), GoHighLevel API, HealthSherpa Medicare API, asyncio
The Results
- Approximately 37,000 total records migrated across 3 platforms
- 100% of contacts imported (1,593/1,593)
- 100% of notes preserved (32,507/32,507)
- 99.3% of policies imported (1,214/1,222)
- 8 times faster note import through parallel processing
- Zero data loss — every importable record migrated with full history
- 2-week delivery from kickoff to completion
- One-click Medicare enrollment links on every client record
How It Works
1. Extract — Pull all data from RadiusBob API
2. Transform — Normalize formats, clean data, validate fields, deduplicate
3. Load — Push contacts to GoHighLevel, match to HealthSherpa via 3-pass strategy
4. Link — Create policy records, attach notes, build relationship associations
5. Verify — Reconciliation counts, duplicate report, validation audit trail
Every step is idempotent and resumable. The pipeline can re-run without duplicates or lost progress.
-
CRM automation - Invoice Collection Automation - ClickUp
Client Management & CRM
US-based construction services company managed over 5,000 invoices through Service Fusion — a legacy platform with limited customization and no built-in collection workflow.
THE PROBLEM
The accountant spent approximately 60 hours per month on manual work: transferring invoice data between systems, tracking due dates by memory, composing individual follow-up emails. Each email took 15 minutes — gathering information from multiple screens, cross-referencing job details, manually formatting messages. Critical limitation: Service Fusion stores invoices and clients in separate tables with no direct link. Staff traced connections through Jobs table, making systematic tracking nearly impossible.
…
THE SOLUTION
Three automations working together, preserving Service Fusion as source of truth:
• Unified Tracking: Estimates and invoices flow automatically into Smartsheet
• Collection System: 7 email templates by payment stage (-2 days, day 1, 7, 14, 31+). One click sends personalized follow-up with job name, address, invoice ID, amount
• Auto-Sync: Updates every 30 minutes. Paid invoices close related ClickUp tasks automatically
RESULTS
• 60 hours per month freed from manual work
• Follow-up time: 15 minutes → 1 click
• First-ever collection rate tracking capability
• Handles over 5,000 invoices without additional headcount
Timeline: 2.5 weeks (development and testing)
-
n8n Automation for RSS work evaluations
Client Management & CRM
As a full stack developer, I created an automation system using n8n that runs every 5 minutes to process new job listings. The workflow evaluates each job with a 10-point scoring system based on matching keywords and skills. Selected jobs are automatically sent to a Discord channel and added to a Notion database. Tags are managed and updated via HTTP requests for accurate tracking. As a front-end developer, react developer, and web developer, I designed an efficient and scalable solution, fully leveraging n8n’s automation capabilities to streamline the process.
-
n8n Automation: Sync Worksection Tasks with HubSpot Deals
Client Management & CRM
As an n8n Automation developer, I built this automated integration using n8n to connect Worksection and HubSpot. The workflow triggers on new tasks in Worksection, processes Deal data, and automatically creates new Deals in HubSpot. It also syncs contact details, updates tasks, and ensures both systems stay aligned in real time. This solution eliminates manual data entry, reduces errors, and saves time for the sales team. The project showcases my expertise in API automation, n8n workflows, and complex integrations.
-
n8n Automation for Smart Email Sorting and Business Workflow
Client Management & CRM
As an n8n automation expert, I developed a smart email processing system for Gmail. The automation uses an AI model to classify incoming emails into categories (commercial, retail, social, important, other), applies labels, removes non-priority emails from the inbox, and logs actions to Google Sheets for reporting. This solution helps businesses save time and manage communication more effectively. With my background as a full stack developer, front-end developer, react developer, and web developer, I deliver reliable and scalable n8n-based automations tailored to business needs.
Activity
| Latest proposals 2 | Budget | Added | Deadlines | Proposal | |
|---|---|---|---|---|---|
|
List of pages
45 USD
|
|||||
|
адаптивная верстка сайта
113 USD
|
