# Ігор Бартєнєв


Архітектор ПЗ / Технічний лідер · Польща

2026-09-27 · [bartenev.site](https://bartenev.site/uk/)

Python · FastAPI · PostgreSQL · Elasticsearch · Redis

Архітектор ПЗ і технічний лідер із практичною розробкою у commerce, автоматизації бізнесу та інфраструктурі AI-агентів. Перетворюю вимоги на моделі даних, модульні backend-сервіси й інтеграції та доводжу рішення до реалізації. Досвід виробництва й ERP допомагає пов’язувати програмні рішення з реальною роботою людей.

## Ключовий досвід


### Onlihub · Початок у лютому 2022


Lead Developer · архітектура й технічна відповідальність

Приєднався до наявної платформи другим розробником; після відходу ліда взяв технічну відповідальність. Перебудував архітектуру застосунку й БД, координував невелику міжфункціональну команду та працював із CEO над реалізовністю й запуском.

Реалізовував backend-сервіси для каталогів постачальників, лістингів, залишків, замовлень і виконання. Моделював зовнішні ідентифікатори та правила синхронізації для систем із різними даними й циклами оновлення.

### Artekom · Січень 2020 - лютий 2022


1C-розробник → Python-продукти й автоматизація

Поєднував облік, сайти й API в 1C; у 2021 перейшов до Python-продуктів. Створював процеси Telegram → ERP і настільний торговий термінал із backtesting стратегій та виконанням операцій на біржі.

### Technopark Pozh Tekhnika · 2013 - січень 2020


Інженерія виробництва → ERP-автоматизація

Проєктував деталі, оснащення та процеси ЧПК для серійного виробництва. З лютого 2019 впроваджував і розвивав 1C для матеріалів, планування виробництва, звітності та зарплати.

## Приклади інженерної роботи


### Налаштовувані бізнес-процеси


Спроєктував і створив платформу для роботи іпотечної компанії разом з Encompass. Налаштовувані анкети, OCR документів, завдання й правила нарахувань поєднали клієнтські заявки з внутрішніми операціями. Клієнти відповідали один раз і бачили потрібні документи; працівники отримували призначені завдання з меншою ручною координацією.

[BOS](https://bartenev.site/uk/work/bos/)

### Масштабне збирання даних


Спроєктував паралельне сканування, координацію проксі й акаунтів, нормалізацію та пакетну обробку Elasticsearch. Архівний проєкт даних маркетплейсу обробляв мільйони лістингів близько п’яти місяців (історичний масштаб за моїм досвідом).

[Amazon Data / Trends](https://bartenev.site/uk/work/amazon-data/)

### Керований доступ AI-агентів до інструментів


Створив MCP Hub: пошук інструментів, схеми на запит, збережені результати й виконання з перевіркою прав; використовую щодня. Окрема open-source інтеграція Unity скоротила 48 видимих моделі інструментів до 6 зі збереженням 377 операцій. Порівняння схем опубліковано.

[MCP Hub](https://bartenev.site/uk/work/mcp-hub/) · [Unity MCP Efficient](https://bartenev.site/uk/work/unity-mcp-efficient/)

## Технічні інструменти


- Backend і дані: Python, FastAPI, SQL, PostgreSQL, Elasticsearch, Redis; каталог на Rust; складні запити, обмеження, тригери й TTL-кеш.

- Архітектура: Доменні моделі; модульні сервіси; порти й адаптери; документи, формули, права; ідемпотентність і відновлення.

- Інтеграції та виконання: REST, webhooks, OAuth, WebSocket; workers, черги, пакетні процеси; Docker, Linux і діагностика production.

- AI-інфраструктура: MCP, пошук інструментів та оркестрація; локальні embeddings і гібридний пошук; бюджети контексту, погодження й історія виконання.

## Освіта


Національний технічний університет «Харківський політехнічний інститут»
Диплом спеціаліста · Вересень 2008 — лютий 2014
Автоматизація та комп’ютерно-інтегровані технології

## Міждисциплінарний досвід


TON Tanks: продукт, backend і запуск гри Telegram / TON. Інші роботи: модульна техніка Unity, 3D-асети та експерименти з локальним AI для мовлення й документів.

## Компетенції


### Комерція та інтеграції


Каталоги, маркетплейси, склади, замовлення й виконання: спільна модель та межі між системами.

Архітектура й реалізація багатоканальних платформ

Спроєктував спільні моделі товарів, залишків і замовлень для Onlihub та MySellerHub, поєднавши канали з різними моделями складів і зовнішніми ідентифікаторами.

Amazon, Amazon SP-API, Amazon MCF, Shopify, eBay, Walmart, TikTok Shop, Etsy, Zenventory, Ysell, Onedaybundle, Warehouse integrations, Supplier integrations, Multichannel commerce, Canonical data models, Supplier catalogs, Products, SKU mapping, Variants, Listings, Categories, Attributes, Properties and values, Pricing policies, Shipping policies, Warehouses, Virtual warehouses, Inventory synchronization, Reservations, Overselling prevention, Customer orders, Supplier orders, Order routing, Fulfilment, Shipments, Tracking, Payment synchronization, External identifiers, Bidirectional synchronization, Webhooks, Scheduled synchronization, Polling, Callbacks, Retries, Rate limits, Partial failure recovery, Idempotency, Eventual consistency, State reconciliation, Barcode identification, ASIN identification, Product enrichment, Geodata, Route calculation, Estimated delivery time

[Комерція та інтеграції](https://bartenev.site/uk/expertise/#domain-commerce-integrations)

### Бізнес-системи


Для іпотечної компанії я поєднав клієнтські анкети з документами, OCR, завданнями працівників, нарахуваннями та Encompass. Налаштовувані форми й бізнес-правила дають спільному ядру підтримувати різні робочі сценарії.

Моделювання бізнесу, архітектура та власна розробка

Відповіді клієнта визначають наступні запитання й потрібні документи. OCR переносить значення із файлів у поля; події документів призначають учасників і завдання. Працівники користуються власними Kanban-дошками, а записи та вибрані статуси передаються в Encompass. Розрахунки й нарахування зберігають зв’язки з джерелами.

Business process modelling, Domain modelling, ERP, 1C, 1C УТП, 1C УНФ, Business accounting, Production planning, Material norms, Material consumption, Procurement, Stock accounting, Stock movements, Cost accounting, Payroll, Expenses, Transport logistics, Reporting, Inter-system exchanges, BOS, CRM, BPM, Organizations, Departments, Users and memberships, Roles and permissions, Workflow, Pipelines, Stages, Processes, Tasks, Operation sequences, Dynamic documents, Conditional forms, Document OCR, Encompass, Kanban, Task assignment, Document types, Multi-step forms, Dynamic fields, Nested fields, Repeatable fields, Calculated fields, Document relationships, Templates, Formula engines, Calculators, Printable forms, File management, Email integration, Email templates, External mailboxes, Notifications, Event-driven automation, Audit history, Salaries, Hourly compensation, Piece-rate compensation, Stripe, Wise, Subscriptions, One-time payments, Checkout, Shopping carts, Payment statuses, Payment webhooks, Transaction ledgers, Transaction categories, Transaction types, Recalculations, Statements, PDF statements, Financial movements, Financial invariants, Document-driven accounting, Transactions, Constraints, Triggers

[Бізнес-системи](https://bartenev.site/uk/expertise/#domain-business-systems)

### Бекенд, дані та парсинг


Масовий парсинг із паралельною обробкою та пулами проксі; пакетне читання й запис в Elasticsearch; окремі шляхи БД, кешу, читання та воркерів.

Архітектура, реалізація та оптимізація продуктивності

Amazon data: паралельне збирання й пакетні операції Elasticsearch. Catalog: читання на Rust, резервний Python і кеш Redis. Onlihub: бізнес-модулі з явними прикладними контрактами, портами репозиторіїв та інфраструктурними адаптерами.

Python, SQL, Rust, C++, FastAPI, Pydantic, asyncio, Multiprocessing, Multithreading, Background processing, Workers, Queues, Batch processing, Schedulers, Service architecture, REST, GraphQL, WebSocket, OAuth, External APIs, Internal APIs, Service-to-service communication, Event processing, Callbacks, Polling, Modular architecture, Module boundaries, Ports and adapters, Dependency inversion, Composition root, PostgreSQL, Elasticsearch, Redis, SQLite, Transactional storage, Search models, Read models, Cache layers, Complex SQL, CTE, Dynamic queries, Aggregations, Full-text search, Execution plans, Indexing, Bulk operations, Bulk indexing, Bulk reading, Transactions, Triggers, Constraints, Data migrations, Large relational schemas, Selenium, BeautifulSoup, Scrapy, Requests, Proxy pools, Proxy rotation, Multi-account parsing, Anti-blocking strategies, Parallel scraping, Data normalization, Deduplication, Data enrichment, Task distribution, Error monitoring, Retry strategies, Request throttling, XLS / XLSX / CSV ingestion, Import monitoring, Processing statuses, Docker, Linux, Git, CI/CD, GitHub Actions, Reverse proxies, Load balancing, Rate limiting, SSH, VPN, Proxy infrastructure, Logging, Monitoring, Bottleneck analysis, Pandas, NumPy, Numba, Matplotlib, PyQt5, PowerBI, yfinance, QThread, Thread, Market data, Charting, SMA, EMA, MACD, TMA, RSI, Backtesting, User-defined trading strategies, Live exchange execution, Commissions, P&L, Results persistence

[Бекенд, дані та парсинг](https://bartenev.site/uk/expertise/#domain-backend-data)

### Інфраструктура ШІ


MCP Hub поєднує пошук інструментів, локальні embeddings і повторне використання методів із керованою роботою з базами даних, логами, завданнями й комунікаціями.

Архітектура та власна розробка інфраструктури агентів

Реалізував гібридний пошук знань, опціональне локальне переранжування методів і зворотний зв’язок щодо досвіду. Схеми на запит, збережені результати, спільні бюджети runner та запуски автоматизацій у БД допомагають керувати виконанням і контекстом.

LLM APIs, Local LLMs, Lightweight models, CPU-first inference, MCP, FastMCP, Tool calling, Tool discovery, Tool RAG, Schemas on demand, Progressive disclosure, Agent orchestration, Specialized agents, Subagents, Agent workflows, Context management, Context compression, Context budgets, Execution memory, Memory, Embeddings, Vector search, Semantic retrieval, RAG-like retrieval, Hybrid retrieval, FTS5, SentenceTransformers, CrossEncoder, Reranking, Reusable methods, Learning feedback, Result handles, Shared budgets, Operation claims, Persistent task runs, Lease recovery, Cron, Event triggers, Human approval, Permission boundaries, Project isolation, Audit, Batch execution, Bounded results, Stored results, Execution receipts, Idempotency, Retry semantics, Duplicate mutation protection, Asynchronous operations, State inspection, Unity domain reload, RU/EN tool search, Schema context measurement, Slack integration, Teamwork integration, Telegram integration, Database tools, Log inspection, OCR, Document recognition, Speech recognition, Transcription, TTS, Whisper, Sherpa-ONNX, Silero, ONNX, GGUF, Speech pipelines, Multilingual processing, Meeting action extraction, AI data enrichment, Product categorization

[Інфраструктура ШІ](https://bartenev.site/uk/expertise/#domain-ai-infrastructure)

### Технічне лідерство


Почати з мети бізнесу, знайти рішення й реалізувати його в коді. Моя робота поєднує архітектуру, обговорення варіантів із замовниками, власну розробку та координацію там, де цього потребує проєкт.

Відповідальність за рішення, архітектуру та реалізацію

Для BOS я запропонував і розробив рішення, обґрунтував його архітектуру перед бізнесом і доопрацьовував під реальні процеси. В Onlihub перейняв архітектуру, БД, backend та інтеграції після виходу lead-розробника, координував розробку й консультував CEO щодо здійсненності.

Technical ownership, Hands-on architecture, Architecture decisions, Business discovery, Customer collaboration, Process formalization, Domain modelling, Database design, Backend development, Integration design, Engineering trade-offs, Technical communication, Cross-functional coordination, Task allocation, Delivery, Product development, Product concepts, Product launch, Product promotion, Production debugging, Bottleneck analysis, System evolution

[Технічне лідерство](https://bartenev.site/uk/expertise/#domain-technical-leadership)

### Промислова інженерія


Виробництво, CAD/CAM і ЧПК дали основу: зрозуміти матеріали, операції та обмеження перед автоматизацією.

Промислова інженерія та автоматизація виробництва

Готував деталі, програми обладнання й документацію для серійного виробництва; оптимізував операції та матеріали, згодом автоматизував планування виробництва й облік у 1С.

Manufacturing process modelling, Part design, Assembly design, CAD, CAM, CAD/CAM, CATIA, SolidWorks, AutoCAD, CNC, FeatureCAM, CNC Cad, Sheet metal, Nesting, Cutting, Turning, Milling, Coordinate punching, Turn-mill machines, Machine programs, Postprocessors, Tooling, Materials, Material consumption, Operation sequencing, Technical documentation, Production launch, Serial production, Process bottlenecks

[Промислова інженерія](https://bartenev.site/uk/expertise/#domain-engineering-foundations)

### Ігри та 3D


Самостійні продукти: ігровий бекенд, TON, фізика Unity, модульна техніка, процедурні світи та 3D-асети.

Власні продукти та розробка ігрових систем

Керував розробкою TON Tanks, створював бекенд та ігрову логіку. Власний проєкт на Unity досліджує модульні танки, фізику гусениць, пошкодження й процедурні міста.

Unity, C#, Game backends, Game logic, Game balance, Progression, Rewards, Telegram integration, TON, Blockchain transactions, NFTs, NFT economy, Minting, Ownership, Trading, Marketplace mechanics, Modular vehicle architecture, Vehicle assembly, Independent modules, Damage systems, Physics, Tracked vehicle mechanics, Shooting, Multiplayer experiments, PvP, PvE, Capture zones, Football mode, Procedural environments, Procedural city generation, Vegetation, Game optimization, Blender, 3D modelling, Hard-surface modelling, Materials, Textures, Game-ready assets, Asset optimization, Engine audio banks, Physical engine simulation, Audio generation

[Ігри та 3D](https://bartenev.site/uk/expertise/#domain-games-3d)

## Проєкти


### Onlihub


Технічна відповідальність за commerce-платформу

Lead Developer · архітектура, реалізація та розвиток

Я взяв на себе технічну відповідальність за розвиток платформи, що поєднує постачальників, товари, маркетплейси та виконання замовлень.

[Onlihub](https://bartenev.site/uk/work/onlihub/)

**Підключення магазину — більше ніж API-виклик**

Ілюстративний розбір реалізації

Продавець підключає канал продажів. Провайдер може відповідати повільно, а запит — надійти повторно. Застосунок має знати, що замовлено, хто це обробляє і чи завершена операція.

1. Перевірити власника магазину та можливості інтеграції.

2. Зберегти запит підключення з ключем ідемпотентності та записом outbox.

3. Передати задачу воркеру, продовжувати строк володіння та фіксувати завершення або помилку.

**Що це дає**
Запит підключення має збережений життєвий цикл і не залежить від одного довгого HTTP-запиту. Повтори та вичерпані спроби обробляються явно.

**Рішення та компроміс**
Поточна реалізація зберігає намір операції та володіння задачею в PostgreSQL, обмежує паралельність і перевіряє lease. Це дає відновлення, але додає керування станом і фонову обробку. Доставка — at least once: зовнішня дія потребує ідемпотентності або звірки; локальний токен не гарантує одноразове виконання в іншому сервісі.

**Задача**
Торговельні операції мали залишатися узгодженими між різними моделями товарів, складами та зовнішніми системами.

**Як я це реалізував**
Після відходу lead-розробника я очолив розробку та перебудував архітектуру застосунку й бази даних. Реалізував асинхронний backend на FastAPI, складні запити PostgreSQL та інтеграції торговельних і складських систем, водночас координуючи команду й консультуючи CEO щодо реалізовності ідей.

**Результат**
Робота охопила життєвий цикл товару від каталогу й залишків до замовлень, виконання та відстеження, з відповідальністю за систему загалом.

**Від розробника до технічного керівника**
Я приєднався до стартапу поруч із досвідченим lead. Після його відходу взяв відповідальність за архітектуру, базу даних і backend, координував невелику міжфункціональну команду та вів продукт через реалізацію, підтримку й подальший розвиток. Обговорення з CEO пов’язували бізнес-ідеї з технічною реалізовністю та рішеннями щодо розробки.

**Спільна модель різних каналів**
Початкова платформа проєктувалася під ширший multichannel-сценарій: товар з одного джерела можна опублікувати в іншому каналі. Я працював з Amazon, Walmart, eBay, TikTok Shop, Shopify та складськими інтеграціями, узгоджуючи товари, зовнішні ідентифікатори, реальні й віртуальні склади, залишки, замовлення та tracking. Цей початковий задум згодом став основою появи MySellerHub.

**Асинхронні сервіси та складний SQL**
Я створював і документував API на FastAPI з асинхронною обробкою, потоками та керуванням чергами. Робота з PostgreSQL охоплювала динамічні запити й оптимізацію великих наборів даних. Інструменти повторюваних завдань, парсери та аналіз у PowerBI доповнювали backend і підтримували інтеграційні та операційні процеси.

**Архітектура, що змінювалася разом із продуктом**
Платформа розвивалася в пов’язані продукти з різними завданнями: операції постачальників, роботу ритейлерів і окремий високонавантажений каталог. Я займався і архітектурою, і реалізацією, зокрема підписками та разовими платежами. Згодом Onlihub з’явився серед інтеграцій Amazon MCF; це окрема віха продукту поряд із моєю інженерною відповідальністю.

**Моя відповідальність**
Я приєднався до наявної платформи в лютому 2022 другим розробником. Після відходу ліда взяв відповідальність за архітектуру застосунку, БД і backend, координував невелику міжфункціональну команду та працював із CEO над реалізовністю й запуском.

- Спільна commerce-модель поєднує каталог, залишки, замовлення, виконання та tracking між системами різних каналів.

- API та фонова обробка підтримують інтеграції маркетплейсів і складів з узгодженням зовнішніх ідентифікаторів та станів.

**Публічні дані про продукт**

Опубліковані Onlihub числа описують заявлений масштаб платформи окремо від мого внеску й періоду роботи. Amazon вказує Onlihub серед інтеграцій MCF.

- 10,000+: магазинів у мережі платформи

- 40,000+: виконаних замовлень MCF

[Onlihub · показники продукту](https://onlihub.com/)

[Amazon · сторінка інтеграції](https://supplychain.amazon.com/integrations/onlihub)

Джерела перевірено: 2026-09-27

**Інструменти й технології**
Technical ownership, Hands-on architecture, Architecture decisions, Domain modelling, Database architecture, Database design, Backend architecture, Backend development, API integrations, Integration design, Inventory, Fulfillment, Reconciliation, Team coordination, Cross-functional coordination, Technical communication, Engineering trade-offs, Delivery, Product development, System evolution, Suppliers, Products, SKU, Variants, Attributes, Listings, Marketplaces, Warehouses, Reservations, Customer orders, Shipments, Tracking, FastAPI, Python, PostgreSQL, Complex SQL, Dynamic queries, Query optimization, asyncio, Multiprocessing, Multithreading, Queues, Recurring tasks, PowerBI, Selenium, BeautifulSoup, Requests, Scrapy, Multi-account parsing, Proxy pools, Amazon, Walmart, eBay, Etsy, TikTok Shop, Shopify, Zenventory, Ysell, Onedaybundle, API documentation, Virtual warehouses, Background workers, SKIP LOCKED, Outbox, Leases, Retries, Bounded concurrency, WebSocket, Redis Pub/Sub, Realtime delivery, Backpressure, Session authentication, Pillow, Image processing, Concurrency limits, WebP, HTTP caching, CDN, Modular architecture, Domain modules, Module boundaries, Application architecture, Ports and adapters, Repository ports, Dependency inversion, Dependency injection, Composition root, Contracts, Read models, Idempotency

- [Onlihub · торговельна платформа](https://onlihub.com/) — Публічний сайт продукту: запаси FBA, мережа продавців і виконання замовлень через Amazon MCF.

Продукт · Публічна сторінка · Посилання перевірено: 2026-09-27

- [Onlihub на сайті Amazon MCF](https://supplychain.amazon.com/integrations/onlihub) — Сторінка інтеграції на сайті Amazon описує передачу замовлень Onlihub до Multi-Channel Fulfillment.

Зовнішнє джерело · Публічна сторінка · Посилання перевірено: 2026-09-27

Підтверджує наявність інтеграції в каталозі, а не сертифікацію продукту чи його розробника.

- [Довідковий центр Onlihub](https://support.onlihub.com/) — Публічні інструкції, на які посилається сайт Onlihub.

Документація · Публічна сторінка · Посилання перевірено: 2026-09-27

### BOS / Business Operations System


Від анкети клієнта до іпотечних операцій

Проєктування рішення, архітектура та власна розробка

Я спроєктував і створив платформу операцій для роботи чинної іпотечної компанії. Клієнтські форми з умовними переходами, OCR документів, завдання працівників і правила нарахувань поєдналися з процесами в Encompass.

[BOS / Business Operations System](https://bartenev.site/uk/work/bos/)

**Одна анкета запускає робочий процес**

Використання в іпотечній компанії · за даними автора

Чинна іпотечна компанія опрацьовувала заявки в Encompass, а значну частину збору даних і координації виконувала вручну. Я створив BOS, щоб поєднати новий клієнтський сайт із людьми, документами й діями, потрібними для кожної заявки.

1. Відповісти один раз. Зайнятість, дохід і попередні відповіді визначають наступні запитання та потрібні документи. Працівники й ріелтори можуть самі налаштовувати такі форми.

2. Завантажити потрібні файли. Автоматизація створює пов’язані записи документів і завдання; OCR переносить значення в поля, щоб працівники працювали зі структурованою інформацією.

3. Просувати заявку далі. Учасники працюють зі своїми списками завдань і Kanban-дошками; документи, зовнішні ID та вибрані статуси передаються між BOS і Encompass.

**Що це дає**
Клієнти отримали зрозумілий шлях від відповідей до потрібних документів. Працівники отримували призначені завдання, скорочуючи ручну координацію передачі роботи. Компанія зберегла Encompass і отримала пов’язаний із ним прийом заявок та операційний процес.

**Рішення та компроміс**
Я зробив форми, схеми документів і бізнес-правила налаштовуваними, щоб зміни процесу не вимагали щоразу окремої логіки заявки в коді. Іпотечна конфігурація працює на перевикористовуваному ядрі. Гнучкість потребує явних умов, правил доступу й переходів стану. Розрахунки, дії за подіями документів та облік нарахувань залишаються окремими модулями з визначеними входами й результатами.

**Задача**
Компанія працювала в Encompass без сайту для подання клієнтських анкет. Працівники вручну збирали інформацію, визначали потрібні позичальнику документи й координували подальші дії. Зайнятість, дохід та інші обставини змінювали вимоги й ускладнювали опрацювання кожної нової заявки.

**Як я це реалізував**
Я запропонував рішення, обґрунтовував архітектурні рішення перед бізнесом і розробляв систему під реальні робочі сценарії. Налаштовувані форми визначають поля, кроки й потрібні документи за відповідями заявника. Події документів створюють завдання й призначають учасників; OCR заповнює поля із завантажених файлів. Окремі модулі відповідають за розрахунки, доступ, нарахування та обміни з Encompass. Ядро документів і правил проєктувалося для повторного використання поза іпотекою.

**Результат**
Компанія отримала сайт для клієнтських анкет, пов’язаний із внутрішніми операціями. Клієнти могли відповісти один раз і побачити потрібні документи; працівники отримували призначені завдання й працювали з пов’язаними записами, що передавалися в Encompass. Це спростило опрацювання заявок і скоротило ручну координацію.

**Форми, що враховують ситуацію заявника**
Працівники й ріелтори можуть налаштовувати форми для клієнтів. Відповіді визначають видимі й доступні поля, наступний крок та потрібні документи. Зайнятість і дохід можуть вести різними гілками, з урахуванням попередніх кроків. Завершена анкета запускає налаштовані дії з документами й завданнями.

**Завантажені документи стають робочими даними**
Клієнти завантажують файли до записів потрібних документів. OCR використовує компактну нейромодель для перенесення значень у поля; приватність документів була важливою вимогою до підходу. Налаштовувані колонки й поля дають змогу розширювати модель даних зі зміною вимог. Витягнуті значення використовуються в процесах документів, розрахунків і завдань.

**Робочі завдання кожного учасника**
Правила призначають учасників документів і створюють завдання для їхньої частини іпотечного процесу. Кожен має список завдань або Kanban-дошку; завдання можна перепризначити чи виконати повторно. Статуси завдань і документів відображають різні види прогресу. Шаблони повідомлень із параметрами адресуються користувачам або контактам.

**Зв’язок із чинним процесом в Encompass**
BOS обмінюється документами з Encompass, пов’язує зовнішні ID документів і вибрані статуси. Імпорт, експорт і синхронізація використовують зіставлення полів та записи інтеграційних задач, поєднуючи клієнтську анкету з чинною системою компанії. Передбачений сценарій інтеграції — крок, залежний від підпису: провайдер на кшталт PandaDoc може надати статус підписання перед продовженням процесу.

**Організації та доступ**
Іпотечний процес працює в моделі організацій, підрозділів, членства й ролей. Права поєднують дозволену дію з областю доступу та умовами щодо даних. Так доступ до документів відповідає обов’язкам людини в організації.

**Документи та форми зі станом**
Типи документів визначають типізовані поля, довідники та зв’язки батьківських і дочірніх документів. Багатокрокові форми підтримують вкладені й повторювані поля, зберігають відповіді та після завершення створюють або пов’язують документи. Очікувана версія в запиті дає змогу виявити застарілу зміну й повернути конфлікт.

**Розрахункові потоки**
Розрахунок поєднує атрибути документів, константи й попередні результати формул. Попередній перегляд показує значення та їхні джерела; запуск потоку створює документ із результатом. Один зі сценаріїв — розрахунок доходу для іпотеки. Друковані шаблони перетворюють дані документа на PDF.

**Нарахування, пов’язані з роботою**
Нарахування охоплюють фіксовану місячну суму, премії за закриті кредити та винагороду за досягнення документом учасника налаштованого статусу. Правила визначають отримувача й базу: фіксовані суми, відсотки, базисні пункти та ліміти. Внутрішні записи зберігають документ і правило походження, зокрема для утримань і рекомендацій; це облік винагород, а не банківський переказ.

**Моя відповідальність**
Я спроєктував і розробив BOS для чинної іпотечної компанії: уточнював потреби, пропонував варіанти, обґрунтовував архітектурні рішення та доопрацьовував реалізацію разом із бізнесом. Моя відповідальність охоплювала рішення та його код.

- Налаштовувані типи документів і багатокрокові форми збирають пов’язані дані. Окремі розрахункові потоки показують результати формул або створюють нові документи.

- Області доступу й правила подій керують діями з документами. Нарахування за статусом зберігають посилання на документ і правило, а записи транзакцій мають перевірки в БД.

**Інструменти й технології**
Domain modelling, Business process modelling, BOS, CRM, BPM, Organizations, Departments, Users and memberships, Roles & permissions, Roles and permissions, Pipelines, Stages, Processes, Workflow, Tasks, Operation sequences, Dynamic documents, Document types, Dynamic fields, Nested fields, Repeatable fields, Calculated fields, Document relationships, Templates, Formula engine, Formula engines, Calculators, Printable forms, File management, Email automation, Email integration, Email templates, External mailboxes, Notifications, Event-driven automation, Compensation models, Salaries, Financial movements, Conditional forms, Document OCR, Encompass, Kanban, Task assignment, Transactions, Audit history, External APIs, Python, FastAPI, PostgreSQL, Multi-step forms, Divisions, Data modelling, Foreign keys, Constraints, Triggers, Document hierarchy, Background workers, SKIP LOCKED, Outbox, Leases, Retries, Bounded concurrency

### MCP Hub


Оркестрація агентів, знання проєктів і повторне використання досвіду

Інфраструктура агентів та архітектура інтеграцій

Я створив сервіс, у якому агенти знаходять інструменти й знання проєктів, працюють із підключеними системами та зберігають корисні методи для наступних завдань.

[MCP Hub](https://bartenev.site/uk/work/mcp-hub/)

**Розбір розбіжності між підключеними сервісами**

Ілюстративний розбір реалізації

Уявімо агента, що з’ясовує розбіжність залишків і готує задачу для її вирішення. Йому потрібні дані підключених сервісів, достатній контекст і чітка межа перед внесенням змін.

1. Знайти потрібні інструменти в дозволеному каталозі й завантажити лише їхні точні схеми.

2. Читати в межах спільного бюджету; зберігати великі відповіді як артефакти з прев’ю.

3. Перевірити права дії, отримати погодження за потреби та зберегти результат виконання.

**Що це дає**
Агент отримує цільовий робочий контекст, а оператор може перевірити дію, рішення про доступ і збережений результат. Погодження прив’язане до узгодженої дії та аргументів.

**Рішення та компроміс**
Вибірковий пошук додає крок, але не завантажує всі схеми інтеграцій у кожний запит. Прев’ю скорочують поточний контекст; повні артефакти потрібно запитувати окремо, і вони мають строк зберігання. Невідомий результат зовнішнього запису залишається невідомим — не стає успіхом чи сліпим повтором.

**Задача**
Операційні питання охоплюють кілька систем, тоді як широкий доступ до БД і постійне зростання каталогу інструментів створюють проблеми прав та контексту агентів.

**Як я це реалізував**
Я поєднав схеми інструментів на запит, виконання в межах прав і збережені результати з локальними embeddings, повнотекстовим пошуком та повторним використанням методів. Власний runner агентів розподіляє спільні бюджети між делегованими завданнями; автоматизації зберігають запуски й стани погодження. Знання, спостережені виклики та зворотний зв’язок розділені, щоб наступні завдання могли використовувати досвід з урахуванням його контексту.

**Результат**
Я використовую MCP Hub для дослідження помилок, огляду комунікацій та аналізу активності проєктів у БД, логах і робочих інструментах. Потрібні схеми, збережені результати й попередні методи можна відкривати в міру потреби, зосереджуючи повторні дослідження на завданні.

**Знайти операцію, потім отримати її схему**
Пошук інструментів повертає короткі результати з підказками аргументів, відомостями про ризик і посиланням на схему, що перевіряється під час виклику. Агент запитує точну схему вибраної операції, потім викликає її за назвою. Повний каталог інтеграцій залишається поза промптом, а шлях від наміру до актуального контракту інструмента — явним.

**Локальні embeddings і гібридний пошук**
Знання проєктів поєднують FTS5 з локальними embeddings SentenceTransformer. Потоковий перегляд векторів відбирає ID найкращих фрагментів до завантаження їхнього вмісту; хеші дозволяють не векторизувати незмінений текст. Для повторно використовуваних методів є окремий шлях: семантичний і лексичний відбір, після якого опціональний локальний CrossEncoder оцінює відповідність завданню.

**Межі проєкту й підтвердження виконання**
Дослідження кількох систем починається з дозволених проєктів, ресурсів та операцій. У цих межах можна аналізувати записи БД, логи й комунікації. Виклики, що потребують погодження, очікують рішення людини. Підтвердження виконання пов’язують спостережені результати з поточним запуском, а аудит зберігає дії та допомагає перевірити підсумковий висновок.

**Методи, що зберігають контекст і зворотний зв’язок**
Агент може зберегти мету, умови застосування, план викликів із розгалуженнями та висновки з невдалих спроб. Наступні завдання отримують невелику добірку методів, які можна використати, адаптувати або пропустити. Оцінка корисності й підтверджений успіх залишаються окремими сигналами. Навчання накопичує та уточнює досвід; незмінене повторне використання зберігає наявний метод і його embedding.

**Спільне керування делегованою роботою**
Вбудований runner агентів використовує спільний контролер токенів, викликів моделей, спроб інструментів, workers і паралельності для делегованої роботи. Строк виконання й скасування діють на дерево запусків, а резервування операцій відстежує запити, що перетинаються. Так оркестрація зберігає спільний бюджет і явну відповідальність за виконання, коли агенти ділять завдання.

**Автоматизації зі збереженням запусків**
Тригери cron, interval та event запускають операцію інструмента або багатокроковий процес агента. Стан запусків зберігається в SQLite; workers беруть роботу із зазначенням власника та lease, а прострочені lease можна відновити. Очікування погодження має явний стан. Регулярні перевірки активності проєктів і комунікацій використовують той самий керований інтеграційний шар.

**Зберігати результати й компактний контекст**
Результати зберігаються зашифрованими; доступ за ідентифікатором враховує власника, строк дії та версію політики. Фрагменти знань читаються вибірково, пакети пам’яті обмежують кількість записів і символів. Короткі описи методів ведуть до великих планів, а невеликі плани містять умови одразу. Агент може повертатися до деталей без копіювання кожної вихідної відповіді в розмову.

**Моя відповідальність**
Я спроєктував і створив інтеграційний шар та власний runtime агентів: пошук інструментів, знання проєктів, контроль виконання й повторне використання досвіду.

- Локальні embeddings і гібридний пошук знаходять доречні знання. Схеми інструментів і збережені результати відкриваються за потреби, зберігаючи фокус робочого контексту.

- Агенти й постійні автоматизації використовують виконання в межах прав, погодження, записи результатів і бюджети. Завершена робота може явно доповнювати методи; ваги моделі не навчаються.

**Інструменти й технології**
MCP, Tool discovery, Agent orchestration, Permissions, Permission boundaries, Human approval, Approval flows, Audit, Project isolation, Stored results, Context management, Context optimization, Automation, Knowledge retrieval, Slack, Teamwork, Telegram, Databases, Logs, Email integration, Internal services, Cross-system investigation, Bounded database operations, Log analysis, Tool RAG, Progressive disclosure, Context efficiency, Execution memory, Project knowledge, Reusable experience, Cross-project context, Recurring automations, User journey investigation, Embeddings, Hybrid retrieval, Reusable methods, FTS5, Vector search, SentenceTransformers, CrossEncoder, Reranking, Learning feedback, Schemas on demand, Schema references, Result handles, Execution receipts, Context budgets, Shared budgets, Operation claims, Subagents, Cron, Event triggers, Persistent task runs, Lease recovery

### Amazon Data / Trends


Масштабний парсинг Amazon та аналіз тенденцій

Архітектура збору й обробки даних

Я спроєктував і реалізував сервіс даних Amazon, що сканував категорії маркетплейсу, крім книг, і використовував пакетну обробку Elasticsearch для пошуку тенденцій.

[Amazon Data / Trends](https://bartenev.site/uk/work/amazon-data/)

**Від розрізнених лістингів до придатного набору даних**

Історичний процес · за даними автора

Для вивчення товарних тенденцій за категоріями збір і зберігання мали працювати разом. Завантаження сторінок було лише першим кроком: неоднорідним записам потрібні спільне подання й ефективний шлях до аналізу.

1. Паралельно збирати дані категорій, координуючи акаунти, проксі, частоту та повтори.

2. Нормалізувати записи перед пакетною індексацією в Elasticsearch.

3. Читати групи записів для аналізу замість окремого запиту до сховища для кожного лістингу.

**Що це дає**
Набір даних за категоріями підтримував аналіз тенденцій. Архівний сервіс обробляв мільйони лістингів близько п’яти місяців; це наведений мною історичний масштаб, не поточний benchmark пропускної здатності.

**Рішення та компроміс**
Пакетний підхід охоплював і запис, і читання, зменшуючи кількість окремих звернень до сховища. Компроміс — дані стають доступні групами, а не миттєво по одній позиції. Повнота й актуальність залежать від зовнішнього джерела; розмір набору не доводить точність тенденції чи прогнозу.

**Задача**
Ширина каталогу вимагала паралельного збору й стратегії зберігання для мільйонів оголошень, без окремого читання чи запису для кожної позиції.

**Як я це реалізував**
Паралельні парсери поєднували керування обліковими записами й proxy, обмеження частоти та повторні спроби під час сканування категорій. Я організував нормалізацію й роботу з Elasticsearch навколо пакетних записів і читань, зберігаючи пакетний підхід зі зростанням даних. Результат використовувався для аналізу змін і тенденцій.

**Результат**
Сервіс працював близько п’яти місяців в історичному масштабі порядку мільйонів оголошень. Він підтримував аналіз тенденцій за категоріями, після чого команда змінила фокус, а проєкт було архівовано.

**Історичне охоплення категорій**
Проєкт сканував категорії Amazon по каталогу, свідомо виключаючи книги. Історичний обсяг даних був порядку мільйонів оголошень. Такий охват поєднував збір, нормалізацію та зберігання в одне завдання: дані категорій мали стати узгодженим набором для пакетного аналізу.

**Збір за зовнішніх обмежень**
Парсери мали враховувати блокування, кілька облікових записів, proxy та невдалі запити. Паралельна обробка, обмеження частоти й повтори були частиною архітектури збору. Нормалізація давала індексації та аналізу узгоджене подання попри відмінності зібраних даних.

**Пакетний запис і читання**
Elasticsearch використовувався і для пакетного запису, і для пакетного читання. Пакети були важливі з обох боків: зібрані записи індексувалися разом, а аналіз отримував групи записів, щоб навантаження не складалося переважно з поодиноких запитів. Це рішення визначало шлях даних нарівні з вибором пошукового рушія.

**Аналіз тенденцій і завершений етап продукту**
Метою збору було виявлення змін і тенденцій у товарних даних. Сервіс працював приблизно п’ять місяців, після чого пріоритети змістилися на іншу роботу. Архівний проєкт поєднує повний інженерний ланцюжок: паралельний збір, нормалізацію, пакетний доступ до сховища та аналіз великого історичного набору даних.

**Моя відповідальність**
Я спроєктував і реалізував шлях від збору до аналізу: паралельний збір, нормалізацію та пакетний доступ до Elasticsearch.

- Паралельні парсери враховують помилки запитів і зовнішні обмеження через контроль частоти та повтори; нормалізація готує узгоджений набір даних.

- Індексація й аналіз працюють пакетами, тому шлях даних не залежить від окремого запиту до сховища для кожного оголошення.

**Історичний масштаб · за даними автора**

Сервіс працював близько п’яти місяців з історичним обсягом порядку мільйонів оголошень. Він підтримував аналіз тенденцій категорій до архівування проєкту.

**Інструменти й технології**
Data acquisition, Parallel processing, Parallel scraping, Proxy management, Proxy rotation, Multi-account parsing, Retries, Retry strategies, Throttling, Request throttling, Normalization, Data normalization, Elasticsearch, Bulk indexing, Bulk writes, Bulk reads, Bulk reading, Trend analysis, Amazon category scanning, Large datasets, Historical data analysis, Index structures, Bulk operations, Search/read models, Data pipelines

### Liqsale / Daily Snipes


Від прайсів постачальників до маркетплейсу

Архітектура продукту й обробка даних

Я побудував процес, що перетворює розрізнені пропозиції розпродажу залишків на структуровані товарні оголошення з пошуком.

[Liqsale / Daily Snipes](https://bartenev.site/uk/work/liqsale/)

**Задача**
Покупці вручну переглядали неузгоджені таблиці та листи з неповними даними про товари.

**Як я це реалізував**
Я поєднав імпорт листів і таблиць із нормалізацією, ідентифікацією за штрихкодом або ASIN та збагаченням із зовнішніх джерел. AI допомагав структурувати неповні дані й визначати категорії, а оператори бачили стани обробки та помилки.

**Результат**
Файли постачальників стали оголошеннями, пов’язаними з цінами, залишками та складами, у продукті з покупцями, продавцями, чатами й замовленнями.

**Інструменти й технології**
Data ingestion, XLS / XLSX / CSV, XLS / XLSX / CSV ingestion, Email ingestion, Data normalization, ASIN, ASIN identification, Barcode identification, AI enrichment, Product enrichment, Data enrichment, Categorization, Catalog architecture, Supplier catalogs, Categories, Attributes, Listings, Warehouses, Inventory, Prices, Orders, Chats, Admin panel, Import monitoring, Processing states, Processing statuses, Error handling

- [Liqsale · оптовий каталог](https://liqsale.com/) — Публічний каталог оптових товарів і залишків з інформацією про продукти та склади.

Продукт · Публічна сторінка · Посилання перевірено: 2026-09-27

- [Daily Snipes · каталог](https://dailysnipes.com/) — Та сама лінійка оптових продуктів під назвою Daily Snipes, яка також зазначена на сайті Liqsale.

Продукт · Публічна сторінка · Посилання перевірено: 2026-09-27

### Unity MCP Efficient


Менший інтерфейс інструментів із доступом до повного каталогу операцій

Проєктування й реалізація фасаду

Я створив шар сумісності, що дає агентам змогу знаходити операції Unity без завантаження всіх схем інструментів у контекст.

[Unity MCP Efficient](https://bartenev.site/uk/work/unity-mcp-efficient/)

**Задача**
Великий видимий моделі набір інструментів займав контекст ще до вибору потрібної операції.

**Як я це реалізував**
Я відокремив пошук від виконання: схеми операцій завантажуються за потреби, а розмір відповідей обмежений. Пакетне виконання, збережені результати, квитанції та ідемпотентні повтори враховують дублювання змін, асинхронну роботу й перезавантаження домену Unity.

**Результат**
Опубліковане авторське порівняння від 24 серпня 2026 з upstream v10.1.0 показує 48 → 6 видимих моделі інструментів і доступ до 377 операцій. Контекст схем зменшився з 23 280 до 915 оцінених токенів (символи ÷ 4); це документована оцінка, а не незалежно відтворений тест швидкості чи вартості.

**Моя відповідальність**
Я спроєктував і реалізував фасад сумісності, відокремивши пошук операцій від виконання та надаючи схеми за потреби.

- Компактний видимий моделі інтерфейс зберігає пошук і доступ до повного каталогу операцій.

- Пакети, обмежені результати, записи виконання та обробка повторів підтримують асинхронну роботу Unity й перезавантаження домену.

**Опубліковане авторське порівняння**

Порівняння в README від 24 серпня 2026 з upstream v10.1.0. Токени схем оцінено як символи ÷ 4; це вимір оголошень інструментів, а не всього контексту, швидкості чи вартості завдання.

- 23,280 → 915: оцінених токенів схем

- 48 → 6: видимих моделі інструментів

- 377: операцій залишаються доступними

[GitHub · порівняння й методика](https://github.com/Vangardo/unity-mcp-efficient#readme)

Джерела перевірено: 2026-09-27

**Інструменти й технології**
MCP, Tool discovery, RU/EN tool search, Schemas on demand, Context optimization, Bounded results, Batch execution, Stored results, Receipts, Idempotency, Retry semantics, Duplicate mutation protection, Unity domain reload, Asynchronous operations, State inspection, Compatibility layers

- [Unity MCP Efficient · GitHub](https://github.com/Vangardo/unity-mcp-efficient) — Відкритий код, інструкції налаштування й тести компактного MCP-фасаду для Unity.

Вихідний код · Публічна сторінка · Посилання перевірено: 2026-09-27

- [Unity MCP Efficient · методика вимірювань](https://github.com/Vangardo/unity-mcp-efficient/blob/main/BENCHMARKS.md) — Відтворювані вимірювання розміру схем інструментів і компактних результатів, із базовою версією та обмеженнями.

Документація · Публічна сторінка · Посилання перевірено: 2026-09-27

Зазначене скорочення стосується обсягу контексту, а не вартості API чи загальної швидкості роботи.

### MySellerHub


Спільна модель незалежних каналів продажу

Multichannel-архітектура та інтеграції

Я спроєктував backend-модель товарів, оголошень у каналах, замовлень і складів, пов’язавши оновлення залишків та виконання замовлень між зовнішніми платформами.

[MySellerHub](https://bartenev.site/uk/work/mysellerhub/)

**Задача**
Кожен канал по-своєму описував той самий товар і замовлення, тому синхронізація потребувала спільної предметної моделі.

**Як я це реалізував**
Я відокремив товари від оголошень у каналах і зіставив зовнішні ідентифікатори зі спільною моделлю. Операції Shopify як каналу продажу та постачальника мають окремі сценарії. Імпорт замовлень пов’язаний із призначенням складу, а синхронізація залишків відстежує цільову кількість, її версію та останнє надіслане значення.

**Результат**
Архітектура поєднала публікацію товару в іншому каналі з поверненням статусу його виконання; поточний публічний продукт акцентує Shopify та залишки Amazon.

**Канал продажу й постачальник**
Shopify може бути каналом продажу, що отримує товари й передає замовлення покупців, або постачальником, що надає каталог і виконує замовлення на закупівлю. Ці ролі мають окремі процеси навколо спільної моделі товарів та оголошень. Замовлення постачальнику містить локальний ідентифікатор для пошуку вже створеного зовнішнього замовлення.

**Залишок може змінитися під час оновлення**
Кожна ціль оновлення залишку має кількість і версію. Після надсилання worker перевіряє, чи версія ще актуальна. Якщо залишок устиг змінитися, запис залишається в очікуванні наступної спроби. Правила резерву та верхньої межі залишку коригують ціль до надсилання в канал.

**Продовження імпорту замовлення**
Імпортоване замовлення знаходиться за магазином, інтеграцією та зовнішнім ID, а його позиції зіставляються з оголошеннями. Наступна синхронізація може повторити призначення складу для наявних позицій та оновити виконання й tracking. Частково оброблене замовлення залишається в тій самій моделі.

**Моя відповідальність**
Я спроєктував multichannel commerce-модель і шляхи синхронізації оголошень, залишків, замовлень та виконання.

- Товари й ідентифікатори різних каналів узгоджуються у спільній моделі публікації та синхронізації залишків.

- Замовлення пов’язуються з відповідним джерелом виконання, а tracking повертається до початкового каналу.

**Публічні дані про продукт**

Поточний сайт продукту повідомляє цей показник каталогу. Його нинішня пропозиція відрізняється від ширшої multichannel-моделі, над якою я працював.

- 10,000+: товарів, готових до публікації

[MySellerHub · сайт продукту](https://mysellerhub.com/)

Джерела перевірено: 2026-09-27

**Інструменти й технології**
Multichannel commerce, Canonical data models, SKU mapping, Products, Listings, External identifiers, Inventory synchronization, Supplier orders, Customer orders, Order routing, Fulfillment, Tracking, Warehouses, Pricing policies, Bidirectional synchronization, Retries, Idempotency, Eventual consistency, Reconciliation, State reconciliation, Shopify, Amazon, eBay, Redis, JSON, TTL, Cache invalidation, OAuth, Webhooks, HMAC, State synchronization, Notifications, PostgreSQL, LISTEN/NOTIFY, Event signalling

- [MySellerHub · платформа продавця](https://mysellerhub.com/) — Огляд продукту: пошук товарів, синхронізація залишків і виконання замовлень.

Продукт · Публічна сторінка · Посилання перевірено: 2026-09-27

- [MySellerHub · Shopify App Store](https://apps.shopify.com/mysellerhub) — Сторінка опублікованого застосунку вказує Onlihub Inc. як розробника та описує інтеграції каналів продажів.

Зовнішнє джерело · Публічна сторінка · Посилання перевірено: 2026-09-27

- [Довідковий центр MySellerHub](https://help.mysellerhub.com/) — Інструкції з початку роботи, каталогів, лістингів, замовлень і доставки.

Документація · Публічна сторінка · Посилання перевірено: 2026-09-27

### Onlihub Catalog


Окремі шляхи даних для різних навантажень

Архітектура й реалізація сервісу каталогу

Я спроєктував і реалізував окремий сервіс каталогу Onlihub з основним шляхом на Rust, резервним на Python, кешуванням Redis та Elasticsearch.

[Onlihub Catalog](https://bartenev.site/uk/work/catalog/)

**Задача**
Великі набори оголошень і важкі запити потребували моделі читання, що відповідає способам доступу до даних.

**Як я це реалізував**
Я розділив швидкий шар обслуговування на Rust, резервний Python-шлях, кеш і пошук/читання з транзакційним сховищем. Балансування й обмеження частоти стримували повторний трафік, а пакетна обробка та оптимізація запитів працювали з важкими операціями над даними.

**Результат**
Пошук і часті читання отримали власний шлях, а транзакційне зберігання та бізнес-логіка зберегли окремі обов’язки.

**Окремий сервіс і визначені шляхи даних**
Каталог маркетплейсу став окремим сервісом із власною архітектурою обслуговування. Rust відповідав за основний швидкий шлях, поруч працював резервний Python-підхід. Я відповідав і за архітектуру, і за реалізацію, відокремлюючи навантаження каталогу від ширшого commerce-застосунку.

**Кеш, пошук і транзакції мають різні завдання**
Redis кешував дані для повторних читань, Elasticsearch забезпечував модель пошуку/читання, а PostgreSQL зберігав транзакційні обов’язки. Це розділяло отримання даних каталогу й зберігання бізнес-стану. Пакетні операції та оптимізація важких запитів доповнювали цей розподіл.

**Контроль повторного трафіку на вході**
Балансування й обмеження частоти були частиною дизайну сервісу. Клієнтів із надмірними повторними запитами можна було сповільнити до переважання їхнього трафіку. Керування запитами, кеш і швидкий шар обслуговування проєктувалися разом, враховуючи і надходження запитів, і спосіб читання даних.

**Інструменти й технології**
Rust, Python, PostgreSQL, Elasticsearch, Redis, Read models, Search models, Transactional storage, Caching, Cache layers, Bulk operations, Query optimization, Rate limiting, Request throttling, Load balancing, Backend performance, Python fallback, Index structures, Search/read models, Data pipelines

### Manufacturing Engineering


Фізичний процес, що стоїть за програмою

Технологічне проєктування та CAD/CAM

Мій інженерний фундамент — проєктування деталей, операцій обробки та процесів запуску виробів у виробництво.

[Manufacturing Engineering](https://bartenev.site/uk/work/manufacturing/)

**Задача**
Деталь мала вписатися у відтворюваний виробничий процес з реальними обмеженнями верстатів, матеріалів і послідовності операцій.

**Як я це реалізував**
Я працював із CAD/CAM-моделями, програмами CNC, постпроцесорами та технологічною документацією. Робота охоплювала розкрій листового металу, токарні й фрезерні операції, витрати матеріалів і підготовку серійного виробництва.

**Результат**
Ця робота сформувала мій підхід: зрозуміти реальний процес, визначити обмеження й лише тоді проєктувати автоматизацію.

**Інструменти й технології**
Manufacturing process modelling, Part design, Assembly design, CAD, CAM, CAD/CAM, CATIA, SolidWorks, AutoCAD, CNC, FeatureCAM, CNC Cad, Postprocessors, Sheet metal, Nesting, Cutting, Turning, Milling, Coordinate punching, Turn-mill machines, Machine programs, Materials, Material planning, Material consumption, Operation sequencing, Process optimization, Production launch, Serial production, Process bottlenecks, Technical documentation

### ERP / 1C


Перетворення операцій підприємства на облікову модель

Аналіз бізнесу та прикладна розробка

Я створював і підтримував рішення 1C для українських компаній, працюючи безпосередньо із замовниками над обліком, плануванням виробництва, витратами матеріалів і логістикою.

[ERP / 1C](https://bartenev.site/uk/work/erp/)

**Задача**
Бізнес-документи мали формувати коректні складські й фінансові рухи у взаємопов’язаних процесах підприємства.

**Як я це реалізував**
Я вивчав роботу підприємств і переводив її правила в документи, звіти, запити та інтеграції в 1C УТП/УНФ. Прикладні модулі охоплювали транспортну логістику й виробничі операції, норми матеріалів, собівартість та внутрішні обміни даними.

**Результат**
Цей досвід пов’язав програмні моделі з реальними залишками, грошима й операційними наслідками та став основою подальших фінансових і бізнес-систем.

**Зрозуміти компанію перед налаштуванням системи**
Я працював безпосередньо із замовниками, вивчаючи технологічні й адміністративні процеси, зокрема в проєктах із нуля. Спочатку з’ясовував реальний рух матеріалів, документів, залишків і грошей, а потім налаштовував облік та інтеграції. Операційна модель замовника визначала модель програми.

**Виробництво, матеріали та плани витрат**
Робота охоплювала планування виробництва, норми й витрати матеріалів, складські рухи, собівартість, зарплату та плани витрат. Виробничий досвід допомагав пов’язати цифри в 1C з операціями, що їх створюють. Звіти й складні запити робили цю інформацію придатною для планування та контролю.

**Прикладні модулі для реальних операцій**
Я розробляв модулі транспортної логістики й інструменти для прискорення або поліпшення виробничих операцій. Обміни даними та інтеграції поєднували ці модулі з рештою обліку компанії. Цей досвід заклав модель «документ → рух», яка згодом з’явилася у фінансових сервісах і бізнес-платформі на Python.

**Інструменти й технології**
1C, 1C УТП/УНФ, 1C УТП, 1C УНФ, ERP, Business analysis, Business discovery, Customer collaboration, Process formalization, Accounting, Business accounting, Production planning, Material norms, Material consumption, Procurement, Stock accounting, Stock movements, Cost accounting, Payroll, Expenses, Transport logistics, Reporting, Data exchange, Inter-system exchanges, Document-driven accounting, Complex queries

### Financial Systems


Платежі, документи та цілісність даних

Фінансове моделювання та інтеграції в різних проєктах

В Onlihub і Liqsale я створював підписки, разові платіжні сценарії та моделі транзакцій, пов’язані з виписками, перерахунками й бізнес-документами.

[Financial Systems](https://bartenev.site/uk/work/finance/)

**Задача**
Успішний callback платежу був лише частиною завдання узгодження балансів, станів транзакцій і бізнес-документів.

**Як я це реалізував**
Я працював зі Stripe та Wise, підписками, checkout, платіжними webhooks і PDF-виписками. Також проєктував моделі обліку транзакцій і досліджував забезпечення фінансових інваріантів через транзакції, constraints і triggers PostgreSQL.

**Результат**
Ця практика поєднує мій досвід ERP із сучасними платіжними системами: фінансові операції моделюються через явні стани, категорії та рухи.

**Платежі всередині торговельного процесу**
Моя робота в Onlihub і Liqsale включала підписки, разові платежі, кошики, checkout і синхронізацію статусів. Інтеграції Stripe та Wise були частиною фінансового процесу застосунку, пов’язуючи платіжні події із замовленням або підпискою клієнта та відповідними записами транзакцій.

**Модель транзакцій за виписками**
Я працював над типами й категоріями транзакцій, розрахунками, перерахунками та виписками, зокрема PDF. Ці записи описують зв’язок фінансових операцій зі станом застосунку й документами. Модель дає змогу простежити показані користувачу цифри до транзакцій і рухів, які їх сформували.

**Дослідження інваріантів у PostgreSQL**
Я досліджував перенесення частини фінансових правил у транзакції, constraints і triggers PostgreSQL, зокрема обмежень балансу та рухів від зміни статусу документа. Мета — явно описати важливі інваріанти на рівні даних. Захист балансу через тригери був напрямом експериментів у цій роботі.

**Інструменти й технології**
Stripe, Wise, Subscriptions, One-time payments, Checkout, Shopping carts, Payment statuses, Payment webhooks, Transaction ledgers, Transaction categories, Transaction types, Statements, PDF statements, Recalculations, PostgreSQL, Transactions, Constraints, Triggers, Financial invariants, Financial movements, Document-driven accounting

### Zipurch


Торговельна активність на карті

Інтеграція замовлень і геопросторові сценарії

Я працював над поєднанням активності замовлень, інформації про товари та географічного контексту на карті.

[Zipurch](https://bartenev.site/uk/work/zipurch/)

**Задача**
Потоку замовлень потрібен був візуальний контекст, який поєднує місце події з придбаними товарами.

**Як я це реалізував**
Я працював з агрегацією замовлень, геоданими, tracking і картками товарів, пов’язаними з commerce-каталогом. У проєктуванні також розглядалися маршрути та оцінки доставки; публічний Product Map показує продукт.

**Результат**
Робота додала географічний вимір торговельним подіям, пов’язавши активність на карті з товарним каталогом.

**Інструменти й технології**
Order aggregation, Geodata, Product maps, Tracking, Route modelling, Route calculation, Delivery estimates, Estimated delivery time, Catalog integration

- [Zipurch · пошук товарів](https://zipurch.com/) — Сторінка продукту на базі Onlihub: тенденції покупок, географічні дані та аналіз ринку.

Продукт · Ранній доступ · Посилання перевірено: 2026-09-27

Сторінка запрошує до раннього доступу; частина функцій позначена «Coming Soon».

### Meeting-to-Actions


Від усних рішень до структурованої роботи

Інтеграція мовлення та агентних процесів

Я працював над процесом перетворення аудіо зустрічі на рішення, подальші дії та завдання в Teamwork через MCP.

[Meeting-to-Actions](https://bartenev.site/uk/work/meeting-automation/)

**Задача**
Рішення з розмови потрібно було перетворити на структуровану роботу з відповідальними, а не залишати в аудіозаписі.

**Як я це реалізував**
Розпізнавання мовлення формувало транскрипт для AI-аналізу рішень, завдань і відповідальних. MCP пов’язував структурований результат із Teamwork, поєднуючи обробку аудіо з наявною робочою системою.

**Результат**
Процес пов’язав зміст зустрічей із робочими записами в системі завдань команди.

**Інструменти й технології**
Speech recognition, Transcription, AI analysis, Action extraction, MCP, Teamwork, Workflow integration

### Local AI / Lightweight ML


Вибір моделі під конкретне завдання

Прикладні дослідження та прототипи процесів

Я досліджую локальні моделі та легковагове виконання для мовлення, документів, пошуку й прикладної автоматизації.

[Local AI / Lightweight ML](https://bartenev.site/uk/work/local-ai/)

**Задача**
Вибір моделі вимагав балансу точності, затримки, обмежень обладнання та вартості роботи.

**Як я це реалізував**
Я працюю з локальними LLM, виконанням насамперед на CPU, ONNX і GGUF, а також інструментами мовлення Whisper, Sherpa-ONNX та Silero. Експерименти охоплюють OCR, embeddings, векторний пошук, багатомовну обробку й TTS.

**Результат**
Прикладні експерименти формують мій підхід до вибору моделей і їх поєднання з корисними процесами.

**Інструменти й технології**
Local LLMs, Lightweight models, CPU-first inference, Whisper, Sherpa-ONNX, Silero, ONNX, GGUF, OCR, Document recognition, Embeddings, Vector search, Semantic retrieval, Speech pipelines, Multilingual processing, TTS

### TON Tanks


Telegram-гра: серверні бої та ігрові системи

Керівництво продуктом, backend та ігрові системи

Я брав участь у створенні концепції, розробці та запуску Telegram-гри. Backend обробляє покрокові PvP/PvE-бої, здібності танків, оренду, крафт і збереження результатів; ігрові активи пов’язані з гаманцями та станом NFT.

[TON Tanks](https://bartenev.site/uk/work/ton-tanks/)

**Задача**
Ігровий прогрес, цифрове володіння, торгівля та backend мали скластися в цілісний продукт.

**Як я це реалізував**
Моя робота охоплювала ігрову логіку, backend, продуктові рішення та координацію завдань розробки. Сервер керує ходами, очками дій, ефектами й шкодою, надсилає оновлення бою через WebSocket і записує результати. Також я займався запуском, просуванням і TON/NFT-частиною продукту.

**Результат**
Моя історична оцінка — 130 тис. користувачів; її період і спосіб підрахунку не зіставлено з числом на сайті продукту. Самостійний проєкт поєднав ігрові системи, backend-розробку та запуск.

**Бойовий цикл**
Серверний бій координує ходи PvP та PvE. Стан танка містить здоров’я, броню, швидкість, здібності, ефекти, відновлення та очки дій. Цикл визначає наступний хід, застосовує дії й шкоду, а потім надсилає клієнтам доступні дії та зміни стану через WebSocket.

**Володіння, оренда й крафт**
Доступ до танка розрізняє власника й орендаря та враховує час відновлення й ліміти оренди. Крафт перевіряє вихідні танки та їхнє володіння, після чого записує документ крафту й отриманий ігровий танк. Зв’язки з гаманцями та стан NFT належать до моделі активів.

**Поточний стан і збережені результати**
Сервер зберігає поточний стан бою, а клієнти отримують оновлення. Записи в базі пов’язують бій із його танками та зберігають підсумкові дані, зокрема шкоду й очки. Автентифікація Telegram WebApp пов’язує сесію гравця з ігровим API.

**Моя відповідальність**
Я працював над напрямом продукту, backend та ігровою логікою, координував завдання розробки й брав участь у запуску.

- Серверні PvP/PvE-бої керують ходами, ефектами й шкодою, надсилають поточні оновлення та зберігають результати.

- Сесії Telegram, володіння через гаманці, оренда й крафт поєднують доступ гравця з моделлю ігрових активів.

**Публічні дані про продукт**

Це кількість користувачів застосунку з публічного сайту. Окремий історичний показник 130 тис. походить із мого опису проєкту й не є тією самою перевіреною метрикою.

- 80,000: користувачів застосунку за даними публічного сайту

[TON Tanks · публічна сторінка проєкту](https://tontanks.io/)

Джерела перевірено: 2026-09-27

**Інструменти й технології**
Product concepts, Product launch, Product promotion, Task allocation, Game backends, Game logic, Game balance, Progression, Rewards, Telegram integration, TON, Blockchain transactions, NFTs, NFT economy, Minting, Ownership, Trading, Marketplace mechanics, WebSocket, PvP/PvE, Turn-based battles, Rentals, Crafting

- [TON Tanks · сайт гри](https://tontanks.io/) — Офіційний огляд гри, її механік і посилання на Telegram-гру та NFT-колекцію.

Продукт · Публічна сторінка · Посилання перевірено: 2026-09-27

- [TON Tanks · колекція на GetGems](https://getgems.io/tontanks) — NFT-колекція, на яку безпосередньо посилаються сайт гри та її офіційний Telegram-канал.

NFT-колекція · Перегляд із JavaScript · Посилання перевірено: 2026-09-27

GetGems потребує JavaScript і може обмежувати автоматичні запити. Посилання на колекцію підтверджено джерелами проєкту; кількість NFT і торговельні дані не перевірялися.

- [TON Tanks · Telegram-канал](https://t.me/ton_tanks_nft) — Офіційний канал із сайту tontanks.io: оновлення гри та посилання на колекцію.

Офіційний канал · Публічна сторінка · Посилання перевірено: 2026-09-27

### Modular Vehicles / Unity


Фізика, модульна техніка та процедурні світи

Самостійна розробка ігрових систем

Я розробляю й досліджую модульну техніку, пошкодження, фізику гусениць та процедурні середовища в Unity.

[Modular Vehicles / Unity](https://bartenev.site/uk/work/unity-games/)

**Задача**
Збірна техніка потребує незалежних модулів, які разом працюють як цілісна фізична та ігрова система.

**Як я це реалізував**
Я створюю модульну архітектуру техніки з окремими частинами, логікою пошкоджень, рухом на гусеницях і стрільбою. Експерименти охоплюють multiplayer, режими PvP/PvE, захоплення зон, процедурні міста, рослинність та оптимізацію.

**Результат**
Самостійна розробка, що триває, для перевірки взаємодії фізичної симуляції, модульного дизайну та ігрових механік.

**Інструменти й технології**
Unity, C#, Modular vehicle architecture, Vehicle assembly, Independent modules, Damage systems, Physics, Tracked vehicle mechanics, Shooting, Multiplayer experiments, PvP, PvE, Capture zones, Football mode, Procedural environments, Procedural city generation, Vegetation, Game optimization

### Blender / 3D


Від hard-surface моделей до ігрових ресурсів

Самостійне моделювання та підготовка ресурсів

Я використовую Blender для створення й підготовки hard-surface моделей, матеріалів і текстур для ігрових середовищ.

[Blender / 3D](https://bartenev.site/uk/work/blender/)

**Задача**
3D-ресурс має працювати і візуально, і в межах обмежень застосунку реального часу.

**Як я це реалізував**
Я працюю з моделюванням, hard-surface геометрією, матеріалами й текстурами. Підготовка включає оптимізацію для ігрових проєктів, поєднуючи візуальну роботу з технічними вимогами середовища виконання.

**Результат**
Колекція самостійних 3D-робіт, що доповнює мій досвід ігрових систем і фізичної інженерії.

**Інструменти й технології**
Blender, 3D modelling, Hard-surface modelling, Materials, Textures, Game-ready assets, Asset optimization

### Engine Sim Unity Audio


Фізична симуляція як джерело ігрового звуку

Самостійна розробка аудіоінструментів

Я працював над автоматизованим створенням банків звуків двигуна для Unity з фізичного симулятора двигуна.

[Engine Sim Unity Audio](https://bartenev.site/uk/work/engine-audio/)

**Задача**
Результат симуляції потрібно було перетворити на придатний для гри набір звуків двигуна.

**Як я це реалізував**
Я пов’язав фізичну симуляцію двигуна з автоматизованим створенням аудіобанків. Робота зосереджена на інструментах між генерацією звуку й підготовкою ресурсів для Unity.

**Результат**
Інструментальний проєкт на перетині симуляції, автоматизації та виробництва ігрових ресурсів.

**Інструменти й технології**
Unity, Engine audio banks, Physical engine simulation, Audio generation, Asset automation

- [Engine Sim Unity Audio · GitHub](https://github.com/Vangardo/engine-sim-unity-audio) — Код і документація мого офлайн-генератора аудіобанків на основі Engine Simulator від AngeTheGreat.

Вихідний код · Публічна сторінка · Посилання перевірено: 2026-09-27

### Crypto Trading Terminal


Ринкові дані, стратегії та виконання в одному інструменті

Самостійна розробка застосунку

Я створив торговий термінал із ринковими даними, графіками, власними стратегіями, backtesting і виконанням операцій на біржі.

[Crypto Trading Terminal](https://bartenev.site/uk/work/trading-terminal/)

**Задача**
Дослідження стратегій потребувало зв’язного шляху від історичних даних та індикаторів до виконання й збереження результатів.

**Як я це реалізував**
Я поєднав графіки та індикатори SMA, EMA, MACD, TMA і RSI з користувацькими стратегіями й backtesting. Виконання операцій на біржі, комісії, P&L і збереження результатів сформували операційну частину термінала.

**Результат**
Застосунок поєднав аналіз стратегій і виконання на біржі в одному процесі з урахуванням комісій, P&L і збереженням результатів.

**Інструменти й технології**
Market data, Charting, SMA, EMA, MACD, TMA, RSI, Backtesting, User-defined trading strategies, Live exchange execution, Commissions, P&L, Results persistence

## Контакт


[Telegram](https://t.me/vangardo)

[LinkedIn](https://www.linkedin.com/in/igor-bartenev-452a92290/)

[Facebook](https://www.facebook.com/igor.bartenev)

[Reddit](https://www.reddit.com/user/Complex-Chance-7258/)

[GitHub](https://github.com/Vangardo)

[Завантажити CV](https://bartenev.site/cv/igor-bartenev-uk.pdf)

[Продукти та джерела](https://bartenev.site/uk/resources/)