# Igor Bartenev


Architekt oprogramowania / Lider techniczny · Polska

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

Python · FastAPI · PostgreSQL · Elasticsearch · Redis

Architekt oprogramowania i lider techniczny łączący projektowanie z implementacją w commerce, automatyzacji biznesu i infrastrukturze agentów AI. Przekładam wymagania na modele danych, modułowe usługi backendowe i integracje, prowadząc rozwiązania do wdrożenia. Doświadczenie w produkcji i ERP pomaga mi łączyć oprogramowanie z rzeczywistą pracą ludzi.

## Kluczowe doświadczenie


### Onlihub · Początek: luty 2022


Lead Developer · architektura i odpowiedzialność techniczna

Dołączyłem do istniejącej platformy jako drugi programista; po odejściu lidera przejąłem odpowiedzialność techniczną. Przebudowałem architekturę aplikacji i bazy danych, koordynowałem mały zespół międzyfunkcyjny i współpracowałem z CEO nad wykonalnością oraz wdrożeniem.

Implementowałem usługi backendowe łączące katalogi dostawców, oferty, zapasy, zamówienia i realizację. Modelowałem identyfikatory zewnętrzne i reguły synchronizacji systemów o różnych danych i cyklach aktualizacji.

### Artekom · Styczeń 2020 - luty 2022


Programista 1C → produkty Python i automatyzacja

Łączyłem księgowość, serwisy WWW i API w 1C; w 2021 przeszedłem do produktów Python. Tworzyłem procesy Telegram → ERP i terminal desktopowy z testowaniem strategii oraz realizacją zleceń giełdowych.

### Technopark Pozh Tekhnika · 2013 - styczeń 2020


Inżynieria produkcji → automatyzacja ERP

Projektowałem części, oprzyrządowanie i procesy CNC dla produkcji seryjnej. Od lutego 2019 wdrażałem i rozwijałem 1C dla materiałów, planowania produkcji, raportowania i płac.

## Wybrane realizacje techniczne


### Konfigurowalne procesy biznesowe


Zaprojektowałem i zbudowałem platformę używaną przez firmę hipoteczną obok Encompass. Konfigurowalne formularze, OCR dokumentów, zadania i reguły naliczeń połączyły wnioski klientów z obsługą wewnętrzną. Klienci odpowiadali raz i widzieli wymagane dokumenty; pracownicy otrzymywali przypisane zadania przy mniejszej ręcznej koordynacji.

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

### Zbieranie danych na dużą skalę


Zaprojektowałem równoległe skanowanie, koordynację proxy i kont, normalizację oraz przetwarzanie wsadowe Elasticsearch. Archiwalny projekt danych marketplace’u obsługiwał miliony ofert przez około pięć miesięcy (historyczna skala według mojego doświadczenia).

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

### Kontrolowany dostęp agentów AI do narzędzi


Zbudowałem MCP Hub: wyszukiwanie narzędzi, schematy na żądanie, zachowane wyniki i wykonanie z kontrolą uprawnień; korzystam z niego codziennie. Osobna integracja open source dla Unity zmniejszyła 48 narzędzi widocznych dla modelu do 6, zachowując 377 operacji. Benchmark schematów jest publiczny.

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

## Narzędzia techniczne


- Backend i dane: Python, FastAPI, SQL, PostgreSQL, Elasticsearch, Redis; katalog w Rust; złożone zapytania, ograniczenia, wyzwalacze i cache TTL.

- Architektura: Modele domenowe; usługi modułowe; porty i adaptery; obieg dokumentów, formuły, uprawnienia; idempotencja i odzyskiwanie.

- Integracje i operacje: REST, webhooks, OAuth, WebSocket; workery, kolejki, procesy wsadowe; Docker, Linux i diagnostyka produkcyjna.

- Infrastruktura AI: MCP, wyszukiwanie narzędzi i orkiestracja; lokalne embeddings i wyszukiwanie hybrydowe; budżety kontekstu, zatwierdzenia i historia wykonania.

## Wykształcenie


Narodowy Uniwersytet Techniczny „Charkowski Instytut Politechniczny”
Dyplom specjalisty · Wrzesień 2008 — luty 2014
Automatyzacja i technologie zintegrowane komputerowo

## Doświadczenie interdyscyplinarne


TON Tanks: produkt, backend i uruchomienie gry Telegram / TON. Pozostałe prace: modułowe pojazdy w Unity, zasoby 3D i eksperymenty z lokalnym AI dla mowy i dokumentów.

## Kompetencje


### E-commerce i integracje


Katalogi, marketplace’y, magazyny, zamówienia i realizacja: wspólny model oraz granice między systemami.

Architektura i implementacja platform wielokanałowych

Zaprojektowałem wspólne modele produktów, stanów i zamówień dla Onlihub oraz MySellerHub, łącząc kanały o różnych modelach magazynów i identyfikatorach zewnętrznych.

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

