# Igor Bartenev


Software Architect / Technical Lead · Poland

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

Python · FastAPI · PostgreSQL · Elasticsearch · Redis

Hands-on software architect and technical lead for commerce, business automation and AI agent infrastructure. I turn operational requirements into data models, modular backend services and integrations, and carry decisions through implementation and delivery. My manufacturing and ERP background helps me connect software design to the work people actually do.

## Relevant experience


### Onlihub · Joined February 2022


Lead Developer · architecture & technical ownership

Joined an existing platform as its second developer; took technical ownership after the lead left. Redesigned application and database architecture, coordinated a small cross-functional team and worked directly with the CEO on feasibility and delivery.

Implemented backend services linking supplier catalogs, marketplace listings, stock, orders and fulfillment. Modelled external identifiers and synchronization rules so operations could span systems with different data and update cycles.

### Artekom · January 2020 - February 2022


1C developer → Python products & automation

Connected accounting, websites and APIs in 1C; moved into Python product development in 2021. Built Telegram-to-ERP workflows and a desktop trading terminal with strategy backtesting and exchange execution.

### Technopark Pozh Tekhnika · 2013 - January 2020


Manufacturing engineering → ERP automation

Designed parts, tooling and CNC processes for serial production. From February 2019, implemented and extended 1C for materials, production planning, reports and payroll.

## Selected engineering work


### Configurable business processes


Designed and built a platform used by a mortgage company alongside Encompass. Configurable intake forms, document OCR, staff tasks and compensation rules connected client applications to internal operations. Clients answered once and saw the required documents; staff gained assigned work with less manual coordination.

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

### Large-scale data collection


Designed parallel scanning, proxy/account coordination, normalization and Elasticsearch bulk processing. The archived marketplace-data project handled millions of listings over approximately five months (historical scale reported from my work).

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

### Controlled access to tools for AI agents


Built MCP Hub for tool discovery, schemas on demand, retained results and permission-aware execution; I use it daily. Separately, my open-source Unity integration reduced 48 model-visible tools to 6 while retaining access to 377 operations. Its schema benchmark is public.

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

## Technical toolkit


- Backend & data: Python, FastAPI, SQL, PostgreSQL, Elasticsearch, Redis; Rust catalog service; complex queries, constraints, triggers and TTL caches.

- Architecture: Domain modelling; modular services; ports & adapters; document workflows, formulas, permissions; idempotency and recovery.

- Integration & operations: REST, webhooks, OAuth, WebSocket; workers, task queues, batch pipelines; Docker, Linux and production debugging.

- AI infrastructure: MCP, tool discovery and orchestration; local embeddings and hybrid retrieval; context budgets, approvals and execution history.

## Education


National Technical University “Kharkiv Polytechnic Institute”
Specialist degree · September 2008 — February 2014
Automation and Computer-Integrated Technologies

## Cross-domain experience


TON Tanks: product, backend and launch work on a Telegram / TON game. Further work includes Unity vehicle systems, 3D assets and local speech / document AI experiments.

## Expertise


### Commerce & integrations


Catalogs, marketplaces, warehouses, orders and fulfilment: the shared model and the boundaries between them.

Architecture and implementation of multichannel platforms

Designed shared product, inventory and order models for Onlihub and MySellerHub, connecting channels with different warehouse models and external identifiers.

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

