Андрей Бойко
Запропонуйте Андрею роботу над вашим наступним проєктом або зареєструйте профіль фрилансера і починайте заробляти просто зараз.
Особисте повідомлення
Запропонувати роботу
Харків,
Україна
20 днів 15 годин тому
вільний для роботи
на сервісі 9 років
Рейтинг
Успішних проєктів
Середня оцінка
Рівень володіння мовами
English: просунутий
Українська: вище середнього
Навички та вміння
Програмування
Аутсорсінг та консалтинг
Портфоліо
-
Постійна векторна пам'ять для коду Клода: Відкритий сервер MCP
AI та машинне навчання
Ситуація
Claude Code - це потужний AI асистент кодування, але він за своєю суттю безстанційний. Кожна нова сесія починається без знання минулих рішень, помилок або архітектури. У реальній виробничій роботі це призводить до постійного повторення, втрати контексту та уповільнення розвитку.
Проблема
… Основна проблема: AI асистент, який допомагає будувати проект, не має пам'яті про його створення. Я знову відкривав ті ж самі помилки, знову пояснював ту ж архітектуру і втратив рішення, прийняті минулого тижня. Додаткова проблема: повторювані шаблони в проектах (наприклад, "ми налаштували Supabase саме так 4 рази") залишалися похованими в пам'яті сесій замість того, щоб стати повторно використовуваними, задокументованими навичками.
Рішення
Я створив memory-mcp, відкритий MCP сервер, який надає Claude Code довгострокову семантичну пам'ять. Він пропонує 8 інструментів: 4 основних інструменти пам'яті (запам'ятати, згадати, забути, статус_проекту) та 4 інструменти шаблонів навичок, які відстежують повторювані робочі шаблони та виводять кандидатів для формалізації, коли їх бачать 3+ рази.
Спогади зберігаються у вигляді векторних вбудувань розміром 1536 вимірів (OpenAI text-embedding-3-small) у Supabase PostgreSQL з pgvector. Витяг виконує пошук косинусної схожості через функцію RPC Postgres з фільтрацією на рівні SQL (поріг, проект, тип, дата, термін дії) за один раз. Відповіді на запити обмежені до ~2000 токенів, щоб захистити контекстне вікно Claude.
Сервер працює як безстанційний контейнер Docker на порту 3101 через Express + Streamable HTTP транспорт, тому кілька сесій Claude Code ділять один завжди активний екземпляр. Також доступний режим транспорту stdio для прямої інтеграції з рідним бінарним форматом. Спогади ніколи не видаляються остаточно: забути - це м'яке видалення через expires_at, і кожен запит фільтрується за статусом активної пам'яті.
Технологічний стек: Node.js 20, TypeScript 5 (строгий), Express 5, @ modelcontextprotocol/sdk, OpenAI API (text-embedding-3-small), Supabase PostgreSQL, pgvector, IVFFlat індекси, Zod валідація, Vitest, Docker Compose.
Результати
- 8 MCP інструментів випущено та протестовано від початку до кінця через HTTP
- 125 юніт-тестів з повністю змодельованими клієнтами Supabase та OpenAI
- ~2,600 рядків TypeScript у 16 вихідних файлах, 11 комітів за 11 днів
- 2 таблиці, 3 функції RPC з фільтрацією на рівні SQL перед LIMIT для коректності
- Виробничий запуск як завжди активний Docker сервіс, використовується щодня з реальними сесіями Claude Code
- Опубліковано як відкритий код на GitHub з повною документацією з налаштування, Docker Compose та посібником з усунення несправностей, що охоплює 4 задокументовані режими збоїв
Ключові інженерні рішення
1. Емпіричні пороги схожості. text-embedding-3-small виробляє нижчі косинусні оцінки, ніж вказують документи (майже ідентичні текстові оцінки 0.78–0.84). Я знизив поріг згадування до 0.25 і dedup до 0.75 на основі реальних вимірювань, задокументував правило для майбутніх функцій.
2. Фільтрація дати на рівні SQL. Фільтр since_days спочатку працював на стороні клієнта після LIMIT, що тихо пропускало нещодавні спогади, які були нижче топ N. Переміщення його в WHERE перед LIMIT гарантує коректність незалежно від обсягу даних.
3. Опис інструментів як виконувані інструкції. Опис інструментів був переписаний з "що вони роблять" на "коли їх викликати" (наприклад, "Викликати перед початком нетривіальної роботи"), тому інструменти працюють правильно без необхідності підтримувати CLAUDE.md.
4. Обхід OAuth для рідного бінарного формату Claude Code. Бінарний формат блокує HTTP MCP з'єднання, поки не завершиться відкриття OAuth. Додавання статичного токена Bearer до конфігурації MCP повністю пропускає відкриття (токен є довільним і ніколи не перевіряється на стороні сервера).
Доступно на GitHub
Повний вихідний код, інструкції з налаштування та документація з архітектури опубліковані для розробників, які хочуть відтворити або розширити систему.
-
AI-продажний агент через голос, чат, Телеграм, WhatsApp (Одна труба)
AI та машинне навчання
Ситуація
Агентство B2B з продажу проводило кваліфікацію лідів у великому обсязі для своїх клієнтів. Потенційні клієнти зверталися через 4 канали: віджет на вебсайті, телефонні дзвінки, Telegram та WhatsApp. Агентство хотіло автоматизувати перші розмови через усі ці канали без найму додаткових SDR.
Проблема
… Більшість інструментів автоматизації продажів є специфічними для каналу. Чат-бот для вебсайту. Окремий бот для Telegram. Інший постачальник для голосу. Кожен інструмент має свої власні записи лідів, свої власні сценарії, жодної спільної інформації. Коли один і той же потенційний клієнт звертався в Telegram, а пізніше телефонував на основний номер, ніхто не пов'язував ці два взаємодії. Оцінки лідів були фрагментованими. Відповіді бази знань були непослідовними між каналами. А вихідні дзвінки все ще вимагали людського SDR, який телефонує через електронну таблицю.
Агентству потрібен був один мозок за кожним каналом, а не чотири з'єднані разом інструменти.
Рішення
Я створив єдину платформу продажів, де кожне повідомлення проходить через одного й того ж AI-агента. Голос, чат, Telegram, WhatsApp: кожен канал має тонкий адаптер, який нормалізує вхідні повідомлення, а потім передає їх до спільного ChatService. Ця служба шукає ліда, отримує відповідні знання через RAG (вбудовування Voyage AI в pgvector) і передає історію розмови агенту, який відповідає на запитання, спираючись на фактичні документи продукту компанії, ціни та FAQ. Одні й ті ж записи лідів, одна й та ж база знань, одна й та ж оцінка через усі 4 канали.
Для виходу оператори завантажують список контактів, прикріплюють голосовий сценарій і запускають кампанію з адміністративної панелі. Робітники BullMQ телефонують контактам через Retell AI з обмеженням 1 дзвінок/секунду. Retell обробляє телефонію та мову; мій власний WebSocket-інтерфейс передає транскрипцію кожного дзвінка агенту в реальному часі. Після кожного дзвінка вебхуки Retell доставляють транскрипцію, підсумок дзвінка та аналіз настроїв назад на платформу, яка автоматично коригує оцінки лідів (+10 за позитивний настрій, -5 за негативний).
Вбудовуваний віджет є 53KB однофайловим пакетом Vite IIFE, який можна вставити на будь-який вебсайт за допомогою одного тегу скрипта, рендериться всередині Shadow DOM, щоб уникнути конфліктів CSS, і відновлює історію чату при перезавантаженнях сторінки через localStorage.
Технічний стек: NestJS, TypeScript, Claude API (Anthropic SDK), Retell AI, вбудовування Voyage AI, OpenAI Whisper, Supabase (PostgreSQL + pgvector), BullMQ, Redis, Next.js, Vite, Docker, nginx, Cloudflare Tunnel
Результати
- 4 канали об'єднані під 1 AI-потік: голосові дзвінки, чат на вебсайті, Telegram, WhatsApp ділять записи лідів, базу знань та оцінки
- Вихідні дзвінки повністю автоматизовані: оператори налаштовують кампанію один раз, система телефонує, спілкується, транскрибує та оцінює кожен контакт без участі SDR
- Готовий до багатокористувацького використання: організації, RBAC та бази знань для кожної організації вбудовані, тому платформа може хостити кілька клієнтів агентств
- Запущено в тестуванні з партнерами з 7 службами Docker, підписаною перевіркою вебхуків та тестовим покриттям через 34 тестові файли (одиничні, інтеграційні, поведінка AI, E2E)
Як це працює
1. Потенційний клієнт звертається через будь-який з 4 каналів (віджет, телефон, Telegram, WhatsApp)
2. Адаптер каналу нормалізує повідомлення та створює або шукає ліда
3. ChatService отримує історію розмови та проводить семантичний пошук по базі знань компанії
4. Агент генерує відповідь, спираючись на отримані документи
5. Відповідь повертається через той же адаптер каналу
6. Оцінка ліда оновлюється на основі сигналів повідомлення або (для голосу) аналізу настроїв після дзвінка
-
Забезпечення виконання стандартних операційних процедур календаря: 3 календарі, нульовий ручний перегляд
AI та машинне навчання
Ситуація
Американський інвестиційний фонд працює за суворими стандартами проведення зустрічей. Ранки захищені для глибокої роботи, понеділки - тільки для внутрішніх зустрічей, вівторки - тільки для зовнішніх, середа та четвер поглинають переповнені зустрічі з жорстким лімітом, п’ятниці залишаються без зустрічей. Команда також розподіляє час між трьома окремими календарями Google: Бізнес, Фонд та Особистий. Будь-яка помилка в цьому коштує зосередженості, часу на угоди і, зрештою, довіри з партнерами.
Проблема
… Контроль був ручним. Хтось мусив щодня перевіряти три календарі, виявляти зустріч, заплановану до полудня, помічати дві зустрічі підряд без буфера, позначати зовнішнє бронювання в день внутрішніх зустрічей. Перевірки були нудними, запізнілими і легко пропускалися. Раніша спроба використовувала вбудовані статичні дані n8n, щоб уникнути повторних сповіщень, але цей стан скидається при кожному збереженні робочого процесу. На практиці те саме порушення повторно надсилалося до Slack кожні 5 хвилин протягом усього дня. Виникла втома від сповіщень, і команда почала ігнорувати канал, що знівелювало сенс.
Рішення
Я побудував двошарову систему n8n, підтримувану Supabase. Монітор в реальному часі опитує всі три календарі Google кожні 5 хвилин, перевіряє кожну подію через механізм аудиту SOP (час доби, буфер, тип дня, щоденні ліміти) і публікує порушення в спеціальному каналі Slack. Щоденний аудит проводиться о 8:30 ранку за східним часом з повним оглядом тижня та пропозиціями щодо перенесення, згенерованими штучним інтелектом, а в п’ятницю надсилається друге повідомлення з попереднім переглядом наступного тижня.
Шар дедуплікації - це елемент, який зробив це можливим у виробництві. Кожне порушення отримує стабільний ключ (правило + дата + хеш події). Перед будь-яким надсиланням до Slack робочий процес витягує сповіщення тижня з таблиці Supabase і порівнює їх. Тільки справді нові порушення досягають Slack. Щоранку щоденний аудит видаляє рядки попереднього тижня, зберігаючи таблицю компактною.
Вся система працює всередині n8n і Supabase. Немає власного сервера, немає Docker, немає локального коду. Весь інструментальний ланцюг управляється через сервери MCP, тому оновлення робочих процесів, зміни схеми та розгортання відбуваються через контрольований інтерфейс, організований штучним інтелектом, з межами безпеки від стадії до виробництва.
Технологічний стек: n8n, Supabase, PostgreSQL, Google Calendar API, Slack API, OpenAI API, MCP (Протокол Контексту Моделі)
Результати
- 3 календарі Google постійно моніторяться без жодної ручної перевірки
- Виявлення за 5 хвилин від порушення до сповіщення в Slack
- Нульові дублікати сповіщень після того, як шар дедуплікації Supabase замінив крихкий хеш в пам’яті
- Щоденний аудит о 8:30 ранку з пропозиціями щодо перенесення від штучного інтелекту, плюс попередній перегляд наступного тижня в п’ятницю
- Безсерверна архітектура: немає сервера додатків, немає Docker, повністю керується через n8n і Supabase
- Безпечні розгортання: зміни робочих процесів у виробництві контролюються явним підтвердженням оператора
Як це працює
1. Планувальник спрацьовує кожні 5 хвилин і читає стан синхронізації з Supabase
2. Події витягуються з бізнесових, фондових та особистих календарів Google, а також з затвердженого списку винятків
3. Виявлення змін завершується рано, якщо нічого не змінилося з моменту останнього опитування
4. Механізм аудиту SOP оцінює кожну подію за часом, буфером, типом дня та правилами ліміту
5. Шар дедуплікації порівнює нові ключі порушень з повідомленими сповіщеннями тижня в Supabase
6. Справді нові порушення публікуються в Slack і записуються назад у Supabase
-
AI-Нативний Контроль для Worksection: Клод, Курсор, ChatGPT через М
AI та машинне навчання
AI-Нативний Контроль для Worksection: Claude, Cursor, ChatGPT через MCP
Ситуація
Клієнт управляв усією своєю діяльністю в Worksection: завдання, проекти, коментарі, витрати, призначення команди. Їхня команда також повністю перейшла на AI асистентів (Claude, Cursor, ChatGPT) для щоденної роботи. Але ці два світи були відокремлені. AI нічого не знав про Worksection, а Worksection нічого не знав про AI.
… Проблема
Кожна взаємодія між цими двома інструментами була ручною. Розробник просив Claude скласти опис завдання, а потім вручну копіював його в Worksection. PM робив скріншот статусу проекту і вставляв його в ChatGPT для підсумування. AI міг думати про роботу, але не міг виконувати її. Цей цикл копіювання-вставки знищив більшість продуктивності, яку клієнт очікував від AI спочатку. Їм потрібно було, щоб AI міг читати і писати в Worksection безпосередньо, з належною аутентифікацією, без спільних облікових даних і без ручної інтеграції для кожного члена команди.
Рішення
Я побудував сервер MCP (Модель Контекст Протоколу) для виробництва, який знаходиться між будь-яким AI клієнтом, сумісним з MCP, і API Worksection. AI викликає названий інструмент, наприклад, post_task або get_projects, а сервер обробляє аутентифікацію, обмеження швидкості, переклад даних та формування відповіді.
Це постачається як багатокористувацький SaaS: кожна команда реєструється один раз, отримує свої власні зашифровані облікові дані та OAuth клієнтів і підключає Claude або Cursor за допомогою одного URL. Панель адміністратора (React + Vite) дозволяє оператору керувати орендарями, обертати секрети OAuth, налаштовувати обмеження швидкості для кожного орендаря та бачити, які інструменти викликаються і як часто.
Три технічні рішення визначили побудову. По-перше, API Worksection аутентифікується лише з рядка запиту URL (тіла POST ігноруються його хеш-валідатором), тому кожен вихідний виклик використовує двоетапне кодування: сирий рядок для MD5 хешування, повторно закодований рядок для транспорту. По-друге, кожен ключ API орендаря зашифрований у спокої за допомогою AES-256-GCM; відкритий текст ніколи не потрапляє в базу даних. По-третє, відповіді API активно стискаються перед поверненням до AI, оскільки сирі дані Worksection можуть переповнити вікно контексту моделі на великих проектах.
Технічний стек: Node.js 20, TypeScript, Express, @ modelcontextprotocol/sdk, Supabase (PostgreSQL), OAuth2, AES-256-GCM, Zod, Winston, React, Vite, Docker, nginx, Hetzner VPS.
Результати
26 інструментів MCP працюють у виробництві в 7 категоріях: завдання, проекти, коментарі, учасники, витрати, теги, файли
Багатокористувацький SaaS з аутентифікацією OAuth2, обмеженнями швидкості для кожного орендаря та зашифрованими обліковими даними
Нульове копіювання-вставка між AI асистентом і Worksection для щоденних проектних операцій
30-денні токени OAuth, налаштовані спеціально для шаблонів використання AI клієнтів (без тихих 401 помилок під час сесії)
Панель адміністратора з управлінням орендарями, обертанням секретів OAuth та аналітикою використання по інструментах за 7/30/90 днів
Виробничо-стійкий: розгортання Docker, реверсний проксі nginx, точка здоров'я з метаданими збірки, структуроване логування
Активний у виробництві, обслуговуючи реальних орендарів на живому VPS
Як це працює
1. Орендар реєструється зі своїм URL Worksection та ключем API; сервер шифрує ключ і надсилає електронний лист з підтвердженням OTP
2. Орендар підтверджує через OTP, обліковий запис активується
3. AI клієнт (Claude, Cursor, ChatGPT) аутентифікується через OAuth2 і отримує 30-денний токен доступу
4. AI викликає інструмент (наприклад, post_task); сервер перевіряє токен доступу і знаходить орендаря з кешу
5. Сервер перекладає виклик на запит GET Worksection з MD5-хешованою аутентифікацією, повторює з затримкою у разі невдачі
6. Стиснута відповідь повертається до AI; використання реєструється в Supabase для аналітики
-
AI Асистент для ServiceFusion: Запит роботи через чат, а не кліки
AI та машинне навчання
Ситуація
Оператор польового обслуговування, що працює на ServiceFusion, хотів, щоб диспетчери та офісний персонал перестали переходити через меню щоразу, коли їм потрібно перевірити історію роботи клієнта, відкрити оцінки або побачити, який технік призначений на роботу. Команда вже використовувала Claude для інших завдань. Очевидний наступний крок: дозволити Claude спілкуватися безпосередньо з ServiceFusion.
Проблема
… ServiceFusion надає REST API, але AI асистенти не можуть викликати його безпосередньо. Протокол контексту моделі (MCP) є новим стандартом для надання AI клієнтам структурованого доступу до зовнішніх інструментів, і жодного MCP сервера для ServiceFusion не існувало. Правильне створення одного означало вирішення трьох проблем одночасно:
Життєвий цикл токена OAuth2. ServiceFusion використовує короткочасні токени доступу, які закінчуються і повинні бути оновлені прозоро, щоб AI ніколи не стикався з помилкою авторизації під час розмови.
Багатокористувацькість. Один екземпляр сервера повинен був ізолювати облікові дані та API виклики для кількох компаній, кожна з яких має свій обліковий запис ServiceFusion.
Самообслуговування при onboarding. Оператор не хотів вручну налаштовувати кожного нового орендаря.
Рішення
Я створив багатокористувацький MCP сервер на Node.js та TypeScript, який знаходиться між AI клієнтами (Claude, Cursor, ChatGPT) та ServiceFusion. Він надає 13 структурованих інструментів, що охоплюють основні сутності, які насправді використовують диспетчери: клієнти, роботи, оцінки, техніки та обладнання.
Сервер обробляє два незалежні шари OAuth2. Один аутентифікує вхідні AI клієнти до MCP сервера. Другий керує власними токенами ServiceFusion сервера, включаючи автоматичне оновлення з блокуванням конкурентності, щоб одночасні запити ніколи не викликали дублювання оновлень.
Всі чутливі облікові дані (ідентифікатори клієнтів, секрети, токени) шифруються в спокої за допомогою AES-256-GCM у Supabase PostgreSQL. Нові орендарі самостійно реєструються через REST API, підтверджують через OTP і надають свої облікові дані ServiceFusion для активації. Жодної ручної роботи оператора при реєстрації.
Легка адміністративна панель дозволяє оператору переглядати використання за орендарем, регулювати ліміти швидкості та активувати або деактивувати облікові записи.
Технічний стек: Node.js 20, TypeScript, @modelcontextprotocol/sdk, Express, Supabase (PostgreSQL), шифрування AES-256-GCM, Zod, Winston, Docker, nginx, Let's Encrypt
Результати
13 MCP інструментів працюють з клієнтами, роботами, оцінками, техніками та обладнанням
Жодної ручної налаштування для орендаря. Процес реєстрації та активації через OTP
Прозорий OAuth2. Токени, що закінчилися, автоматично оновлюються з захистом від гонки
Ліміти швидкості для кожного орендаря (безкоштовні, професійні, корпоративні рівні) забезпечуються на рівні запиту
Повне відстеження використання (назва інструменту, кінцева точка, код статусу, час відповіді) реєструється для кожного орендаря для виставлення рахунків та аналітики
Розгорнуто в продукції на Hetzner VPS за nginx з SSL, співіснуючи з братнім MCP сервером на тому ж хостингу
Як це працює
1. Орендар надсилає POST запит на /api/register з назвою компанії та електронною поштою, отримує 6-значний OTP
2. Орендар підтверджує через /api/confirm, а потім активує, надаючи облікові дані OAuth ServiceFusion
3. Облікові дані шифруються за допомогою AES-256-GCM і зберігаються в Supabase
4. AI клієнт (Claude, Cursor) викликає /mcp з токеном доступу; проміжне програмне забезпечення ідентифікує орендаря та перевіряє ліміт швидкості
5. При виклику інструменту сервер перевіряє дійсність токена і автоматично оновлює його, якщо він закінчився
6. Структурована відповідь повертається до AI клієнта, а виклик реєструється для аналітики використання
-
Інтелект ціноутворення продуктів: заощадження на кошику понад 60% у 4 магазинах
AI та машинне навчання
Інтелект ціноутворення продуктів: заощадження на кошику понад 60% у 4 магазинах
Ситуація
Український засновник технологій споживчого сектора хотів надати покупцям те, чого не пропонує жоден місцевий додаток: єдиний вигляд їхнього повного кошика продуктів, ціни на який одночасно порівнюються у чотирьох найбільших мережах доставки в країні. Кінцева мета була простою. Покупець вводить тижневий список, бачить, який магазин є найдешевшим для цього конкретного кошика, і створює виграшний кошик в один клік.
… Проблема
Українські покупці продуктів зазвичай звикають до однієї мережі і переплачують, не знаючи про це. Ціни суттєво варіюються між Silpo, Novus, Auchan та Metro, але перевірка чотирьох додатків вручну займає більше часу, ніж саме шопінг. Крім того, домінуюча мережа доставки захищає свій сайт агресивним виявленням ботів, тому наївні підходи до автоматизації кошика ламаються після одного або двох запусків. Засновнику потрібна була надійна система, яка працювала б у виробництві, а не демонстрація, яка зазнала б невдачі, як тільки реальний покупець спробував би її використати.
Рішення
Я побудував систему від початку до кінця як платформу автоматизації повного стеку. Панель управління React дозволяє покупцеві вводити список природною українською мовою ("молоко 2шт, хліб, курка 1.5кг") або шукати продукти у всіх чотирьох магазинах з фотографіями. Коли покупець натискає "порівняти", бекенд надсилає паралельні запити до всіх чотирьох API магазинів і повертає порівняння загальної вартості кошика, відсортоване за найдешевшим, з розбивкою по товарам.
Для складання кошика в основному магазині я вирішив проблему виявлення ботів за допомогою інвертованої архітектури: замість сервера, що контролює браузер, власний Chrome покупця опитує сервер для виконання роботи через розширення Chrome. Розширення атомарно отримує завдання з черги Postgres, складає кошик у справжній сесії браузера і звітує назад. Це працює на домашньому з'єднанні покупця, яке веде себе як справжній покупець, оскільки є ним.
Я також створив парсер чеків: покупці вставляють URL українського фіскального чека, і система витягує кожен рядок (включаючи вагові товари та знижки) і перетворює його на багаторазовий шаблон для повторних замовлень.
Технологічний стек: NestJS, TypeScript, React, Vite, Tailwind, Supabase (PostgreSQL), Redis, BullMQ, Playwright, розширення Automa Chrome, Docker, Fuse.js, grammY Telegram бот
Результати
- 62% заощаджень на кошику виявлено під час живого тестування: кошик з 5 товарів коштує 301 грн у виграшному магазині проти 787 грн у звичайному магазині
- 4 магазини оцінюються паралельно в одному запиті на порівняння, а не послідовно
- Автоматизація кошика виробничого рівня, яка витримує агресивне виявлення ботів, де стандартні інструменти браузера на стороні сервера зазнають невдачі після 1-2 запусків
- 31 REST-інтерфейс, 7 таблиць бази даних з безпекою на рівні рядків, 37 успішних тестів
- Робочий потік від початку до кінця: створення списку, порівняння 4 магазинів, автоматизоване складання кошика, парсинг чека в список, відстеження життєвого циклу замовлення
Як це працює
1. Покупець вводить або імпортує список покупок у панелі управління
2. Система надсилає паралельні запити цін до всіх 4 API магазинів
3. Панель управління показує загальні суми кошика, відсортовані за найдешевшими, з деталізацією по товарам
4. Покупець обирає виграшний магазин і натискає "створити кошик"
5. Розширення Chrome отримує завдання і складає кошик у браузері покупця
6. Покупець переглядає кошик, обирає час доставки і оформляє замовлення
-
Автоматизована торгова платформа: роки валідації стратегії за годину
AI та машинне навчання
Автоматизована торгова платформа: роки валідації стратегій за години
Ситуація
Клієнт є активним роздрібним трейдером з США, який управляє особистим капіталом на ринках криптовалют та акцій. Технічно підкований, комфортно почувається з API та бек-тестами, але стикається з фундаментальною проблемою, з якою стикається кожен роздрібний квант: відсутність інфраструктури для визначення, які патерни насправді працюють, а які лише виглядають добре в ретроспективі.
… Проблема
Бек-тести виявилися неправдивими. Один патерн показав фактор прибутковості 2.5 у бек-тесті, але не дав жодної виграшної угоди в реальному часі. Інший показав відхилений 0.34 у бек-тесті, але дав 3.12 в реальному часі. Клієнт втрачає реальні гроші на стратегіях, які виглядають сильними на папері, а валідація однієї ідеї вимагала місяців живої паперової торгівлі, перш ніж він міг би вкласти капітал. Ручне сканування понад 100 активів було неможливим, а безшумний збій стоп-лоссу на старому кінцевому пункті біржі вже коштував йому приблизно 300 доларів в одному інциденті.
Рішення
Я побудував платформу виробничого класу на Node.js, яка запускає чотири незалежні двигуни паралельно. Двигун паперової торгівлі тихо тестує понад 150 варіантів стратегій на реальних ринкових даних, проходячи кожен кандидат-сигнал через роки історичних барів для обчислення реальних коефіцієнтів виграшу, факторів прибутковості та просадок. Конвеєр оцінювання запускає 12 детекторів патернів на 4-годинних графіках, підтверджує на 1-годинних таймфреймах і враховує час сесії, потік замовлень, профіль обсягу та дані ліквідації. Тільки стратегії, які проходять суворі пороги (50+ угод вперед, PF вище 1.5, WR вище 55%, просадка нижче 20%), просуваються до живого виконання. Живий двигун маршрутизує угоди до Binance Futures через поточний алгоритмічний API з явною перевіркою замовлень, автоматично встановлює масштабовані тейк-профіти та стоп-лоси і запускає окремий монітор виходу, який закриває позиції відповідно до загального ринкового тренду.
Для акцій скануються 128 тикерів після закриття NYSE через паралельну бібліотеку детекторів. Трекер PnL вперед заповнює кожен сигнал на відкритті наступного дня і веде його до вирішення, що є способом, яким платформа виявила, що 9 з 12 детекторів не мають реальної переваги на акціях, тоді як 3 мають.
Технологічний стек: Node.js, Supabase, PostgreSQL, Docker, Binance Futures API, Telegram Bot API, REST APIs, оркестрація на основі cron
Результати
- 150+ стратегій протестовано паралельно на основі років історичних даних, замінюючи місяці послідовної живої паперової торгівлі
- 174% покращення PnL на живому двигуні після систематичного виявлення сесійних обмежень через бек-тестування
- 3 з 12 детекторів акцій статистично валідовані (інші 9 були усунуті до того, як могли б втратити гроші в реальному часі)
- 441 автоматизований тест через детектори, розмір, симуляцію вперед та рендеринг графіків
- Систематично виявлено упередження погляду вперед: один кластер стратегій впав з PF 3.43 до PF 0.11 після виправлення помилки оцінки на папері, що запобігло живому впровадженню програшної системи
- Жодних безшумних збоїв замовлень після міграції алгоритмічного API та впровадження шару перевірки
Як це працює
1. Щогодинна задача cron витягує дані OHLCV для 100 найкращих криптовалютних пар у Supabase
2. 12 детекторів патернів сканують 4-годинні бари та оцінюють кожну установку за часом, потоком замовлень та конгруенцією
3. Кваліфіковані установки зберігаються як очікуючі зони з терміном дії 72 години
4. Паперовий двигун просуває всі установки вперед на основі реальних барів через понад 150 варіантів стратегій
5. Стратегії, які проходять 50+ угод з виконаними порогами, стають кандидатами на живе просування
6. Живий двигун виконує угоди лише під час сесій Лондона та Нью-Йорка, з частковими TPs, повними SL та окремим монітором виходу на основі тренду
-
Автоматизоване дослідження аукціону податкових актів FL: години роботи, нульовий клік
AI та машинне навчання
Автоматизоване дослідження аукціонів податкових актів у Флориді: години роботи, нуль кліків
Ситуація
Аукціони податкових актів у Флориді перераховують десятки до сотень об'єктів за день аукціону в кількох округах. Серйозний учасник аукціону повинен перевірити кожну ділянку перед аукціоном: площа, зони, ризик затоплення, доступ до дороги, оціночна вартість, аерофотознімок. Дослідження проводиться на шести різних порталах оцінювачів майна округу, картах затоплення FEMA, супутникових знімках Google Maps, Street View та службах меж ділянок, таких як id.land. Кожен округ має свій власний незвичайний SPA. Кожна точка даних знаходиться на різній вкладці.
… Проблема
Ручне дослідження в день аукціону займає від чотирьох до шести годин для списку одного округу. Помножте на шість округів, і математика ламається: учасники аукціону або пропускають ділянки, або не помічають сигнали ризику затоплення, або роблять ставки наосліп. Нудьга є справжньою вартістю. Досвідчений інвестор повинен фільтрувати та аналізувати, а не копіювати та вставляти ідентифікатори ділянок у шість різних форм.
Цільовий оператор достатньо досвідчений, щоб самостійно хостити та хоче повний контроль над своїми даними, API-ключами та інфраструктурою збору даних. Ніякого блокування SaaS, ніяких плат за місце, ніякої передачі власної інвестиційної логіки постачальнику.
Рішення
Я створив самостійно хостингову платформу інтелекту, яка перетворює години ручного дослідження на порталах округу в нічний потік. Оператор запускає один потік, йде геть і прокидається з фільтрувальним коротким списком ділянок аукціону, ранжованих за вердиктом ШІ.
Як працює потік (7 етапів, на основі подій):
1. Збирає списки з realtaxdeed.com за допомогою Surfshark VPN (сайт блокує неамериканські IP-адреси та небраузерні агенти користувача). Обробляє багатоступеневий вхід з до 5 послідовних сторінок повідомлень, пагінує через всі аукціонні предмети.
2. Збирає дані про майно з порталу оцінювача кожного округу. Округ Патнам сам по собі вимагав розділення ідентифікаторів ділянок, таких як 01-10-26-0250-0270-0081, на 6 окремих полів форми всередині SPA.
3. Визначає GPS-координати через id.land, відхиляючи модальні вікна та навігацію через випадаючі списки штат/округ/ділянка.
4. Захоплює скріншоти: супутникові знімки Google Maps, Street View, межі ділянки id.land, зону затоплення FEMA.
5. Перевіряє зону затоплення FEMA, використовуючи не задокументований параметр URL ArcGIS &extent= (замінює крихкий автоматизований потік пошуку UI).
6. Виконує аналіз ШІ через Claude Sonnet 4 з tool_use для структурованого виходу: числові підбали (якість землі, ризик затоплення, доступ до дороги, розвиток, вартість), загальний бал 0-100, позначки, обґрунтування та вердикт купити/переглянути/пропустити.
7. Записує результати в Supabase, які виводяться в реальному часі на панель управління React через підписки в реальному часі.
Технологічний стек: NestJS, Playwright, BullMQ, Redis, Supabase (PostgreSQL + Storage + Realtime), API Claude Sonnet 4, React, Vite, Tailwind, Leaflet, Docker Compose, Caddy, Surfshark VPN через gluetun.
Результати
- Години ручного крос-портального дослідження замінені одним тригером потоку
- Кінцевий потік працює для округу Патнам: 10/10 ділянок зібрано, 10/10 GPS визначено, 40 скріншотів захоплено за один запуск
- Вартість ШІ калібрована приблизно на $0.012 за ділянку для повного аналізу зору
- Система конфігурації для 6 округів дозволяє новим округам підключатися через конфігураційні файли плюс стратегію процесора
- Архітектура самостійного хостингу зберігає всі дані, API-ключі та інфраструктуру збору даних під контролем оператора
- Панель управління в реальному часі показує запуски потоку, деталі ділянок, стан черги, вердикти ШІ, експорт CSV, інтерактивну карту
Як це працює (перегляд оператора)
1. Оператор натискає "Запустити потік" на панелі управління (або POST до API)
2. Система збирає сторінку списку аукціону, створює запис ділянки для кожного предмета
3. Кожна ділянка проходить через всі 7 етапів автоматично
4. Панель управління оновлюється в реальному часі, коли ділянки завершують кожен етап
5. Коли аналіз ШІ закінчується, оператор бачить ранжований, фільтрувальний список з вердиктами
6. Експорт у CSV або детальний перегляд ділянки з усіма скріншотами поруч
-
Оброблено 3M+ записів актів: Дослідження власності від днів до хвилин
AI та машинне навчання
Ситуація
Засновник юридичної технології, що базується в США, створював платформу для дослідження нерухомості для адвокатів з нерухомості: юристів, які шукають недооцінені земельні ділянки як інвестиційні можливості для своїх клієнтів. Їхня робота залежить від знаходження специфічної мови, захованої в записах про право власності, такої як сервітути, обмеження, права доступу та положення про межі.
Перед цим проектом знаходження правильних ділянок означало ручний пошук у DataTree та базах даних округів, читання окремих PDF-документів про право власності та перехресне посилання з податковими картами, даними зони та демографічними даними на окремих вкладках. Один кваліфікований лід міг займати дні. Деякі питання не можна було відповісти взагалі.
…
Проблема
Адвокати втрачали угоди, оскільки вартість дослідження була занадто високою. Кожну нерухомість потрібно було перевіряти вручну за критеріями ключових слів, а потім збагачувати геоданими та записами інфраструктури з чотирьох різних джерел. Засновник намагався використовувати ручні обхідні рішення та готові інструменти. Нічого не пов'язувало джерела. Нічого не фільтрувало за специфічною юридичною мовою, яку його клієнти повинні були знайти.
Питання полягало не в "чи можемо ми зробити це швидше?" А в "чи можемо ми зробити питання, на які раніше не можна було відповісти, такими, на які можна відповісти?"
Рішення
Я побудував платформу для інтелектуальної нерухомості з двома шарами.
Фронтенд - це React SPA, розгорнута на Vercel, де адвокати шукають, фільтрують і переглядають нерухомість. Кожен результат відкривається в детальному перегляді з історією права власності, обмеженнями розміру ділянки, податковими картами, інфраструктурою та демографічними даними округу, всі дані динамічно відображаються з бекенду Supabase з контролем доступу на рівні рядків.
Бекенд - це n8n як API. Замість того, щоб запускати n8n як "клей для автоматизації", я використовував його як виробничий API-інтерфейс для конвеєра обробки прав власності. Коли адвокат запускає пошук за ключовими словами, запит проходить через функцію Supabase Edge до вебхуків n8n. Конвеєр отримує записи про право власності з DataTree, фільтрує за юридичними ключовими словами, збагачує відповідності геоданими Zonomics, проводить аналіз за допомогою Claude (OpenRouter) і записує прогрес назад до Supabase в реальному часі. Адвокати бачать етапний прогрес, коли записи співпадають і збагачуються.
Ця архітектура надала засновнику бекенд, який повністю контролюється, легко модифікується і швидко розширюється: нові джерела даних або етапи аналізу доставляються за години, а не спринти. Щоб підтримати цю швидкість, я створив спеціальний набір інструментів Claude Code, який програмно керує робочими процесами n8n (створення, синхронізація та налагодження їх з технічних специфікацій на природній мові).
Технологічний стек: n8n, Supabase (PostgreSQL, Auth, Storage, Edge Functions), React 19, TypeScript, Vite, Vercel, DataTree API, Zonomics API, Claude API (через OpenRouter), OpenAI API, Google Maps Embed API, Node.js, Zod, Anthropic SDK
Результати
- 3M+ записів про право власності оброблено через конвеєр
- Дні до хвилин на кожен кваліфікований запит на дослідження
- Питання, на які раніше не можна було відповісти, тепер можна (багатоджерельні запити, які були економічно недоцільними вручну)
- Виробнича система активно використовується командою засновника, обслуговуючи юридичних клієнтів
- Бекенд повністю контролюється: нові джерела даних, ключові слова та етапи аналізу AI доставляються без перебудови
- Архітектурно підготовлено для microSaaS: система вже готується до зовнішнього доступу обмеженим набором адвокатів
Як це працює
1. Адвокат вводить критерії ключових слів (юридична мова, яка їм потрібна в актах) та географічний обсяг
2. Запит проходить через функцію Supabase Edge до вебхука n8n
3. Конвеєр n8n отримує відповідні записи про право власності з DataTree
4. Відповідності збагачуються геоданими Zonomics, податковими картами, інфраструктурою, демографічними даними
5. Claude аналізує кожен акт на релевантність; результати оцінюються та сортуються
6. Адвокат завантажує лише ті акти, які відповідають усім їхнім критеріям через підписані URL-адреси Supabase
-
30 AI агентів, 5 платформ, одна панель управління: автономна система контенту
AI та машинне навчання
Ситуація
Одинокий контент-стратег керував багатоканальним публікуванням: блог, LinkedIn, Dev.to, Hashnode та Telegram. Кожна стаття вимагала ручного дослідження, написання, перевірки якості, специфічного для платформи переформатування та індивідуального публікування через інтерфейс кожної платформи. Один матеріал споживав 4-6 годин перед виходом в ефір на всіх каналах.
Проблема
… Кожна платформа мала різні вимоги до формату: WordPress потребував HTML з кастомними типами постів, Dev.to використовував markdown з front matter, Hashnode вимагав GraphQL, LinkedIn видаляв markdown і накладав обмеження в 2,900 символів, Telegram використовував свій власний підмножину HTML. Адаптація однієї статті для п'яти платформ була нудною і схильною до помилок.
Не існувало зворотного зв'язку. Аналітика існувала в п'яти окремих панелях. Стратегічні рішення базувалися на інтуїції. Якість була непослідовною. Кожен етап залежав від доступності клієнта для ручного виконання.
Рішення
Я побудував автономну контент-систему з 30 спеціалізованими AI-агентами, організованими через ланцюги завдань BullMQ. Повний життєвий цикл контенту працює автономно: виявлення трендів → дослідження → написання → перевірка фактів → виявлення AI → оптимізація нейромаркетингу → адаптація до платформи → затвердження → публікація.
Архітектура конвеєра. Кожен контентний елемент проходить через налаштовувану послідовність агентів. Чотиристадійні ворота якості (перевіряючий факти → виявник AI → нейро-оптимізатор → рецензент) перевіряють кожен чернетку. Конвеєр зупиняється на воротах затвердження і сповіщає через інлайн-клавіатури Telegram або панель React.
Динамічні конвеєри. Послідовності агентів налаштовуються для кожного каналу або для кожного контентного елемента через інтерфейс перетягування. Три рівні пріоритету: переваги елемента → за замовчуванням каналу → за замовчуванням системи. Підтримується паралельне виконання агентів.
Багатоплатформне публікування. Обмеження символів LinkedIn накладається на трьох рівнях: підказка адаптера, перевірка виходу та цикл переписування на рівні видавця (повторно викликає AI для скорочення, до 3 спроб). WordPress публікує як кастомні типи постів з відформатованим HTML. Усі п'ять видавців працюють з однієї дії.
Зворотний зв'язок аналітики. Щотижневий конвеєр збирає метрики, генерує гіпотези про те, що працює, і автоматично запускає оновлення стратегії.
Технологічний стек: 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
Результати
- ~85% зменшення часу на статтю (4-6 годин → ~30 хвилин на нагляд)
- Одночасне публікування на 5 платформах з одного затвердження
- 30 AI-агентів з налаштовуваними конвеєрами та повним обліком витрат
- Чотиристадійні ворота якості для послідовної якості контенту
- Подвійний інтерфейс затвердження (панель React + Telegram бот)
- Зворотний зв'язок аналітики, який автоматично коригує контент-стратегію
- 606 автоматизованих тестів (одиничні, інтеграційні, E2E)
Як це працює
1. Виявлення. Cron-завдання виконують виявлення трендів та аналіз конкурентів
2. Створення. Агентів дослідження та написання створюють довгий контент
3. Ворота якості. Перевіряючий факти, виявник AI, нейро-оптимізатор, рецензент перевіряють чернетку
4. Адаптація. Адаптери платформ переформатовують відповідно до вимог кожного каналу
5. Затвердження. Клієнт переглядає через панель або Telegram, затверджує або відхиляє
6. Публікація. Видавці публікують на всіх вибраних платформах одночасно
Конвеєр повністю відновлюється. Він повторює з експоненційним зворотним зв'язком, продовжує з того місця, де зупинився.
-
37,000 записів мігрувало через 3 платформи за 2 тижні — нульові дані
Управління клієнтами та CRM
Повна міграція даних CRM для брокера медичного страхування Medicare: RadiusBob → GoHighLevel + HealthSherpa
---
Ситуація
Брокер медичного страхування Medicare з ~1,600 клієнтів здійснював операції через три роз'єднані системи: RadiusBob (старий CRM), GoHighLevel (новий CRM) та HealthSherpa Medicare (платформа для реєстрації). Агенти щодня вручну звіряли всі три системи — не було єдиного джерела правди, автоматизація була неможлива.
…
Проблема
Роки історії клієнтів зберігалися в RadiusBob: 1,593 контакти, 1,222 страхових полісів, 32,507 нотаток про взаємодію та 793 зв'язки між контактами. Це не був експорт CSV — це була повна реконструкція через три API з різними авторизаціями, обмеженнями швидкості та форматами даних.
Будь-яка втрата запису означала ризик невідповідності. Ручна міграція зайняла б місяці та призвела б до помилок на кожному етапі.
Рішення
Я створив відновлювальний конвеєр міграції на Python (Docker + Supabase як трекер стану синхронізації). Статус кожного запису відстежувався індивідуально — якщо процес зупинився на запису 500, він відновлювався на 501 без жодних дублікатів.
Дедуплікація контактів: GoHighLevel вимагає унікальних телефонів/електронних адрес, але RadiusBob дозволяв спільні номери (одружені пари). Конвеєр виявляв дублікати з відповідей помилок API, оновлював існуючі записи та генерував звіт (163 групи дублікатів) для перегляду клієнтом.
Відповідність HealthSherpa: стратегія з трьох проходів — спочатку за ID бенефіціара Medicare (найвища впевненість), потім за ім'ям + ДР/електронною адресою/телефоном, потім створення нових записів для невідповідних контактів. Кожне співпадіння зберігало пряме посилання на реєстрацію для доступу в один клік з GHL.
Записи полісів: схема користувацького об'єкта в GHL з 15 полями. Виявлено та оброблено не задокументовані особливості API через систематичне тестування.
32,507 нотаток: Паралельна обробка з 8 одночасними запитами API скоротила час імпорту з 9+ годин до ~1 години, залишаючись в межах обмежень швидкості.
793 зв'язки: Складено 10 типів зв'язків, що обробляють як двосторонні (чоловік і дружина), так і односторонні (батько-дитина) асоціації. 260 не відображених типів задокументовано для перегляду клієнтом.
Технічний стек: Python 3.11, Docker, Supabase (PostgreSQL), GoHighLevel API, HealthSherpa Medicare API, asyncio
Результати
- ~37,000 загальних записів мігрувало через 3 платформи
- 100% контактів імпортовано (1,593/1,593)
- 100% нотаток збережено (32,507/32,507)
- 99.3% полісів імпортовано (1,214/1,222)
- 8 разів швидший імпорт нотаток через паралельну обробку
- Нульова втрата даних — кожен імпортований запис мігрував з повною історією
- Доставка за 2 тижні від початку до завершення
- Посилання на реєстрацію Medicare в один клік на кожному записі клієнта
Як це працює
1. Витяг — витягти всі дані з API RadiusBob
2. Трансформація — нормалізувати формати, очистити дані, перевірити поля, дедуплікація
3. Завантаження — надіслати контакти до GHL, відповідність HealthSherpa через стратегію з трьох проходів
4. Зв'язок — створити записи полісів, прикріпити нотатки, побудувати асоціації зв'язків
5. Перевірка — звірка кількостей, звіт про дублікати, аудит валідації
Кожен етап є ідемпотентним і відновлювальним. Конвеєр може повторно виконуватись без дублікатів або втрати прогресу.
-
Автоматизація CRM - Автоматизація збору рахунків - ClickUp
Управління клієнтами та CRM
Компанія з будівельних послуг, що базується в США, обробляла понад 5,000 рахунків через Service Fusion — застарілу платформу з обмеженими можливостями налаштування та без вбудованого робочого процесу збору.
ПРОБЛЕМА
Бухгалтер витрачав приблизно 60 годин на місяць на ручну роботу: перенесення даних рахунків між системами, відстеження термінів сплати за пам'яттю, складання індивідуальних листів-нагадувань. Кожен лист займав 15 хвилин — збір інформації з кількох екранів, перехресна перевірка деталей роботи, ручне форматування повідомлень. Критичне обмеження: Service Fusion зберігає рахунки та клієнтів у окремих таблицях без прямого зв'язку. Персонал відстежував зв'язки через таблицю Робіт, що робило систематичне відстеження майже неможливим.
…
РІШЕННЯ
Три автоматизації, що працюють разом, зберігаючи Service Fusion як джерело істини:
• Уніфіковане відстеження: Оцінки + рахунки автоматично надходять у Smartsheet
• Система збору: 7 шаблонів електронних листів за етапом платежу (-2 дні, день 1, 7, 14, 31+). Один клік надсилає персоналізоване нагадування з назвою роботи, адресою, ID рахунка, сумою
• Авто-синхронізація: Оновлення кожні 30 хв. Сплачені рахунки автоматично закривають пов'язані завдання ClickUp
РЕЗУЛЬТАТИ
• 60 годин/місяць звільнено від ручної роботи
• Час на нагадування: 15 хв → 1 клік
• Перша можливість відстеження ставки збору
• Обробляє понад 5,000 рахунків без додаткового персоналу
Термін: 2,5 тижні (розробка + тестування)
-
n8n Автоматизація для оцінки роботи RSS
Управління клієнтами та CRM
Як повноцінний розробник, я створив систему автоматизації за допомогою n8n, яка працює кожні 5 хвилин для обробки нових вакансій. Робочий процес оцінює кожну вакансію за 10-бальною системою оцінювання на основі відповідності ключовим словам і навичкам. Вибрані вакансії автоматично надсилаються до каналу Discord і додаються до бази даних Notion. Теги керуються та оновлюються через HTTP-запити для точного відстеження. Як фронтенд-розробник, розробник React і веб-розробник, я спроектував ефективне та масштабоване рішення, повністю використовуючи можливості автоматизації n8n для оптимізації процесу.
-
n8n Автоматизація: Синхронізація завдань Worksection з угодами HubSpot
Управління клієнтами та CRM
Як розробник автоматизації n8n, я створив цю автоматизовану інтеграцію за допомогою n8n для з'єднання Worksection і HubSpot. Робочий процес спрацьовує на нових завданнях у Worksection, обробляє дані угод і автоматично створює нові угоди в HubSpot. Він також синхронізує контактні дані, оновлює завдання та забезпечує, щоб обидві системи залишалися узгодженими в реальному часі. Це рішення усуває ручний ввід даних, зменшує помилки та економить час для команди продажів. Проект демонструє мою експертизу в автоматизації API, робочих процесах n8n та складних інтеграціях.
-
n8n Автоматизація для Розумного Сортування Електронної Пошти та Бізнес-Процесів
Управління клієнтами та CRM
Як експерт з автоматизації n8n, я розробив розумну систему обробки електронної пошти для Gmail. Автоматизація використовує модель штучного інтелекту для класифікації вхідних електронних листів на категорії (комерційні, роздрібні, соціальні, важливі, інші), застосовує мітки, видаляє неприоритетні електронні листи з вхідних повідомлень і реєструє дії в Google Sheets для звітності. Це рішення допомагає бізнесу заощаджувати час і ефективніше управляти комунікацією. Завдяки моєму досвіду як розробника повного стеку, фронтенд-розробника, розробника на React і веб-розробника, я надаю надійні та масштабовані автоматизації на основі n8n, адаптовані до потреб бізнесу.
Активність
| Останні ставки 2 | Бюджет | Додано | Терміни | Ставка | |
|---|---|---|---|---|---|
|
Серія сторінки
2000 UAH
|
|||||
|
адаптивная верстка сайта
5000 UAH
|