[E-commerce i integracje](https://bartenev.site/pl/expertise/#domain-commerce-integrations)

### Systemy biznesowe


Dla firmy hipotecznej połączyłem formularze klientów z dokumentami, OCR, zadaniami pracowników, rozliczeniami i Encompass. Konfigurowalne formularze i reguły biznesowe pozwalają wspólnemu rdzeniowi obsługiwać różne scenariusze pracy.

Modelowanie biznesu, architektura i własna implementacja

Odpowiedzi klienta określają kolejne pytania i wymagane dokumenty. OCR przenosi wartości z plików do pól; zdarzenia dokumentów przypisują uczestników i zadania. Pracownicy korzystają z własnych tablic Kanban, a rekordy i wybrane statusy trafiają do Encompass. Obliczenia i naliczenia zachowują powiązania ze źródłami.

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

[Systemy biznesowe](https://bartenev.site/pl/expertise/#domain-business-systems)

### Backend, dane i scraping


Scraping na dużą skalę z przetwarzaniem równoległym i pulami proxy; wsadowy odczyt i zapis w Elasticsearch; osobne ścieżki bazy, cache, odczytu i workerów.

Architektura, implementacja i optymalizacja wydajności

Amazon data: zbieranie równoległe i operacje wsadowe Elasticsearch. Catalog: odczyt w Rust, zapasowy Python i cache Redis. Onlihub: moduły biznesowe z jawnymi kontraktami aplikacji, portami repozytoriów i adapterami infrastruktury.

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, dane i scraping](https://bartenev.site/pl/expertise/#domain-backend-data)

### Infrastruktura AI


MCP Hub łączy odkrywanie narzędzi, lokalne embeddings i metody do ponownego użycia z kontrolowaną pracą z bazami danych, logami, zadaniami oraz komunikacją.

Architektura i własna implementacja infrastruktury agentów

Zaimplementowałem hybrydowe wyszukiwanie wiedzy, opcjonalny lokalny reranking metod i oceny doświadczeń. Schematy na żądanie, zapisane wyniki, wspólne budżety runnera oraz trwałe przebiegi automatyzacji pomagają kontrolować wykonanie i kontekst.

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

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

### Przywództwo techniczne


Zaczynać od celu biznesowego, opracować rozwiązanie i przełożyć je na kod. Moja praca łączy architekturę, omawianie wariantów z interesariuszami, własną implementację i koordynację tam, gdzie wymaga tego projekt.

Odpowiedzialność za rozwiązanie, architekturę i implementację

Dla BOS zaproponowałem i rozwinąłem rozwiązanie, uzasadniłem architekturę przed biznesem i dopracowywałem ją pod rzeczywiste procesy. W Onlihub przejąłem architekturę, bazę, backend i integracje po odejściu głównego programisty, koordynowałem rozwój i doradzałem CEO w kwestii wykonalności.

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

[Przywództwo techniczne](https://bartenev.site/pl/expertise/#domain-technical-leadership)

### Inżynieria produkcji


Produkcja, CAD/CAM i CNC stworzyły fundament: zrozumieć materiały, operacje oraz ograniczenia przed automatyzacją.

Inżynieria i automatyzacja produkcji

Przygotowywałem części, programy maszyn i dokumentację do produkcji seryjnej; usprawniałem operacje i zużycie materiałów, a następnie automatyzowałem planowanie oraz ewidencję w 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

[Inżynieria produkcji](https://bartenev.site/pl/expertise/#domain-engineering-foundations)

### Gry i 3D


Własne projekty: backend gier, TON, fizyka Unity, pojazdy modułowe, światy proceduralne i zasoby 3D.

Własne produkty i rozwój systemów gier

Kierowałem rozwojem TON Tanks i tworzyłem backend oraz logikę gry. Własny projekt Unity rozwija modułowe czołgi, fizykę gąsienic, uszkodzenia i proceduralne miasta.

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

[Gry i 3D](https://bartenev.site/pl/expertise/#domain-games-3d)

## Projekty


### Onlihub


Odpowiedzialność techniczna za platformę commerce

Lead Developer · architektura, implementacja i rozwój

Przejąłem odpowiedzialność techniczną za rozwój platformy łączącej dostawców, produkty, marketplace’y i realizację zamówień.

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

**Podłączenie sklepu to więcej niż wywołanie API**

Przykładowy przebieg na podstawie implementacji

Sprzedawca podłącza kanał sprzedaży. Dostawca może odpowiadać wolno, a żądanie może nadejść ponownie. Aplikacja musi wiedzieć, co zlecono, kto to przetwarza i czy operacja się zakończyła.

1. Sprawdzić właściciela sklepu i możliwości integracji.

2. Zapisać żądanie podłączenia z kluczem idempotencji i wpisem outbox.

3. Przekazać zadanie workerowi, odnawiać dzierżawę i zapisać zakończenie lub błąd.

**Co to umożliwia**
Żądanie podłączenia ma zapisany cykl życia i nie zależy od jednego długiego żądania HTTP. Ponowienia i wyczerpanie prób są obsługiwane jawnie.

**Decyzja i kompromis**
Obecna implementacja zapisuje zamiar operacji i właściciela zadania w PostgreSQL, ograniczając współbieżność i sprawdzając dzierżawę. Umożliwia to odzyskiwanie, ale wymaga zarządzania stanem i pracy w tle. Dostarczenie ma semantykę at least once: efekt u dostawcy wymaga idempotencji lub uzgodnienia; lokalny token nie gwarantuje jednokrotnego wykonania w zewnętrznej usłudze.

**Wyzwanie**
Operacje handlowe wymagały spójności między różnymi modelami produktów, magazynami i systemami zewnętrznymi.

**Moje podejście**
Po odejściu lead developera przejąłem rozwój i przebudowałem architekturę aplikacji oraz bazy danych. Implementowałem asynchroniczny backend FastAPI, złożone zapytania PostgreSQL i integracje systemów handlowych oraz magazynowych, koordynując zespół i doradzając CEO w kwestiach wykonalności.

**Rezultat**
Praca objęła cykl produktu od katalogu i stanów magazynowych po zamówienia, realizację i śledzenie, z odpowiedzialnością za całą platformę.

**Od programisty do odpowiedzialności technicznej**
Dołączyłem do startupu, pracując u boku doświadczonego leada. Po jego odejściu przejąłem architekturę, bazę i backend, koordynowałem niewielki zespół międzyfunkcyjny i prowadziłem produkt przez implementację, utrzymanie oraz dalszy rozwój. Rozmowy z CEO łączyły pomysły biznesowe z wykonalnością techniczną i decyzjami o realizacji.

**Wspólny model różnych kanałów**
Pierwotna platforma miała szerszy zakres multichannel: produkt z jednego źródła można było opublikować w innym kanale. Pracowałem z Amazon, Walmart, eBay, TikTok Shop, Shopify i integracjami magazynowymi, uzgadniając produkty, identyfikatory, magazyny rzeczywiste i wirtualne, stany, zamówienia oraz tracking. Ten pierwotny zakres przyczynił się później do powstania MySellerHub.

**Usługi asynchroniczne i złożony SQL**
Tworzyłem i dokumentowałem API FastAPI z przetwarzaniem asynchronicznym, wątkami i zarządzaniem kolejkami. Praca z PostgreSQL obejmowała zapytania dynamiczne i optymalizację dużych zbiorów danych. Narzędzia zadań cyklicznych, parsery i analiza w PowerBI uzupełniały backend, wspierając integracje i procesy operacyjne.

**Architektura rozwijająca się wraz z produktem**
Platforma rozwinęła się w powiązane produkty o różnych zadaniach: operacje dostawców, procesy detalistów i osobny katalog obsługujący duże obciążenia. Pracowałem nad architekturą i implementacją, w tym subskrypcjami oraz płatnościami jednorazowymi. Onlihub pojawił się później jako integracja Amazon MCF; to etap rozwoju produktu odrębny od mojego zakresu odpowiedzialności inżynierskiej.

**Moja odpowiedzialność**
Dołączyłem do istniejącej platformy w lutym 2022 jako drugi programista. Po odejściu lidera przejąłem architekturę aplikacji, bazę danych i backend, koordynowałem mały zespół międzyfunkcyjny i współpracowałem z CEO nad wykonalnością oraz wdrożeniem.

- Wspólny model commerce łączy katalog, stany, zamówienia, realizację i tracking między systemami różnych kanałów.

- API i przetwarzanie w tle obsługują integracje marketplace’ów oraz magazynów, uzgadniając zewnętrzne identyfikatory i stany.

**Publiczne informacje o produkcie**

Liczby publikowane przez Onlihub opisują deklarowaną skalę platformy, osobno od mojego wkładu i okresu pracy. Amazon wymienia Onlihub jako integrację MCF.

- 10,000+: sklepów w sieci platformy

- 40,000+: zrealizowanych zamówień MCF

[Onlihub · dane produktu](https://onlihub.com/)

[Amazon · strona integracji](https://supplychain.amazon.com/integrations/onlihub)

Źródła sprawdzono: 2026-09-27

**Narzędzia i technologie**
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 · platforma handlowa](https://onlihub.com/) — Publiczna strona produktu: zapasy FBA, sieć sprzedawców i realizacja zamówień przez Amazon MCF.

Produkt · Publiczna strona · Linki sprawdzone: 2026-09-27

- [Onlihub w Amazon MCF](https://supplychain.amazon.com/integrations/onlihub) — Strona integracji na witrynie Amazon opisuje przekazywanie zamówień Onlihub do Multi-Channel Fulfillment.

Źródło zewnętrzne · Publiczna strona · Linki sprawdzone: 2026-09-27

Potwierdza obecność integracji w katalogu, a nie certyfikację produktu lub jego twórcy.

- [Centrum pomocy Onlihub](https://support.onlihub.com/) — Publiczne instrukcje dostępne z witryny Onlihub.

Dokumentacja · Publiczna strona · Linki sprawdzone: 2026-09-27

### BOS / Business Operations System


Od formularza klienta do obsługi kredytu hipotecznego

Projektowanie rozwiązania, architektura i własna implementacja

Zaprojektowałem i zbudowałem platformę operacyjną używaną przez działającą firmę hipoteczną. Warunkowe formularze klientów, OCR dokumentów, zadania pracowników i reguły naliczeń połączyłem z procesami w Encompass.

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

**Jeden formularz uruchamia proces obsługi**

Wykorzystanie w firmie hipotecznej · relacja autora

Działająca firma hipoteczna obsługiwała wnioski w Encompass, ręcznie zbierając znaczną część danych i koordynując pracę. Zbudowałem BOS, aby połączyć nową stronę dla klientów z ludźmi, dokumentami i działaniami potrzebnymi do obsługi każdego wniosku.

1. Odpowiedzieć raz. Zatrudnienie, dochód i wcześniejsze odpowiedzi określają kolejne pytania i wymagane dokumenty. Pracownicy i pośrednicy sami konfigurują formularze.

2. Przesłać wymagane pliki. Automatyzacja tworzy powiązane dokumenty i zadania; OCR przenosi wartości do pól, dając pracownikom uporządkowane informacje.

3. Prowadzić wniosek dalej. Uczestnicy pracują z listami zadań i tablicami Kanban; dokumenty, identyfikatory zewnętrzne i wybrane statusy są wymieniane z Encompass.

**Co to umożliwia**
Klienci otrzymali jasną ścieżkę od odpowiedzi do wymaganych dokumentów. Pracownicy dostawali przypisane zadania, co ograniczyło ręczną koordynację przekazywania pracy. Firma zachowała Encompass i zyskała połączoną z nim obsługę nowych wniosków i operacji.

**Decyzja i kompromis**
Formularze, schematy dokumentów i reguły biznesowe uczyniłem konfigurowalnymi, aby zmiana procesu nie wymagała za każdym razem osobnej logiki wniosku w kodzie. Konfiguracja hipoteczna korzysta ze wspólnego rdzenia. Elastyczność wymaga jawnych warunków, zasad dostępu i przejść stanu. Obliczenia, działania na zdarzeniach dokumentów i ewidencja wynagrodzeń pozostają oddzielnymi modułami z określonymi wejściami i wynikami.

**Wyzwanie**
Firma pracowała w Encompass bez strony do przyjmowania wniosków klientów. Pracownicy ręcznie zbierali informacje, ustalali wymagane dokumenty i koordynowali dalsze działania. Zatrudnienie, dochód i inne okoliczności zmieniały wymagania, utrudniając organizację każdego nowego wniosku.

**Moje podejście**
Zaproponowałem rozwiązanie, uzasadniałem decyzje architektoniczne przed biznesem i rozwijałem system według rzeczywistych scenariuszy pracy. Konfigurowalne formularze dobierają pola, kroki i dokumenty na podstawie odpowiedzi klienta. Zdarzenia dokumentów tworzą zadania i przypisują uczestników; OCR wypełnia pola z przesłanych plików. Osobne moduły obsługują obliczenia, dostęp, naliczenia i wymianę z Encompass. Rdzeń dokumentów i reguł zaprojektowałem do ponownego użycia także poza hipotekami.

**Rezultat**
Firma otrzymała stronę do przyjmowania wniosków połączoną z wewnętrzną obsługą. Klient mógł odpowiedzieć raz i zobaczyć wymagane dokumenty; pracownicy otrzymywali przypisane zadania i pracowali na powiązanych rekordach przekazywanych do Encompass. Uprościło to obsługę wniosków i ograniczyło ręczną koordynację.

**Formularze dostosowane do sytuacji klienta**
Pracownicy i pośrednicy mogą konfigurować formularze dla klientów. Odpowiedzi określają widoczne i aktywne pola, kolejny krok oraz wymagane dokumenty. Zatrudnienie i dochód mogą prowadzić różnymi ścieżkami, z uwzględnieniem wcześniejszych kroków. Ukończony formularz uruchamia skonfigurowane działania na dokumentach i zadaniach.

**Przesłane dokumenty stają się danymi do pracy**
Klienci przesyłają pliki do rekordów wymaganych dokumentów. OCR wykorzystuje niewielki model neuronowy do przenoszenia wartości do pól; prywatność dokumentów była istotnym wymaganiem. Konfigurowalne kolumny i pola pozwalają rozszerzać model danych wraz ze zmianą potrzeb. Odczytane wartości są używane w procesach dokumentów, obliczeń i zadań.

**Zadania dla każdego uczestnika**
Reguły przypisują uczestników dokumentów i tworzą zadania dla ich części procesu kredytowego. Każda osoba ma listę zadań lub tablicę Kanban; zadania można przekazać innej osobie lub wykonać ponownie. Statusy zadań i dokumentów opisują różne rodzaje postępu. Parametryzowane szablony wiadomości są adresowane do użytkowników lub kontaktów.

**Połączenie z istniejącym procesem w Encompass**
BOS wymienia dokumenty z Encompass, wiążąc zewnętrzne identyfikatory i wybrane statusy. Import, eksport i synchronizacja korzystają z mapowań oraz zapisów zadań integracyjnych, łącząc formularz klienta z dotychczasowym systemem firmy. Przewidzianym scenariuszem integracji jest krok zależny od podpisu: dostawca taki jak PandaDoc może dostarczyć status podpisania przed kontynuacją procesu.

**Organizacje i dostęp**
Proces hipoteczny działa w modelu organizacji, działów, członkostwa i ról. Uprawnienia łączą dozwoloną operację z zakresem dostępu i warunkami dotyczącymi danych. Dzięki temu dostęp do dokumentów odpowiada obowiązkom danej osoby w organizacji.

**Dokumenty i formularze ze stanem**
Typy dokumentów definiują pola typowane, słowniki i relacje nadrzędny–podrzędny. Formularze wieloetapowe obsługują pola zagnieżdżone i powtarzalne, zapisują odpowiedzi oraz tworzą lub łączą dokumenty po zakończeniu. Oczekiwana wersja w żądaniu pozwala wykryć nieaktualną edycję i zwrócić konflikt.

**Procesy obliczeniowe**
Obliczenie łączy atrybuty dokumentów, stałe i wcześniejsze wyniki formuł. Podgląd pokazuje wartości i ich źródła; uruchomienie procesu tworzy dokument z wynikiem. Jednym z zastosowań jest obliczanie dochodu na potrzeby kredytu hipotecznego. Szablony wydruku przekształcają dane dokumentu w PDF.

**Wynagrodzenie powiązane z pracą**
Rozliczenia obejmują stałe kwoty miesięczne, premie za zamknięte kredyty oraz naliczenia po osiągnięciu przez dokument uczestnika określonego statusu. Reguły wyznaczają odbiorcę i podstawę: kwoty stałe, procenty, punkty bazowe i limity. Zapisy wewnętrzne zachowują dokument i regułę źródłową, także dla potrąceń i poleceń; jest to ewidencja wynagrodzeń, nie przelew bankowy.

**Moja odpowiedzialność**
Zaprojektowałem i rozwinąłem BOS dla działającej firmy hipotecznej: ustalałem potrzeby, proponowałem warianty, uzasadniałem decyzje architektoniczne i dopracowywałem implementację wspólnie z biznesem. Odpowiadałem za rozwiązanie i jego kod.

- Konfigurowalne typy dokumentów i formularze wieloetapowe zbierają powiązane dane. Osobne procesy obliczeniowe pokazują wyniki formuł lub tworzą nowe dokumenty.

- Zakresy dostępu i reguły zdarzeń sterują działaniami na dokumentach. Naliczenia zależne od statusu zachowują dokument oraz regułę źródłową, a baza sprawdza zapisy transakcji.

**Narzędzia i technologie**
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


Orkiestracja agentów, wiedza projektowa i ponowne wykorzystanie doświadczeń

Infrastruktura agentów i architektura integracji

Zbudowałem usługę, w której agenci znajdują narzędzia i wiedzę projektową, pracują z połączonymi systemami oraz zachowują przydatne metody do kolejnych zadań.

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

**Wyjaśnianie rozbieżności między połączonymi usługami**

Przykładowy przebieg na podstawie implementacji

Agent bada rozbieżność stanów magazynowych i przygotowuje zadanie wyjaśniające. Potrzebuje danych z połączonych usług, wystarczającego kontekstu oraz jasnej granicy przed wprowadzeniem zmian.

1. Znaleźć potrzebne narzędzia w dozwolonym katalogu i załadować tylko ich dokładne schematy.

2. Czytać w ramach wspólnego budżetu; zachować duże odpowiedzi jako artefakty z podglądem.

3. Sprawdzić uprawnienia działania, uzyskać wymagane zatwierdzenie i zachować wynik wykonania.

**Co to umożliwia**
Agent otrzymuje kontekst skupiony na zadaniu, a operator może sprawdzić działanie, decyzję o dostępie i zapisany wynik. Zatwierdzenie pozostaje związane z uzgodnioną akcją i argumentami.

**Decyzja i kompromis**
Selektywne wyszukiwanie dodaje krok, ale nie ładuje wszystkich schematów integracji do każdego żądania. Podglądy zmniejszają bieżący kontekst; pełne artefakty trzeba pobrać osobno i mają one ograniczony czas przechowywania. Nieznany wynik zapisu zewnętrznego pozostaje nieznany — nie jest zgłaszany jako sukces ani ślepo ponawiany.

**Wyzwanie**
Pytania operacyjne dotyczą wielu systemów, a szeroki dostęp do baz i rosnący katalog narzędzi stwarzają problemy z uprawnieniami oraz kontekstem agentów.

**Moje podejście**
Połączyłem schematy narzędzi pobierane na żądanie, wykonanie w granicach uprawnień i zapisane wyniki z lokalnymi embeddings, wyszukiwaniem pełnotekstowym oraz metodami do ponownego użycia. Własny runner agentów współdzieli budżety między delegowanymi zadaniami, a automatyzacje zachowują przebiegi i stany zatwierdzania. Wiedza, zaobserwowane wywołania i oceny pozostają rozdzielone, aby kolejne zadania mogły korzystać z doświadczeń w ich kontekście.

**Rezultat**
Korzystam z MCP Hub do badania błędów, przeglądu komunikacji i analizy aktywności projektów w bazach, logach oraz narzędziach pracy. Potrzebne schematy, zapisane wyniki i wcześniejsze metody można otwierać na żądanie, skupiając kolejne analizy na zadaniu.

**Najpierw operacja, potem jej schemat**
Wyszukiwanie narzędzi zwraca zwięzłe wyniki ze wskazówkami argumentów, informacją o ryzyku i odwołaniem do schematu sprawdzanym przy wywołaniu. Agent pobiera dokładny schemat wybranej operacji, a następnie wywołuje ją po nazwie. Pełny katalog integracji pozostaje poza promptem, zachowując prostą drogę od zamiaru do aktualnego kontraktu narzędzia.

**Lokalne embeddings i wyszukiwanie hybrydowe**
Wiedza projektowa łączy FTS5 z lokalnymi embeddings SentenceTransformer. Strumieniowy przegląd wektorów wybiera ID najlepszych fragmentów przed pobraniem treści, a hashe pozwalają pominąć ponowną wektoryzację niezmienionego tekstu. Metody do ponownego użycia mają osobną ścieżkę: wybór semantyczny i leksykalny, po którym opcjonalny lokalny CrossEncoder ocenia zgodność z zadaniem.

**Zakres projektu i dowody wykonania**
Analiza wielu systemów zaczyna się od dozwolonych projektów, zasobów i operacji. W tym zakresie można badać rekordy baz, logi i komunikację. Wywołania wymagające zatwierdzenia czekają na decyzję człowieka. Potwierdzenia wykonania wiążą zaobserwowane wyniki z bieżącym przebiegiem, a historia audytu zapisuje działania i pomaga sprawdzić końcowy wniosek.

**Metody z zachowanym kontekstem i oceną**
Agent może zapisać cel, warunki zastosowania, warunkowy plan wywołań i wnioski z nieudanych prób. Kolejne zadania otrzymują niewielki zestaw metod do użycia, adaptacji lub pominięcia. Ocena przydatności i potwierdzony sukces pozostają osobnymi sygnałami. Uczenie polega na gromadzeniu i dopracowywaniu doświadczeń; ponowne użycie bez zmian zachowuje istniejącą metodę i jej embedding.

**Wspólna kontrola delegowanych zadań**
Wbudowany runner agentów używa wspólnego kontrolera tokenów, wywołań modeli, prób narzędzi, workers i współbieżności dla delegowanej pracy. Termin i anulowanie obejmują drzewo wykonań, a rezerwacje operacji śledzą nakładające się żądania. Orkiestracja zachowuje wspólny budżet i jawne przypisanie wykonania, gdy agenci dzielą zadanie.

**Automatyzacje z zapisanymi przebiegami**
Wyzwalacze cron, interval i event uruchamiają operację narzędzia lub wieloetapowy proces agenta. Stan przebiegów jest zapisany w SQLite; workers przejmują pracę z właścicielem i lease, a wygasłe lease można odzyskać. Oczekiwanie na zatwierdzenie ma jawny stan. Cykliczne kontrole aktywności projektów i komunikacji korzystają z tej samej kontrolowanej warstwy integracji.

**Dostępne wyniki i zwięzły kontekst**
Wyniki są przechowywane w postaci zaszyfrowanej; dostęp przez uchwyt uwzględnia właściciela, termin ważności i wersję polityki. Fragmenty wiedzy można czytać wybiórczo, a pakiety pamięci ograniczają liczbę elementów i znaków. Opisy metod odsyłają do większych planów; małe zachowują warunki bezpośrednio. Agent wraca do szczegółów bez kopiowania każdej surowej odpowiedzi do rozmowy.

**Moja odpowiedzialność**
Zaprojektowałem i zbudowałem warstwę integracji oraz własny runtime agentów: wyszukiwanie narzędzi, wiedzę projektową, kontrolę wykonania i ponowne użycie doświadczeń.

- Lokalne embeddings i wyszukiwanie hybrydowe odnajdują potrzebną wiedzę. Schematy narzędzi i zapisane wyniki otwierają się na żądanie, utrzymując kontekst wokół zadania.

- Agenci i trwałe automatyzacje korzystają z wykonania w granicach uprawnień, zatwierdzeń, zapisów wyników i budżetów. Ukończona praca może jawnie wzbogacać metody; wagi modelu nie są trenowane.

**Narzędzia i technologie**
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


Pozyskiwanie danych Amazon na dużą skalę i analiza trendów

Architektura pozyskiwania i przetwarzania danych

Zaprojektowałem i zbudowałem usługę danych Amazon, która skanowała kategorie marketplace’u z wyjątkiem książek i korzystała z operacji wsadowych Elasticsearch do wykrywania trendów.

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

**Od rozproszonych ofert do użytecznego zbioru danych**

Historyczny proces · dane autora

Badanie trendów produktowych w kategoriach wymagało połączenia zbierania i przechowywania danych. Pobieranie stron było pierwszym krokiem: niejednorodne rekordy potrzebowały wspólnej reprezentacji i wydajnej ścieżki do analizy.

1. Zbierać dane kategorii równolegle, koordynując konta, proxy, częstotliwość i ponowienia.

2. Normalizować rekordy przed indeksowaniem wsadowym w Elasticsearch.

3. Odczytywać grupy rekordów do analizy zamiast osobnego żądania dla każdej oferty.

**Co to umożliwia**
Zbiór danych obejmujący kategorie wspierał analizę trendów. Archiwalna usługa obsługiwała miliony ofert przez około pięć miesięcy; to historyczna skala podana przeze mnie, a nie aktualny benchmark przepustowości.

**Decyzja i kompromis**
Podejście wsadowe obejmowało zapis i odczyt, zmniejszając liczbę pojedynczych odwołań do bazy. Kompromis: dane stają się dostępne grupami, a nie natychmiast dla każdej pozycji. Pokrycie i świeżość zależą od źródła zewnętrznego; wielkość zbioru nie dowodzi trafności trendu czy prognozy.

**Wyzwanie**
Zakres katalogu wymagał równoległego pozyskiwania i strategii przechowywania milionów ofert bez wykonywania osobnego odczytu lub zapisu dla każdej pozycji.

**Moje podejście**
Równoległe parsery łączyły zarządzanie kontami i proxy, ograniczanie częstotliwości oraz ponowienia podczas skanowania kategorii. Zorganizowałem normalizację i pracę z Elasticsearch wokół zapisów oraz odczytów wsadowych, utrzymując ten model wraz ze wzrostem danych. Wyniki służyły analizie zmian i trendów.

**Rezultat**
Usługa działała około pięciu miesięcy w historycznej skali rzędu milionów ofert. Wspierała analizę trendów w kategoriach, po czym zespół zmienił priorytety, a projekt trafił do archiwum.

**Historyczny zakres kategorii**
Projekt skanował kategorie katalogu Amazon, celowo wyłączając książki. Historyczny zakres danych był rzędu milionów ofert. Taka skala łączyła pozyskiwanie, normalizację i przechowywanie w jeden problem: dane kategorii musiały utworzyć spójny zbiór do analizy wsadowej.

**Pozyskiwanie przy ograniczeniach zewnętrznych**
Parsery musiały uwzględniać blokady, wiele kont, proxy i nieudane żądania. Przetwarzanie równoległe, ograniczanie częstotliwości oraz ponowienia były częścią architektury pozyskiwania. Normalizacja zapewniała indeksowaniu i analizie spójną reprezentację mimo różnic w danych źródłowych.

**Wsadowy zapis i odczyt**
Elasticsearch obsługiwał zarówno zapis, jak i odczyt wsadowy. Grupowanie było ważne po obu stronach: zebrane rekordy indeksowano razem, a analiza pobierała ich partie, ograniczając udział pojedynczych żądań w obciążeniu. Ta decyzja kształtowała przepływ danych równie mocno jak wybór silnika wyszukiwania.

**Analiza trendów i zamknięty etap produktu**
Celem zbierania było wykrywanie zmian i trendów w danych produktowych. Usługa działała około pięciu miesięcy, zanim priorytety przesunęły się na inne prace. Zarchiwizowany projekt obejmuje cały łańcuch inżynierski: równoległe pozyskiwanie, normalizację, wsadowy dostęp do danych i analizę dużego historycznego zbioru.

**Moja odpowiedzialność**
Zaprojektowałem i zaimplementowałem ścieżkę od pozyskiwania do analizy: zbieranie równoległe, normalizację i wsadowy dostęp do Elasticsearch.

- Równoległe parsery uwzględniają błędy i ograniczenia zewnętrzne przez kontrolę częstotliwości oraz ponowienia; normalizacja przygotowuje spójny zbiór danych.

- Indeksowanie i analiza działają wsadowo, więc przepływ danych nie wymaga osobnego żądania do magazynu dla każdej oferty.

**Historyczna skala · dane autora**

Usługa działała około pięciu miesięcy przy historycznym zakresie rzędu milionów ofert. Wspierała analizę trendów kategorii, zanim projekt zarchiwizowano.

**Narzędzia i technologie**
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


Od arkuszy dostawców do marketplace’u

Architektura produktu i przetwarzanie danych

Zbudowałem proces przekształcający rozproszone oferty wyprzedaży zapasów w uporządkowane, przeszukiwalne oferty produktów.

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

**Wyzwanie**
Kupujący musieli ręcznie przeglądać niespójne arkusze i wiadomości z niepełnymi danymi produktów.

**Moje podejście**
Połączyłem import wiadomości i arkuszy z normalizacją, identyfikacją przez kod kreskowy lub ASIN oraz wzbogacaniem danych. AI wspierało porządkowanie niepełnych informacji i kategoryzację, a operatorzy widzieli stany przetwarzania i błędy.

**Rezultat**
Pliki dostawców stały się ofertami powiązanymi z cenami, zapasami i magazynami, w produkcie obsługującym kupujących, sprzedawców, czaty i zamówienia.

**Narzędzia i technologie**
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 · katalog hurtowy](https://liqsale.com/) — Publiczny katalog hurtowy i wyprzedażowy z informacjami o produktach i magazynach.

Produkt · Publiczna strona · Linki sprawdzone: 2026-09-27

- [Daily Snipes · katalog](https://dailysnipes.com/) — Ta sama rodzina produktów hurtowych pod nazwą Daily Snipes, wymienioną również w witrynie Liqsale.

Produkt · Publiczna strona · Linki sprawdzone: 2026-09-27

### Unity MCP Efficient


Mniejszy interfejs narzędzi z dostępem do pełnego katalogu operacji

Projekt i implementacja fasady

Zbudowałem warstwę zgodności, dzięki której agenci odkrywają operacje Unity bez ładowania wszystkich schematów narzędzi do kontekstu.

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

**Wyzwanie**
Duży zestaw narzędzi widocznych dla modelu zajmował kontekst, zanim agent wybrał potrzebną operację.

**Moje podejście**
Oddzieliłem wyszukiwanie od wykonania, udostępniając schematy operacji na żądanie i ograniczając rozmiar wyników. Operacje wsadowe, zapisane wyniki, potwierdzenia i idempotentne ponowienia uwzględniają powtórzone zmiany, asynchroniczność oraz przeładowania domeny Unity.

**Rezultat**
Opublikowane porównanie autora z 24 sierpnia 2026, względem upstream v10.1.0, podaje 48 → 6 narzędzi widocznych dla modelu i dostęp do 377 operacji. Kontekst schematów spada z 23 280 do 915 szacowanych tokenów (znaki ÷ 4); to udokumentowana estymacja, a nie niezależnie odtworzony test szybkości lub kosztu.

**Moja odpowiedzialność**
Zaprojektowałem i zaimplementowałem fasadę zgodności, oddzielając wyszukiwanie operacji od wykonania i udostępniając schematy na żądanie.

- Zwięzły interfejs widoczny dla modelu zachowuje wyszukiwanie i dostęp do pełnego katalogu operacji.

- Operacje wsadowe, ograniczone wyniki, potwierdzenia i obsługa ponowień wspierają asynchroniczną pracę Unity oraz przeładowania domeny.

**Opublikowane porównanie autora**

Porównanie w README z 24 sierpnia 2026 względem upstream v10.1.0. Tokeny schematów oszacowano jako znaki ÷ 4; pomiar dotyczy deklaracji narzędzi, nie całego kontekstu, szybkości ani kosztu zadania.

- 23,280 → 915: szacowanych tokenów schematów

- 48 → 6: narzędzi widocznych dla modelu

- 377: operacji pozostaje dostępnych

[GitHub · porównanie i metodologia](https://github.com/Vangardo/unity-mcp-efficient#readme)

Źródła sprawdzono: 2026-09-27

**Narzędzia i technologie**
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) — Publiczny kod, instrukcje konfiguracji i testy kompaktowej fasady MCP dla Unity.

Kod źródłowy · Publiczna strona · Linki sprawdzone: 2026-09-27

- [Unity MCP Efficient · metodologia pomiarów](https://github.com/Vangardo/unity-mcp-efficient/blob/main/BENCHMARKS.md) — Odtwarzalne pomiary rozmiaru schematów narzędzi i zwięzłych wyników, z wersją bazową i ograniczeniami.

Dokumentacja · Publiczna strona · Linki sprawdzone: 2026-09-27

Podana redukcja dotyczy rozmiaru kontekstu, nie kosztu API ani ogólnej wydajności zadania.

### MySellerHub


Wspólny model niezależnych kanałów sprzedaży

Architektura multichannel i integracje

Zaprojektowałem model backendu dla produktów, ofert w kanałach, zamówień i magazynów, łącząc aktualizacje zapasów z realizacją zamówień między platformami zewnętrznymi.

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

**Wyzwanie**
Każdy kanał inaczej opisywał ten sam produkt i zamówienie, więc synchronizacja wymagała wspólnego modelu domenowego.

**Moje podejście**
Oddzieliłem produkty od ofert w kanałach i powiązałem identyfikatory zewnętrzne ze wspólnym modelem. Operacje Shopify jako kanału sprzedaży i dostawcy mają osobne ścieżki. Import zamówień łączy się z przypisaniem magazynu, a synchronizacja zapasów śledzi docelową ilość, jej wersję i ostatnio wysłaną wartość.

**Rezultat**
Architektura połączyła publikację produktu w innym kanale ze zwrotnym przekazywaniem statusu realizacji; obecny produkt publiczny koncentruje się na Shopify i zapasach Amazon.

**Kanał sprzedaży i dostawca**
Shopify może być kanałem sprzedaży przyjmującym produkty i przekazującym zamówienia klientów albo dostawcą udostępniającym katalog i realizującym zamówienia zakupu. Te role mają osobne procesy wokół wspólnego modelu produktów i ofert. Zamówienie do dostawcy zawiera lokalny identyfikator używany do wyszukania istniejącego zamówienia zewnętrznego.

**Stan może zmienić się podczas aktualizacji**
Każda docelowa aktualizacja stanu ma ilość i wersję. Po wysłaniu worker sprawdza, czy wersja jest nadal aktualna. Jeśli zapas zdążył się zmienić, rekord pozostaje oczekujący na kolejną próbę. Reguły bufora i maksymalnego stanu korygują cel przed wysłaniem go do kanału.

**Kontynuacja importu zamówienia**
Importowane zamówienie jest wyszukiwane według sklepu, integracji i zewnętrznego ID, a jego pozycje są dopasowywane do ofert. Kolejna synchronizacja może ponowić przypisanie magazynu do istniejących pozycji oraz zaktualizować realizację i tracking. Częściowo przetworzone zamówienie pozostaje w tym samym modelu.

**Moja odpowiedzialność**
Zaprojektowałem model handlu wielokanałowego oraz synchronizację ofert, stanów, zamówień i realizacji.

- Produkty i identyfikatory poszczególnych kanałów trafiają do wspólnego modelu publikacji oraz synchronizacji stanów.

- Zamówienia są powiązane z właściwym źródłem realizacji, a tracking wraca do kanału, z którego pochodzi zamówienie.

**Publiczne informacje o produkcie**

Obecna strona produktu podaje tę wielkość katalogu. Dzisiejsza oferta jest odrębna od szerszego modelu wielokanałowego, nad którym pracowałem.

- 10,000+: produktów gotowych do wystawienia

[MySellerHub · strona produktu](https://mysellerhub.com/)

Źródła sprawdzono: 2026-09-27

**Narzędzia i technologie**
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 · platforma sprzedawcy](https://mysellerhub.com/) — Opis produktu: pozyskiwanie asortymentu, synchronizacja stanów i realizacja zamówień.

Produkt · Publiczna strona · Linki sprawdzone: 2026-09-27

- [MySellerHub · Shopify App Store](https://apps.shopify.com/mysellerhub) — Strona opublikowanej aplikacji wskazuje Onlihub Inc. jako dewelopera i opisuje integracje kanałów sprzedaży.

Źródło zewnętrzne · Publiczna strona · Linki sprawdzone: 2026-09-27

- [Centrum pomocy MySellerHub](https://help.mysellerhub.com/) — Instrukcje wdrożenia, katalogów, ofert, zamówień i ich realizacji.

Dokumentacja · Publiczna strona · Linki sprawdzone: 2026-09-27

### Onlihub Catalog


Różne ścieżki danych dla różnych obciążeń

Architektura i implementacja usługi katalogu

Zaprojektowałem i zaimplementowałem osobną usługę katalogu Onlihub z główną ścieżką w Rust, rezerwową w Python, cache Redis i Elasticsearch.

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

**Wyzwanie**
Duże zbiory ofert i kosztowne zapytania wymagały modelu odczytu dopasowanego do sposobów korzystania z danych.

**Moje podejście**
Rozdzieliłem szybką warstwę obsługi w Rust, rezerwową ścieżkę Python, cache i odczyt/wyszukiwanie od przechowywania transakcyjnego. Równoważenie obciążenia i ograniczanie żądań kontrolowały powtarzalny ruch, a przetwarzanie wsadowe oraz optymalizacja zapytań obsługiwały kosztowne operacje danych.

**Rezultat**
Wyszukiwanie i częste odczyty otrzymały własną ścieżkę, a zapis transakcyjny i logika biznesowa zachowały odrębne odpowiedzialności.

**Osobna usługa i jawne ścieżki danych**
Katalog marketplace’u stał się osobną usługą z własną architekturą obsługi. Rust odpowiadał za główną szybką ścieżkę, uzupełnianą przez rezerwową ścieżkę Python. Odpowiadałem za architekturę i implementację, oddzielając obciążenie katalogu od szerszej aplikacji commerce.

**Cache, wyszukiwanie i transakcje mają różne zadania**
Redis buforował dane do powtarzanych odczytów, Elasticsearch zapewniał model wyszukiwania i odczytu, a PostgreSQL zachowywał odpowiedzialność transakcyjną. Oddzielało to pobieranie danych katalogu od zapisu stanu biznesowego. Operacje wsadowe i optymalizacja ciężkich zapytań uzupełniały ten podział.

**Kontrola powtarzanego ruchu na wejściu**
Równoważenie obciążenia i ograniczanie częstotliwości były częścią projektu usługi. Klientów z nadmierną liczbą powtarzanych żądań można było spowolnić, zanim zdominowali ruch. Kontrolę żądań, cache i szybką warstwę obsługi projektowano razem, uwzględniając napływ zapytań oraz sposób odczytu danych.

**Narzędzia i technologie**
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


Fizyczny proces stojący za oprogramowaniem

Inżynieria produkcji i CAD/CAM

Mój fundament inżynierski to projektowanie części, operacji obróbki i procesów wdrażania wyrobów do produkcji.

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

**Wyzwanie**
Część musiała wpisywać się w powtarzalny proces produkcji, uwzględniający ograniczenia maszyn, materiałów i kolejności operacji.

**Moje podejście**
Pracowałem z modelami CAD/CAM, programami CNC, postprocesorami i dokumentacją technologiczną. Zakres obejmował rozkrój blach, toczenie i frezowanie, zużycie materiałów oraz przygotowanie produkcji seryjnej.

**Rezultat**
Ta praca ukształtowała moje podejście: zrozumieć rzeczywisty proces, określić ograniczenia, a dopiero potem projektować automatyzację.

**Narzędzia i technologie**
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


Przekładanie operacji firmy na model ewidencji

Analiza biznesowa i rozwój aplikacji

Tworzyłem i utrzymywałem rozwiązania 1C dla firm w Ukrainie, pracując bezpośrednio z klientami nad ewidencją, planowaniem produkcji, zużyciem materiałów i logistyką.

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

**Wyzwanie**
Dokumenty biznesowe musiały tworzyć poprawne operacje magazynowe i finansowe w powiązanych procesach firmy.

**Moje podejście**
Analizowałem działanie firm i przekładałem ich reguły na dokumenty, raporty, zapytania i integracje w 1C УТП/УНФ. Moduły obejmowały logistykę transportu i operacje produkcyjne, normy materiałowe, koszty oraz wewnętrzną wymianę danych.

**Rezultat**
To doświadczenie połączyło modele programowe z rzeczywistymi zapasami, pieniędzmi i skutkami operacji, tworząc podstawę późniejszych systemów finansowych i biznesowych.

**Zrozumieć firmę przed konfiguracją systemu**
Pracowałem bezpośrednio z klientami, poznając ich procesy technologiczne i administracyjne, również w projektach budowanych od podstaw. Najpierw ustalałem rzeczywisty przepływ materiałów, dokumentów, zapasów i pieniędzy, a następnie konfigurowałem ewidencję oraz integracje. Model działania klienta kształtował model oprogramowania.

**Produkcja, materiały i planowanie wydatków**
Praca obejmowała planowanie produkcji, normy i zużycie materiałów, operacje magazynowe, koszty, płace oraz plany wydatków. Doświadczenie produkcyjne pomagało mi powiązać liczby w 1C z operacjami, które je tworzą. Raporty i złożone zapytania udostępniały te informacje do planowania i kontroli.

**Moduły dla rzeczywistych operacji**
Tworzyłem moduły logistyki transportowej i narzędzia przyspieszające lub usprawniające operacje produkcyjne. Wymiana danych i integracje łączyły je z pozostałą ewidencją firmy. To doświadczenie ukształtowało model „dokument → operacja”, który później pojawił się w usługach finansowych i platformie biznesowej w Python.

**Narzędzia i technologie**
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


Płatności, dokumenty i integralność danych

Modelowanie finansowe i integracje w wielu projektach

W Onlihub i Liqsale tworzyłem subskrypcje, płatności jednorazowe i modele transakcji powiązane z zestawieniami, przeliczeniami oraz dokumentami biznesowymi.

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

**Wyzwanie**
Prawidłowy callback płatności był tylko częścią zadania utrzymania spójności sald, stanów transakcji i dokumentów biznesowych.

**Moje podejście**
Pracowałem ze Stripe i Wise, subskrypcjami, checkout, webhookami płatności i zestawieniami PDF. Projektowałem też modele ewidencji transakcji i badałem egzekwowanie niezmienników finansowych przez transakcje, ograniczenia i wyzwalacze PostgreSQL.

**Rezultat**
Ta praktyka łączy moje doświadczenie ERP z nowoczesnymi płatnościami: operacje finansowe są modelowane przez jawne stany, kategorie i przepływy.

**Płatności wewnątrz procesu handlowego**
Moja praca w Onlihub i Liqsale obejmowała subskrypcje, płatności jednorazowe, koszyki, checkout i synchronizację statusów. Integracje Stripe oraz Wise należały do procesu finansowego aplikacji, wiążąc zdarzenia płatnicze z zamówieniem lub subskrypcją klienta i właściwymi zapisami transakcji.

**Model transakcji stojący za zestawieniami**
Pracowałem nad typami i kategoriami transakcji, obliczeniami, przeliczeniami oraz zestawieniami, w tym PDF. Rekordy opisują związek operacji finansowych ze stanem aplikacji i dokumentami. Model pozwala powiązać liczby wyświetlane użytkownikowi z transakcjami i operacjami, które je utworzyły.

**Badanie niezmienników w PostgreSQL**
Badałem przeniesienie części reguł finansowych do transakcji, ograniczeń i wyzwalaczy PostgreSQL, w tym ograniczeń salda oraz operacji wywołanych zmianą statusu dokumentu. Celem było jawne zapisanie ważnych niezmienników w warstwie danych. Ochrona salda przez wyzwalacze pozostawała obszarem eksperymentów w tej pracy.

**Narzędzia i technologie**
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


Aktywność handlowa widoczna na mapie

Integracja zamówień i procesy geoprzestrzenne

Pracowałem nad połączeniem aktywności zamówień, informacji produktowych i kontekstu geograficznego na mapie.

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

**Wyzwanie**
Strumień zamówień potrzebował wizualnego kontekstu łączącego miejsce zdarzenia z kupowanymi produktami.

**Moje podejście**
Pracowałem z agregacją zamówień, geodanymi, trackingiem i kartami produktów powiązanymi z katalogiem commerce. Projekt uwzględniał również trasy i szacunki dostawy; publiczny Product Map stanowi odniesienie do produktu.

**Rezultat**
Praca nadała zdarzeniom handlowym wymiar geograficzny, łącząc aktywność na mapie z katalogiem produktów.

**Narzędzia i technologie**
Order aggregation, Geodata, Product maps, Tracking, Route modelling, Route calculation, Delivery estimates, Estimated delivery time, Catalog integration

- [Zipurch · odkrywanie produktów](https://zipurch.com/) — Strona produktu opartego na Onlihub: trendy zakupowe, dane geograficzne i analiza rynku.

Produkt · Wczesny dostęp · Linki sprawdzone: 2026-09-27

Strona zaprasza do wczesnego dostępu; część funkcji ma oznaczenie „Coming Soon”.

### Meeting-to-Actions


Od ustnych ustaleń do uporządkowanej pracy

Integracja rozpoznawania mowy i procesów agentowych

Pracowałem nad procesem przekształcającym nagranie spotkania w ustalenia, działania i zadania w Teamwork przez MCP.

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

**Wyzwanie**
Ustalenia z rozmowy należało przekształcić w uporządkowaną pracę z przypisanymi osobami, zamiast pozostawiać je w nagraniu.

**Moje podejście**
Rozpoznawanie mowy tworzyło transkrypcję do analizy ustaleń, zadań i odpowiedzialnych osób przez AI. MCP łączyło uporządkowany wynik z Teamwork, integrując przetwarzanie audio z istniejącym systemem pracy.

**Rezultat**
Proces połączył treść spotkań z zadaniami w systemie pracy zespołu.

**Narzędzia i technologie**
Speech recognition, Transcription, AI analysis, Action extraction, MCP, Teamwork, Workflow integration

### Local AI / Lightweight ML


Dobór modelu do rzeczywistego zadania

Badania stosowane i prototypy procesów

Badam lokalne modele i lekkie mechanizmy inferencji do obsługi mowy, dokumentów, wyszukiwania i praktycznej automatyzacji.

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

**Wyzwanie**
Wybór modelu wymagał równowagi między jakością, opóźnieniem, ograniczeniami sprzętu i kosztem działania.

**Moje podejście**
Pracuję z lokalnymi LLM, inferencją nastawioną na CPU, ONNX i GGUF oraz narzędziami mowy Whisper, Sherpa-ONNX i Silero. Eksperymenty obejmują też OCR, embeddings, wyszukiwanie wektorowe, przetwarzanie wielojęzyczne i TTS.

**Rezultat**
Zbiór eksperymentów pomaga mi dobierać modele i łączyć je z użytecznymi procesami.

**Narzędzia i technologie**
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


Gra Telegram: walki po stronie serwera i systemy gry

Prowadzenie produktu, backend i systemy gry

Współtworzyłem koncepcję, rozwijałem i uruchamiałem grę Telegram. Backend obsługuje turowe walki PvP/PvE, zdolności czołgów, wynajem, crafting i zapis wyników; aktywa gry są powiązane z portfelami i stanem NFT.

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

**Wyzwanie**
Progresja w grze, cyfrowa własność, handel i backend musiały tworzyć jeden spójny produkt.

**Moje podejście**
Moja praca obejmowała logikę gry, backend, decyzje produktowe i koordynację zadań zespołu. Serwer zarządza turami, punktami akcji, efektami i obrażeniami, wysyła aktualizacje walki przez WebSocket i zapisuje wyniki. Zajmowałem się też uruchomieniem, promocją i częścią produktu związaną z TON/NFT.

**Rezultat**
Moje historyczne oszacowanie to 130 tys. użytkowników; okres i sposób liczenia nie zostały uzgodnione z liczbą na stronie produktu. Niezależny projekt połączył systemy gry, backend i uruchomienie.

**Przebieg walki**
Walka po stronie serwera koordynuje tury PvP i PvE. Stan czołgu obejmuje zdrowie, pancerz, prędkość, zdolności, efekty, czas odnowienia i punkty akcji. Pętla wyznacza kolejną turę, stosuje akcje i obrażenia, a następnie wysyła klientom dostępne działania i zmiany stanu przez WebSocket.

**Własność, wynajem i crafting**
Dostęp do czołgu rozróżnia właściciela i najemcę oraz uwzględnia czas odnowienia i limity wynajmu. Crafting sprawdza czołgi wejściowe i ich własność, a następnie zapisuje dokument craftingu oraz utworzony czołg w grze. Powiązania z portfelami i stan NFT są częścią modelu aktywów.

**Bieżący stan i zapisane wyniki**
Serwer utrzymuje bieżący stan walki, a klienci otrzymują aktualizacje. Rekordy w bazie wiążą walkę z jej czołgami i zapisują dane wynikowe, w tym obrażenia i punkty. Uwierzytelnianie Telegram WebApp łączy sesję gracza z API gry.

**Moja odpowiedzialność**
Współtworzyłem kierunek produktu, backend i logikę gry, koordynowałem zadania zespołu oraz pracowałem nad uruchomieniem.

- Walki PvP/PvE po stronie serwera zarządzają turami, efektami i obrażeniami, wysyłają bieżące aktualizacje oraz zapisują wyniki.

- Sesje Telegram, własność w portfelach, wynajem i crafting łączą dostęp gracza z modelem aktywów gry.

**Publiczne informacje o produkcie**

To liczba użytkowników aplikacji z publicznej strony. Osobna historyczna liczba 130 tys. pochodzi z mojego opisu projektu i nie jest tą samą zweryfikowaną metryką.

- 80,000: użytkowników aplikacji według publicznej strony

[TON Tanks · publiczna strona projektu](https://tontanks.io/)

Źródła sprawdzono: 2026-09-27

**Narzędzia i technologie**
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 · strona gry](https://tontanks.io/) — Oficjalny opis gry i jej mechaniki oraz linki do gry na Telegramie i kolekcji NFT.

Produkt · Publiczna strona · Linki sprawdzone: 2026-09-27

- [TON Tanks · kolekcja na GetGems](https://getgems.io/tontanks) — Kolekcja NFT wskazana bezpośrednio na stronie gry i jej oficjalnym kanale Telegram.

Kolekcja NFT · Widok z JavaScript · Linki sprawdzone: 2026-09-27

GetGems wymaga JavaScript i może ograniczać automatyczne zapytania. Link do kolekcji potwierdzono w źródłach projektu; liczby NFT i danych handlowych nie zweryfikowano.

- [TON Tanks · kanał Telegram](https://t.me/ton_tanks_nft) — Oficjalny kanał wskazany na tontanks.io: aktualizacje gry i link do kolekcji.

Oficjalny kanał · Publiczna strona · Linki sprawdzone: 2026-09-27

### Modular Vehicles / Unity


Fizyka, maszyny modułowe i światy proceduralne

Samodzielny rozwój systemów gry

Rozwijam i badam modułowe pojazdy, uszkodzenia, fizykę gąsienic i środowiska proceduralne w Unity.

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

**Wyzwanie**
Składane pojazdy wymagają niezależnych modułów, które razem działają jako spójny system fizyczny i rozgrywkowy.

**Moje podejście**
Buduję modułową architekturę pojazdów z osobnymi częściami, logiką uszkodzeń, ruchem gąsienicowym i strzelaniem. Eksperymenty obejmują multiplayer, tryby PvP/PvE, przejmowanie stref, proceduralne miasta, roślinność i optymalizację.

**Rezultat**
Trwający niezależny projekt służący sprawdzaniu, jak współdziałają symulacja fizyczna, projektowanie modułowe i rozgrywka.

**Narzędzia i technologie**
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


Od modeli hard-surface do zasobów gotowych do gry

Samodzielne modelowanie i przygotowanie zasobów

Używam Blender do tworzenia i przygotowania modeli hard-surface, materiałów i tekstur do środowisk gier.

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

**Wyzwanie**
Zasób 3D musi działać wizualnie i jednocześnie mieścić się w ograniczeniach aplikacji czasu rzeczywistego.

**Moje podejście**
Pracuję nad modelowaniem, geometrią hard-surface, materiałami i teksturami. Przygotowanie obejmuje optymalizację do projektów gier, łącząc pracę wizualną z technicznymi wymaganiami środowiska wykonawczego.

**Rezultat**
Zbiór niezależnych prac 3D uzupełniający moje doświadczenie z systemami gier i inżynierią fizyczną.

**Narzędzia i technologie**
Blender, 3D modelling, Hard-surface modelling, Materials, Textures, Game-ready assets, Asset optimization

### Engine Sim Unity Audio


Symulacja fizyczna jako źródło dźwięku w grze

Samodzielny rozwój narzędzi audio

Pracowałem nad automatycznym generowaniem banków dźwięków silnika do Unity z fizycznego symulatora silnika.

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

**Wyzwanie**
Wynik symulacji trzeba było przekształcić w zestaw dźwięków silnika możliwy do użycia w grze.

**Moje podejście**
Połączyłem fizyczną symulację silnika z automatycznym generowaniem banków audio. Praca koncentruje się na narzędziach między generowaniem dźwięku a przygotowaniem zasobów dla Unity.

**Rezultat**
Projekt narzędziowy łączący symulację, automatyzację i tworzenie zasobów gry.

**Narzędzia i technologie**
Unity, Engine audio banks, Physical engine simulation, Audio generation, Asset automation

- [Engine Sim Unity Audio · GitHub](https://github.com/Vangardo/engine-sim-unity-audio) — Kod i dokumentacja mojego generatora banków audio offline, opartego na Engine Simulator autorstwa AngeTheGreat.

Kod źródłowy · Publiczna strona · Linki sprawdzone: 2026-09-27

### Crypto Trading Terminal


Dane rynkowe, strategie i wykonanie w jednym narzędziu

Samodzielny rozwój aplikacji

Zbudowałem terminal tradingowy łączący dane rynkowe, wykresy, własne strategie, backtesting i wykonywanie operacji na giełdzie.

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

**Wyzwanie**
Badanie strategii wymagało spójnej ścieżki od danych historycznych i wskaźników do wykonania oraz zapisu wyników.

**Moje podejście**
Połączyłem wykresy i wskaźniki SMA, EMA, MACD, TMA oraz RSI ze strategiami użytkownika i backtestingiem. Wykonywanie operacji na giełdzie, prowizje, P&L i zapis wyników tworzyły operacyjną część terminala.

**Rezultat**
Aplikacja połączyła analizę strategii i wykonanie na giełdzie w jednym procesie, obejmując prowizje, P&L i zapis wyników.

**Narzędzia i technologie**
Market data, Charting, SMA, EMA, MACD, TMA, RSI, Backtesting, User-defined trading strategies, Live exchange execution, Commissions, P&L, Results persistence

## Kontakt


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

[Pobierz CV](https://bartenev.site/cv/igor-bartenev-pl.pdf)

[Produkty i źródła](https://bartenev.site/pl/resources/)