[Commerce & integrations](https://bartenev.site/en/expertise/#domain-commerce-integrations)

### Business systems


For a mortgage company, I connected client intake to documents, OCR, staff tasks, compensation and Encompass. Configurable forms and business rules let the same core support different operating scenarios.

Business modelling, architecture and hands-on implementation

A client’s answers select the next questions and document requirements. Uploaded files supply field values through OCR; document events assign participants and tasks. Staff work from personal Kanban boards, while records and selected statuses flow to Encompass. Calculations and compensation retain their source relationships.

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

[Business systems](https://bartenev.site/en/expertise/#domain-business-systems)

### Backend, data & scraping


Large-scale parsing with concurrency and proxy pools; Elasticsearch bulk reads and writes; separate database, cache, read and worker paths.

Architecture, implementation and performance optimization

Amazon data: parallel collection and Elasticsearch batch operations. Catalog: Rust reads, Python fallback and Redis caching. Onlihub: business modules with explicit application contracts, repository ports and infrastructure adapters.

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

[Backend, data & scraping](https://bartenev.site/en/expertise/#domain-backend-data)

### AI infrastructure


MCP Hub combines tool discovery, local embeddings and reusable methods with controlled execution across databases, logs, tasks and communication.

Architecture and hands-on development of agent infrastructure

Implemented hybrid knowledge retrieval, optional local reranking of methods and experience feedback. On-demand schemas, retained results, shared runner budgets and persistent automations keep execution and context manageable.

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

[AI infrastructure](https://bartenev.site/en/expertise/#domain-ai-infrastructure)

### Technical leadership


Start with a business goal, work out a solution and carry it into code. My work combines architecture, explaining alternatives to stakeholders, hands-on development and coordination where the project needs it.

Solution ownership, architectural decisions and implementation

For BOS, I proposed and developed the solution, explained its architecture to the business and refined it around real workflows. At Onlihub, I took over architecture, database, backend and integrations after the lead developer left, coordinated development and advised the CEO on feasibility.

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

[Technical leadership](https://bartenev.site/en/expertise/#domain-technical-leadership)

### Industrial engineering


Manufacturing, CAD/CAM and CNC built the foundation: understand materials, operations and constraints before automating them.

Industrial engineering and production automation

Prepared parts, machine programs and technical documentation for serial production; refined operation sequences and material use, then automated production planning and accounting in 1C.

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

[Industrial engineering](https://bartenev.site/en/expertise/#domain-engineering-foundations)

### Games & 3D


Independent product work across game backends, TON, Unity physics, modular vehicles, procedural worlds and 3D assets.

Independent product development and game systems

Led TON Tanks product development and built its backend and game logic. Independent Unity work explores modular tanks, tracked physics, damage and procedural city generation.

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

[Games & 3D](https://bartenev.site/en/expertise/#domain-games-3d)

## Work


### Onlihub


Technical ownership of a commerce platform

Lead Developer · architecture, implementation and delivery

I took technical ownership of a growing platform connecting suppliers, products, marketplaces and fulfillment.

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

**Connecting a store is more than an API call**

Illustrative walkthrough of the implementation

A merchant connects a sales channel. The provider may be slow, and the same request may arrive again. The application needs to know what was requested, who is processing it and whether it finished.

1. Validate store ownership and the integration’s supported capabilities.

2. Record the connection request with an idempotency key and an outbox entry.

3. Let a worker claim the job, renew its lease and record completion or failure.

**What this enables**
A connection request has a recorded lifecycle instead of depending on one long HTTP request. Retries and exhausted attempts have explicit handling.

**Design choice & trade-off**
The current implementation keeps intent and worker ownership in PostgreSQL, with bounded concurrency and lease checks. This makes work recoverable, but adds state management and background processing. Delivery is at least once: a provider-side effect still needs idempotency or reconciliation; a local claim token cannot guarantee exactly-once execution in an external service.

**The challenge**
Commerce operations had to stay consistent across different product models, warehouses and external systems.

**How I approached it**
After the lead developer left, I took over development and redesigned the application and database architecture. I implemented an asynchronous FastAPI backend, complex PostgreSQL queries and integrations across commerce and warehouse systems, while coordinating the team and advising the CEO on feasibility.

**The outcome**
The work connected the product lifecycle from catalog and inventory to orders, fulfillment and tracking, with ownership extending beyond individual services.

**From developer to technical owner**
I joined the startup working alongside an experienced lead. When they left, I took responsibility for the architecture, database and backend, coordinated a small cross-functional team and guided the product through implementation, support and further development. Discussions with the CEO connected business ideas to technical feasibility and delivery decisions.

**One model across different channels**
The original platform was designed for a broader multichannel scenario: a product from one source could be published into another channel. I worked with Amazon, Walmart, eBay, TikTok Shop, Shopify and warehouse integrations, reconciling products, external identifiers, real and virtual warehouses, stock, orders and tracking. That original scope helped give rise to MySellerHub as the products evolved.

**Asynchronous services and complex SQL**
I built and documented API methods with FastAPI, asynchronous processing, threads and queue management. PostgreSQL work included dynamic queries and optimization over large datasets. Recurring-task tooling, parsers and PowerBI analysis complemented the core backend, so integration work and operational processing had their own supporting tools.

**Architecture that evolved with the product**
The platform grew into related products with different responsibilities: supplier operations, retailer workflows and the dedicated high-load catalog. I worked on both architecture and implementation, including subscriptions and one-time payments. Onlihub later appeared as an Amazon MCF integration; that product milestone is separate from my own engineering responsibilities.

**My responsibility**
I joined the existing platform in February 2022 as its second developer. After the lead left, I took responsibility for application architecture, the database and backend, coordinated a small cross-functional team and worked directly with the CEO on feasibility and delivery.

- A shared commerce model connects catalog, inventory, orders, fulfillment and tracking across channel-specific systems.

- APIs and background processing support marketplace and warehouse integrations, with reconciliation of external identifiers and states.

**Public product context**

Figures published by Onlihub describe the platform’s reported scale, separately from my contribution and period of work. Amazon lists Onlihub as an MCF integration.

- 10,000+: stores in the platform’s network

- 40,000+: MCF orders fulfilled

[Onlihub · product figures](https://onlihub.com/)

[Amazon · integration listing](https://supplychain.amazon.com/integrations/onlihub)

Sources checked: 2026-09-27

**Tools & technologies**
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 · commerce platform](https://onlihub.com/) — The public product website: FBA inventory, retailer distribution and Amazon MCF fulfillment.

Product · Public page · Links checked: 2026-09-27

- [Onlihub on Amazon MCF](https://supplychain.amazon.com/integrations/onlihub) — Amazon’s own integration listing describes how Onlihub routes orders to Multi-Channel Fulfillment.

External reference · Public page · Links checked: 2026-09-27

This confirms the listed integration; it is not a certification of the product or its developer.

- [Onlihub Help Center](https://support.onlihub.com/) — Public product guides, linked from Onlihub’s website.

Documentation · Public page · Links checked: 2026-09-27

### BOS / Business Operations System


From client intake to mortgage operations

Solution design, architecture and hands-on development

I designed and built a business operations platform used by an existing mortgage company. Conditional client forms, document OCR, staff tasks and compensation rules connected to its Encompass workflow.

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

**One client form starts the operational process**

In use at a mortgage company · author’s account

An existing mortgage company handled applications in Encompass, with much of the intake and coordination done manually. I built BOS to connect a new client-facing website to the people, documents and actions behind each application.

1. Answer once. Employment, income and earlier answers determine the next questions and required documents. Staff and realtors can configure these forms themselves.

2. Upload the requested files. Automation creates linked document records and tasks; OCR extracts values into fields so staff can work with structured information.

3. Move the application forward. Participants work from their task lists and Kanban boards; documents, external IDs and selected statuses are exchanged with Encompass.

**What this enables**
Clients gained a clear route from answers to required documents. Staff received assigned work instead of manually coordinating every hand-off. The company kept Encompass and gained a connected intake and operations layer around it.

**Design choice & trade-off**
I made forms, document schemas and business rules configurable so process changes did not require a separate hard-coded application flow each time. Mortgage-specific configuration sits on a reusable core. This flexibility requires explicit conditions, access rules and state transitions. Calculations, document-event actions and compensation accounting remain separate modules with defined inputs and results.

**The challenge**
The company worked in Encompass without a client-facing intake website. Staff manually gathered information, worked out which documents each borrower needed and coordinated follow-up. Employment, income and other circumstances changed the requirements, making each new application difficult to organize.

**How I approached it**
I proposed the solution, explained architectural choices to the business and developed it around real operating scenarios. Configurable forms choose fields, steps and required documents from the applicant’s answers. Document events create tasks and assign participants; OCR populates fields from uploaded files. Separate modules handle calculations, access, compensation and exchanges with Encompass. The document-and-rule core was designed to be reusable beyond mortgages.

**The outcome**
The company gained a client-facing intake website connected to its internal operations. Clients could answer once and see which documents to provide; staff received assigned tasks and worked on linked records that flowed into Encompass. This simplified application handling and reduced manual coordination.

**Forms that follow the applicant’s situation**
Staff and realtors can configure forms for their clients. Answers determine which fields are visible or enabled, which step comes next and which documents are required. Employment status and income can lead to different branches, including decisions based on earlier steps. Completed intake starts the configured document and task actions.

**Uploaded documents become working data**
Clients upload files against the required document records. OCR uses a lightweight neural model to extract values into document fields, with document privacy guiding the approach. Configurable columns and fields let staff extend the data model as requirements change. Extracted values then participate in the same document, calculation and task processes.

**A work queue for each participant**
Rules assign document participants and create tasks for their part of the loan process. Each person has a task list or Kanban board; tasks can be reassigned or performed again when work needs revisiting. Task statuses and document statuses express different kinds of progress. Parameterized message templates address users or contacts.

**Connected to the existing Encompass process**
BOS exchanges documents with Encompass and links external document IDs and selected statuses. Import, export and synchronization run through mappings and recorded integration tasks, so client intake connects to the company’s existing system. A planned integration scenario is a signature-dependent step: a provider such as PandaDoc can supply the signing status before work proceeds.

**Organizations and access**
The mortgage process sits within a model of organizations, departments, memberships and roles. Permissions combine an allowed action with a scope and conditions on the data. This lets document access follow a person’s responsibilities in the organization.

**Documents and forms with state**
Document types define typed fields, dictionaries and parent–child relationships. Multi-step forms support nested and repeating inputs, save answers and create or link documents on completion. Submissions can include an expected version so a stale edit returns a conflict instead of silently replacing newer answers.

**Calculation flows**
A calculation combines document attributes, constants and previous formula results. The preview shows values and their sources; running the flow creates a document with the result. Mortgage income calculations are one concrete use case. Print templates turn a document’s data into a PDF.

**Compensation tied to the work**
Compensation covers fixed monthly amounts, bonuses tied to closed loans and accruals when a participant’s document reaches a configured status. Rules select the recipient and calculation base, supporting fixed amounts, percentages, basis points and caps. Internal records retain their source document and rule, including deductions and referrals; they represent compensation accounting, not a bank transfer.

**My responsibility**
I designed and developed BOS for an existing mortgage company: clarified its needs, proposed alternatives, explained my architectural choices and refined the implementation with the business. My responsibility covered the solution and its code.

- Configurable document types and multi-step forms collect linked data. Separate calculation flows preview formula results or produce new documents.

- Scoped access and event rules govern document actions. Status-based compensation retains its source document and rule, with database checks around transaction records.

**Tools & technologies**
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


Agent orchestration, project knowledge and reusable experience

Agent infrastructure and integration architecture

I built a service where agents find tools and project knowledge, work across connected systems and retain useful methods for later tasks.

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

**Investigating a discrepancy across connected services**

Illustrative walkthrough of the implementation

Consider an agent investigating a stock discrepancy and preparing a follow-up task. It needs relevant data from connected services, enough context to reason, and a clear boundary before changing anything.

1. Find relevant tools in the permitted catalog and load only their exact schemas.

2. Read within a shared budget; keep large responses as stored artifacts with previews.

3. Check action permissions, obtain approval when required, then retain the execution result.

**What this enables**
The agent gets a focused working context, while the operator can inspect the action, access decision and recorded result. Approval remains tied to the agreed action and arguments.

**Design choice & trade-off**
Selective discovery adds a lookup step but avoids loading every integration schema into every request. Previews reduce immediate context size, while full artifacts require explicit retrieval and have retention limits. An uncertain external write stays uncertain; it is not silently reported as success or blindly repeated.

**The challenge**
Operational questions span several systems, while broad database access and an ever-growing tool catalog create permission and context problems for agents.

**How I approached it**
I combined on-demand tool schemas, scoped execution and retained results with local embeddings, full-text retrieval and reusable methods. The native agent runner shares budgets across delegated work, while scheduled workflows use persistent runs and approval states. Knowledge, observed calls and feedback remain separate so later tasks can reuse experience in its original context.

**The outcome**
I use MCP Hub to investigate errors, review communication and trace project activity across databases, logs and work tools. Relevant schemas, stored results and prior methods can be opened as needed, keeping repeated investigations focused.

**Find an operation, then load its schema**
Tool discovery returns compact matches with argument hints, risk information and a schema reference checked at invocation. The agent requests the exact schema for a selected operation, then invokes it by name. This keeps the full integration catalog outside the prompt while preserving a direct path from intent to the current tool contract.

**Local embeddings and hybrid retrieval**
Project knowledge combines FTS5 with local SentenceTransformer embeddings. A streamed vector scan retains the best fragment IDs before loading their content, and content hashes avoid embedding unchanged text. Reusable methods have a separate retrieval path: semantic and lexical selection followed by an optional local CrossEncoder that assesses relevance to the task.

**Project scope and evidence of execution**
A cross-system investigation starts with the permitted projects, resources and operations. Database records, logs and communication can then be examined within that scope. Calls requiring approval wait for a human decision. Execution receipts tie observed results to the current run, while the audit trail records actions and supports checking the final conclusion.

**Methods that retain context and feedback**
An agent can save the goal, applicability, conditional call plan and lessons from unsuccessful attempts. Later tasks retrieve a small set of methods to use, adapt or ignore. Reported usefulness and evidenced success remain separate signals. Learning accumulates and refines reusable experience; unchanged reuse keeps the existing method and its embedding.

**Shared control for delegated work**
The built-in agent runner uses a shared controller for token usage, model calls, tool attempts, workers and concurrency across delegated work. Deadlines and cancellation apply to the run tree, while operation claims track overlapping requests. This gives orchestration a common execution budget and explicit ownership as agents divide a task.

**Automations with persistent runs**
Cron, interval and event triggers start a tool operation or a multi-step agent workflow. Run state is stored in SQLite; workers claim work with an owner and lease, and expired leases can be recovered. Approval waits are explicit states. Recurring checks of project activity and communication use the same governed integration layer.

**Keep results available and context compact**
Results are retained encrypted and reopened through handles within their owner, expiry and policy boundaries. Knowledge fragments can be read selectively; memory packs cap items and characters. Method previews link to larger plans, while small plans keep their conditions inline. The agent can revisit details without copying every raw response into the conversation.

**My responsibility**
I designed and built the integration layer and native agent runtime, including tool discovery, project knowledge, execution controls and reusable experience.

- Local embeddings and hybrid search retrieve relevant knowledge. Tool schemas and stored results open on demand, keeping the working context focused.

- Agents and persistent automations share scoped execution, approvals, receipts and budgets. Completed work can explicitly contribute reusable methods; this does not train model weights.

**Tools & technologies**
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


Large-scale Amazon scraping and trend analysis

Data acquisition and processing architecture

I designed and built an Amazon data service that scanned categories across the marketplace, excluding books, and used Elasticsearch bulk processing to identify trends.

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

**From scattered listings to a usable dataset**

Historical workflow · author-reported

To study product trends across categories, collection and storage had to work together. Fetching pages was only the first step: inconsistent records needed a common representation and an efficient path into analysis.

1. Collect category data in parallel, coordinating accounts, proxies, throttling and retries.

2. Normalize collected records before indexing them in Elasticsearch batches.

3. Read groups of records for analysis instead of making one storage request per listing.

**What this enables**
A category-wide dataset supported trend analysis. The archived service handled millions of listings over roughly five months; this is historical scale reported by me, not a current throughput benchmark.

**Design choice & trade-off**
Batching shaped both writes and reads, reducing the number of individual storage round trips. The trade-off is that data becomes available in groups rather than immediately per item. Collection coverage and freshness still depend on the external source; dataset size does not establish the accuracy of a trend or forecast.

**The challenge**
The breadth of the catalog required parallel acquisition and a storage strategy that could work with millions of listings without turning every item into a separate read or write.

**How I approached it**
Parallel parsers combined account and proxy management, throttling and retry strategies across the category scan. I organized normalization and Elasticsearch processing around bulk writes and bulk reads, keeping storage work batched as the collected dataset grew. The resulting data supported analysis of changes and trends.

**The outcome**
The service ran for about five months at a historical scale on the order of millions of listings. It supported category-wide trend analysis before the team changed focus and the project was archived.

**Historical category-wide scope**
The project scanned Amazon categories across the catalog, with books deliberately excluded. Its historical workload was on the order of millions of listings. That breadth made acquisition, normalization and storage design one connected problem: category data had to become a consistent dataset that could be analysed in batches.

**Acquisition under external constraints**
The parsers had to account for blocking, multiple accounts, proxies and failed requests. Parallel processing, throttling and retries made these conditions part of the acquisition design. Normalization gave downstream indexing and analysis a consistent representation despite differences in the collected source data.

**Bulk on both sides of storage**
Elasticsearch was used for both bulk writes and bulk reads. Batching mattered on both sides: collected records were indexed together and analysis consumed groups of records, avoiding a storage workload dominated by individual requests. This decision shaped the data path as much as the choice of search engine itself.

**Trend analysis and a bounded product lifetime**
The goal of collection was to identify changes and trends in product data. The service operated for roughly five months before priorities moved to other work. The archived project brings together the full engineering chain: parallel acquisition, normalization, bulk storage access and analysis of a large historical dataset.

**My responsibility**
I designed and implemented the acquisition-to-analysis path: parallel collection, normalization and bulk access to Elasticsearch.

- Parallel parsers account for failed requests and external limits through throttling and retries; normalization prepares a consistent dataset.

- Both indexing and analysis use batches, so the data path does not depend on a separate storage request for every listing.

**Historical scale · author-reported**

The service operated for roughly five months with a historical workload on the order of millions of listings. It supported category trend analysis before the project was archived.

**Tools & technologies**
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


From supplier spreadsheets to a marketplace

Product architecture and data processing

I built a pipeline that turns fragmented liquidation offers into structured, searchable product listings.

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

**The challenge**
Buyers had to search inconsistent spreadsheets and email offers with incomplete product data.

**How I approached it**
I connected email and spreadsheet ingestion with normalization, barcode or ASIN identification and external enrichment. AI helped structure incomplete data and classify products, while processing states and errors remained visible to operators.

**The outcome**
Supplier files became listings connected to prices, stock and warehouses, within a product supporting buyers, sellers, chats and orders.

**Tools & technologies**
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 · wholesale catalog](https://liqsale.com/) — Browse the public wholesale and liquidation catalog, with product and warehouse information.

Product · Public page · Links checked: 2026-09-27

- [Daily Snipes · catalog](https://dailysnipes.com/) — The same wholesale product family under the Daily Snipes name, also identified on Liqsale’s website.

Product · Public page · Links checked: 2026-09-27

### Unity MCP Efficient


A smaller tool interface with access to the full operation catalog

Facade design and implementation

I built a compatibility layer that lets agents discover Unity operations without loading every tool schema into context.

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

**The challenge**
A large model-visible tool surface consumed context before an agent could choose the operation it needed.

**How I approached it**
I separated discovery from execution, loading operation schemas on demand and bounding returned results. Batches, stored results, receipts and idempotent retries address repeated mutations, asynchronous work and Unity domain reloads.

**The outcome**
The published author benchmark of 24 August 2026, against upstream v10.1.0, records 48 → 6 model-visible tools and access to 377 operations. Schema context falls from 23,280 to 915 estimated tokens (characters ÷ 4); this is a documented estimate, not an independently reproduced runtime or cost benchmark.

**My responsibility**
I designed and implemented the compatibility facade, separating operation discovery from execution and keeping schemas available on demand.

- A compact model-visible interface preserves discovery and access to the full operation catalog.

- Batches, bounded results, receipts and retry handling support asynchronous Unity work and domain reloads.

**Published author benchmark**

README comparison dated 24 August 2026 against upstream v10.1.0. Schema tokens are estimated as characters ÷ 4; this measures tool declarations, not total task context, runtime speed or billing.

- 23,280 → 915: estimated schema tokens

- 48 → 6: model-visible tools

- 377: operations remain accessible

[GitHub · benchmark and method](https://github.com/Vangardo/unity-mcp-efficient#readme)

Sources checked: 2026-09-27

**Tools & technologies**
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) — Public source, setup instructions and tests for the compact MCP facade for Unity.

Source code · Public page · Links checked: 2026-09-27

- [Unity MCP Efficient · benchmark method](https://github.com/Vangardo/unity-mcp-efficient/blob/main/BENCHMARKS.md) — Reproducible measurements of tool-schema size and compact output, with the baseline and limitations.

Documentation · Public page · Links checked: 2026-09-27

The reported reduction concerns context footprint, not API cost or overall task performance.

### MySellerHub


A shared model across independent commerce channels

Multichannel architecture and integrations

I designed a backend model for products, channel listings, orders and warehouses, with inventory updates and fulfillment connected across external platforms.

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

**The challenge**
Each sales channel described the same product and order differently, making synchronization a domain problem rather than a simple API call.

**How I approached it**
I separated products from channel listings and mapped external identifiers into a shared model. Shopify sales-channel and supplier operations follow separate paths. Order import connects to warehouse assignment, while stock synchronization tracks the desired quantity, its version and what was last sent.

**The outcome**
The architecture supported a connected path from publishing a product in another channel to returning its fulfillment status; the current public product emphasizes Shopify and Amazon inventory.

**Sales channel and supplier**
Shopify can be a sales channel receiving products and sending customer orders, or a supplier providing a catalog and fulfilling purchase orders. These roles use separate workflows around a shared product and listing model. Supplier orders carry a local reference used to look for an existing external order before creating another.

**Stock can change during an update**
Each stock target has a desired quantity and version. After sending an update, the worker checks whether that version is still current. If stock changed in the meantime, the item stays pending for another attempt. Buffer and stock-cap rules adjust the target before it is sent to the channel.

**Continuing an order import**
Imported orders are matched by store, integration and external ID, then their lines are matched to listings. A later sync can revisit warehouse assignment for existing lines and update fulfillment and tracking. This keeps a partially processed order within the same model instead of creating an unrelated copy.

**My responsibility**
I designed a multichannel commerce model and the synchronization paths connecting listings, inventory, orders and fulfillment.

- Channel-specific products and identifiers map into a common model for publishing and stock synchronization.

- Orders connect to the relevant fulfillment source, with shipment tracking returned to the originating channel.

**Public product context**

The current product website reports this catalog figure. Its present offering is separate from the broader multichannel model I worked on.

- 10,000+: products ready to list

[MySellerHub · product website](https://mysellerhub.com/)

Sources checked: 2026-09-27

**Tools & technologies**
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 · seller platform](https://mysellerhub.com/) — Product overview for catalog sourcing, stock synchronization and order fulfillment.

Product · Public page · Links checked: 2026-09-27

- [MySellerHub · Shopify App Store](https://apps.shopify.com/mysellerhub) — The published app listing names Onlihub Inc. as developer and describes its sales-channel integrations.

External reference · Public page · Links checked: 2026-09-27

- [MySellerHub Help Center](https://help.mysellerhub.com/) — Guides for onboarding, product catalogs, listings, orders and fulfillment.

Documentation · Public page · Links checked: 2026-09-27

### Onlihub Catalog


Different data paths for different workloads

Architecture and implementation of the catalog service

I designed and implemented a dedicated Onlihub catalog service with a Rust primary path, Python fallback, Redis caching and Elasticsearch.

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

**The challenge**
Large listing datasets and expensive queries needed a read model suited to their access patterns.

**How I approached it**
I separated the fast Rust serving layer, a Python fallback, cache and search/read responsibilities from transactional storage. Load balancing and request throttling controlled repeated traffic, while bulk processing and query optimization addressed expensive data operations.

**The outcome**
Search and high-frequency reads gained their own path while transactional storage and business logic retained separate responsibilities.

**Dedicated service, explicit data paths**
The marketplace catalog became a dedicated service with its own serving architecture. Rust handled the primary fast path, with a Python fallback alongside it. I was responsible for both the architecture and its implementation, separating the catalog workload from the broader commerce application.

**Cache, search and transactions have different jobs**
Redis cached data for repeated reads, while Elasticsearch provided the search/read model and PostgreSQL retained transactional responsibilities. This separated how catalog data was retrieved from how business state was stored. Bulk operations and heavy-query optimization complemented that division of responsibilities.

**Control repeated traffic at the boundary**
Load balancing and throttling were part of the service design. Clients making excessive repeated requests could be slowed before their traffic dominated the catalog workload. Traffic controls, caching and the fast serving layer were designed together, addressing both how requests arrived and how the underlying data was read.

**Tools & technologies**
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


The physical process behind the software

Manufacturing engineering and CAD/CAM

My engineering foundation comes from designing parts, machining operations and the processes that bring products into production.

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

**The challenge**
A part had to work as a repeatable production process, with real constraints on machines, materials and operation sequences.

**How I approached it**
I worked with CAD/CAM models, CNC programs, postprocessors and technical documentation. The work included sheet-metal cutting, turning and milling operations, material consumption and preparation for serial production.

**The outcome**
This work established the method I still use: understand the real process, identify constraints and only then design its automation.

**Tools & technologies**
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


Translating company operations into an accounting model

Business analysis and application development

I built and supported 1C solutions for Ukrainian companies, working directly with customers on accounting, production planning, material consumption and logistics.

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

**The challenge**
Business documents had to produce correct stock and financial movements across connected company processes.

**How I approached it**
I examined how companies operated and translated those rules into documents, reports, queries and integrations in 1C УТП/УНФ. Custom modules addressed transport logistics and production operations, alongside material norms, costs and internal data exchanges.

**The outcome**
The experience connected software models to physical stock, money and operational consequences, forming a foundation for later financial and business systems.

**Understand the company before configuring the system**
I worked directly with customers to understand their technological and administrative processes, including projects built from the ground up. That meant discussing how materials, documents, stock and money actually moved before configuring accounting and integrations. The customer’s operational model shaped the software model.

**Production, materials and spending plans**
The work included production planning, material norms and consumption, stock movements, costs, payroll and spending plans. My manufacturing background helped connect the figures in 1C to the operations creating them. Reports and complex queries made that operational information usable for planning and control.

**Custom modules for real operations**
I developed transport-logistics modules and tools for accelerating or improving production operations. Data exchanges and integrations connected these modules with the rest of the company’s accounting. This experience established the document-to-movement model that later reappeared in financial services and the Python business operations platform.

**Tools & technologies**
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


Payments, documents and data integrity

Cross-project financial modelling and integrations

In Onlihub and Liqsale, I built subscriptions, one-time payment flows and transaction models connected to statements, recalculations and business documents.

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

**The challenge**
A successful payment callback was only one part of keeping balances, transaction states and business documents consistent.

**How I approached it**
I worked with Stripe and Wise, subscriptions, checkout, payment webhooks and PDF statements. I also designed ledger-like models and explored enforcing financial invariants through PostgreSQL transactions, constraints and triggers.

**The outcome**
This practice links my ERP background to modern payment systems: financial operations are modelled through explicit states, categories and movements.

**Payments within the commerce workflow**
My work in Onlihub and Liqsale included subscriptions, one-time payments, carts, checkout and status synchronization. Stripe and Wise integrations sat within the application’s financial workflow, connecting payment events to the customer’s order or subscription and the relevant transaction records.

**A transaction model behind the statements**
I worked on transaction types and categories, calculations, recalculations and statements, including PDF output. These records describe how financial operations relate to application state and documents. The model supports tracing the figures displayed to users back to the transactions and movements that produced them.

**Exploring invariants in PostgreSQL**
I explored placing part of the financial rules in PostgreSQL transactions, constraints and triggers, including balance restrictions and movements caused by document status changes. The design goal was to make important invariants explicit at the data layer. Trigger-based balance protection was an area of experimentation within that work.

**Tools & technologies**
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


Making commerce activity visible on a map

Order-data integration and geospatial workflows

I worked on connecting order activity, product information and geographic context in a commerce map.

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

**The challenge**
A stream of orders needed a visual context that linked where activity happened with what was being purchased.

**How I approached it**
I worked with order aggregation, geodata, tracking and product cards linked to the commerce catalog. The design also considered routes and delivery estimates; the public Product Map is the visible product reference.

**The outcome**
The work brought a geographic view to commerce events, connecting map activity with the underlying product catalog.

**Tools & technologies**
Order aggregation, Geodata, Product maps, Tracking, Route modelling, Route calculation, Delivery estimates, Estimated delivery time, Catalog integration

- [Zipurch · product discovery](https://zipurch.com/) — The Onlihub-powered product page for purchase trends, geographic data and market exploration.

Product · Early access · Links checked: 2026-09-27

The public page invites early access; several features are marked “Coming Soon”.

### Meeting-to-Actions


From spoken decisions to structured work

Speech and agent workflow integration

I worked on a workflow that transforms meeting audio into decisions, action items and tasks in Teamwork through MCP.

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

**The challenge**
Decisions in a conversation needed to become structured, attributable work rather than remain buried in a recording.

**How I approached it**
Speech recognition produced a transcript for AI analysis of decisions, tasks and responsible people. MCP connected the structured output to Teamwork, making the workflow an integration between audio processing and an existing work system.

**The outcome**
The workflow connected meeting content to actionable records in the team’s task system.

**Tools & technologies**
Speech recognition, Transcription, AI analysis, Action extraction, MCP, Teamwork, Workflow integration

### Local AI / Lightweight ML


Choosing a model that fits the actual task

Applied research and workflow prototypes

I explore local models and lightweight inference for speech, documents, retrieval and practical automation.

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

**The challenge**
Model selection needed to balance useful accuracy, latency, hardware limits and operating cost.

**How I approached it**
I work with local LLMs, CPU-first inference, ONNX and GGUF alongside speech tools such as Whisper, Sherpa-ONNX and Silero. Experiments also cover OCR, embeddings, vector search, multilingual processing and TTS.

**The outcome**
A collection of applied experiments informs how I choose models and connect them to useful workflows.

**Tools & technologies**
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 game: server-side battles and game systems

Product lead, backend and game systems

I helped shape, build and launch a Telegram game. Its backend handles turn-based PvP/PvE battles, tank abilities, rentals, crafting and recorded results; game assets are linked to wallets and NFT state.

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

**The challenge**
Game progression, digital ownership, trading and the backend had to form one coherent product.

**How I approached it**
My work covered game logic, backend, product decisions and coordination of development tasks. The server manages turns, action points, effects and damage, sends battle updates over WebSocket and records results. I also worked on launch, promotion and the TON/NFT side of the product.

**The outcome**
My historical estimate is 130k users; its period and counting basis have not been reconciled with the product website’s published figure. The independent project brought together game systems, backend development and launch work.

**The battle loop**
A server-side battle coordinates PvP and PvE turns. Tank state includes health, armor, speed, abilities, effects, cooldowns and action points. The loop chooses the next turn, applies actions and damage, then sends available actions and state changes to clients over WebSocket.

**Ownership, rentals and crafting**
Tank access distinguishes an owner from a renter and accounts for cooldowns and rental limits. Crafting checks the input tanks and their ownership, then records a crafting document and the resulting game tank. Wallet links and NFT state are part of the asset model.

**Live state and recorded results**
The server maintains the active battle state while clients receive updates. Database records link a battle to its tanks and store outcome data, including damage and points. Telegram WebApp authentication connects the player session to the game API.

**My responsibility**
I contributed product direction, backend and game logic, coordinated development tasks and worked on the launch.

- Server-side PvP/PvE battles manage turns, effects and damage, send live updates and record results.

- Telegram sessions, wallet ownership, rentals and crafting connect player access with the game’s asset model.

**Public product context**

This is the public site’s app-user figure. The separately reported historical figure of 130k comes from my own account of the project and is not the same verified metric.

- 80,000: app users reported on the public website

[TON Tanks · public project page](https://tontanks.io/)

Sources checked: 2026-09-27

**Tools & technologies**
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 · game website](https://tontanks.io/) — The official game overview, with gameplay information and links to the Telegram game and NFT collection.

Product · Public page · Links checked: 2026-09-27

- [TON Tanks · GetGems collection](https://getgems.io/tontanks) — The NFT collection linked directly by the game website and its official Telegram channel.

NFT collection · JavaScript viewer · Links checked: 2026-09-27

GetGems requires JavaScript and may restrict automated requests. The official collection link was verified through the project; NFT totals and trading data were not verified.

- [TON Tanks · Telegram channel](https://t.me/ton_tanks_nft) — The official project channel linked from tontanks.io, with game updates and the collection link.

Official channel · Public page · Links checked: 2026-09-27

### Modular Vehicles / Unity


Physics, modular machines and procedural worlds

Independent game systems development

I am building and experimenting with modular vehicles, damage, tracked physics and procedural environments in Unity.

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

**The challenge**
Assembled vehicles need independent parts to behave as a coherent physical and gameplay system.

**How I approached it**
I build modular vehicle architecture with separate parts, damage logic, tracked movement and shooting. Experiments extend to multiplayer, PvP/PvE modes, capture zones, procedural cities, vegetation and optimization.

**The outcome**
An ongoing independent development space for testing how physical simulation, modular design and gameplay fit together.

**Tools & technologies**
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


From hard-surface models to game-ready assets

Independent modelling and asset preparation

I use Blender to build and prepare hard-surface models, materials and textures for game environments.

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

**The challenge**
A 3D asset needs to work both visually and within the constraints of a real-time application.

**How I approached it**
I work across modelling, hard-surface geometry, materials and textures. Asset preparation includes optimization for use in game projects, connecting visual work with the technical needs of the runtime.

**The outcome**
A collection of independent 3D work that complements my experience with game systems and physical engineering.

**Tools & technologies**
Blender, 3D modelling, Hard-surface modelling, Materials, Textures, Game-ready assets, Asset optimization

### Engine Sim Unity Audio


Physical simulation as a source of game audio

Independent audio tooling

I worked on automated generation of engine audio banks for Unity from a physical engine simulator.

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

**The challenge**
Simulation output needed to become a usable set of engine sounds for a game project.

**How I approached it**
I connected physical engine simulation to automated audio-bank generation. The work focuses on the tooling between sound generation and preparation of assets for Unity.

**The outcome**
A tooling project connecting simulation, automation and game-asset production.

**Tools & technologies**
Unity, Engine audio banks, Physical engine simulation, Audio generation, Asset automation

- [Engine Sim Unity Audio · GitHub](https://github.com/Vangardo/engine-sim-unity-audio) — Source and documentation for my offline audio-bank generator, built on AngeTheGreat’s Engine Simulator.

Source code · Public page · Links checked: 2026-09-27

### Crypto Trading Terminal


Market data, strategies and execution in one tool

Independent application development

I built a trading terminal combining market data, charting, custom strategies, backtesting and live exchange execution.

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

**The challenge**
Strategy research needed a connected path from historical data and indicators to execution and recorded results.

**How I approached it**
I combined charting and SMA, EMA, MACD, TMA and RSI indicators with user-defined strategies and backtesting. Live exchange execution, commissions, P&L and result persistence formed the operational side of the terminal.

**The outcome**
The application brought strategy analysis and exchange execution into one workflow, including commissions, P&L and recorded results.

**Tools & technologies**
Market data, Charting, SMA, EMA, MACD, TMA, RSI, Backtesting, User-defined trading strategies, Live exchange execution, Commissions, P&L, Results persistence

## Contact


[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)

[Download CV](https://bartenev.site/cv/igor-bartenev-en.pdf)

[Live work & references](https://bartenev.site/en/resources/)