Cases

Selected projects

Two scales of the same work: enterprise delivery programs and a compact applied lab.

Enterprise programs

Complex rollouts

Projects where outcomes depended not only on architecture, but on the ability to align an internal team, the client, and partners into a unified delivery model. Organization names, budgets, and sensitive details are intentionally omitted from this public version.

Enterprise program · 1 / 2 Russia · public version

Federal-scale data platform

Distributed sources · prime contractor · delivery ecosystem

As part of a major rollout program, a platform was built and put into production to collect data from geographically distributed sources, process it, and deliver it to end applications, analytics systems, and users.

Context and delivery model

Complexity came from more than architecture. The client had a distributed geographic and organizational structure, and a broad ecosystem of implementers took part in delivery.

We acted as prime contractor and owned the program end to end. A substantial share of design, development, and rollout was delivered by our own team. Subcontractors were engaged for selected workstreams, including major Russian systems integrators. Our role therefore combined hands-on solution building, overall delivery management, and coordination across all parties.

The project was not structured as an external handoff with a formal transfer at the end. Client specialists participated in design, rollout, and operational readiness. In parallel, internal capabilities, processes, and ownership zones were established for ongoing platform support.

How my role evolved

I joined as project manager at the transition from agreement to execution: the client contract was being finalized while subcontractor commercial and working relationships were being set up. The initial mandate was to organize launch and management of one project stream.

As the program grew, scope expanded quickly. I moved from managing a single project to coordinating several interdependent projects, and then took responsibility for overseeing the program as a whole.

The role included team and capability building, organizing our own design and rollout work, subcontractor management, resolving cross-project dependencies, and participating in key architectural and management decisions.

Client engagement changed in parallel: from day-to-day project communication to regular work with leaders accountable for the program and its outcomes. Technical and delivery questions had to be translated into risks, priorities, and decisions that mattered at the organizational level.

Programs at this scale inevitably hit difficult points. Management alignment and timely removal of cross-organizational blockers helped preserve shared accountability and move the program toward production launch and acceptance.

Outcome

The platform went live and became a unified environment for working with data from distributed sources.

Two organizational capabilities emerged in parallel: on our side, the ability to deliver programs of this scale as prime contractor; on the client side, the ability to participate in operating, supporting, and further developing the platform.

Enterprise program · 2 / 2 Central Asia · public version

Data Lake and Data Governance for a major bank

Digital transformation · joint team · capability building

A major bank needed to build from scratch a platform for collecting, storing, managing, and analyzing data — not as a standalone repository, but as the foundation for further digital transformation.

Context and delivery model

For the bank, this was one of the largest data investments at the time. Alongside the platform, the bank needed data management processes and an internal team capable of evolving the solution after rollout.

We acted as the single technology implementer, but the program was not structured as an external turnkey delivery with a handoff of keys. Implementation ran jointly with bank specialists: they participated in design and rollout, learned the technologies, and gradually took ownership of parts of the platform.

The program covered Data Lake infrastructure, Data Governance processes, and initial applied analytics scenarios. For retail, customer segmentation models and recommendations for personalized offers were developed.

My role

I led the program across the full cycle: from shaping the initiative and negotiations through solution design and rollout launch. I coordinated the technology and organizational tracks, engagement with bank leadership and teams, and internal capability development.

Particular attention went to the future operating model: roles, processes, hiring, training, and the bank’s ability to continue platform development independently.

Outcome

The bank gained a platform foundation for analytics and data-driven scenarios: infrastructure, data management practices, and initial models. At the same time, an internal team formed that could participate in evolving and operating the solution.

This was a joint transformation program: the external implementer provided architecture and delivery, while the bank team steadily built its own capability and took the platform into day-to-day use.

Applied lab

From hypothesis to a working solution

Compact projects where the full path — problem framing, architecture, MVP, validation, and adaptation — can be shown end to end.

Full case · 1 / 4 qdrant_experiments

Corporate knowledge base and AI assistant

knowledge base + assistant (support / pre-sales)

In one line

Built a corporate knowledge base from help content, FAQ, articles, internal materials, and the support knowledge base — and on top of it, an applied AI assistant for technical support and pre-sales, with room to extend to other functions.

Cycle

We started with a hypothesis: use OpenWebUI as a ready-made RAG builder. It did not fit — too little flexibility and hard-coded constraints for different roles and data sensitivity. On top of Qdrant we built our own source integration layer for the corporate knowledge base and a minimal chat on top. The chat quickly hit a ceiling; we extended and modernized it (multi-collection and source trust, YouTrack, OCR/attachments, communication profiles for support / pre-sales / external users). We eventually arrived at a Workspace runtime: each request is classified and routed first, then the right capabilities are invoked — knowledge base search, attachment parsing, YouTrack scenarios, and so on — with execution visible as events, artifacts, and tool calls; a managed orchestrator, not “one long prompt.” The next planned step is multi-step agents. Team: myself, an L2 support engineer as domain expert, and a maintenance-system developer; code was written by an AI agent under my direction.

Outcome

A unified corporate knowledge base plus an AI assistant with role profiles, not “one chat for every case.” We aimed to help L1, but the chat immediately handled conversations at L2 level — including confident parsing of long, heavy attachments (logs, dumps) with insights for engineers. Potential to extend to other functions. No hard public KPIs — the emphasis is on a managed knowledge pipeline and fitness for different operating environments.

Stack

Python/FastAPI, Celery, React, PostgreSQL, Redis, Qdrant, Docker; LLM: llama.cpp, Ollama, vLLM. Integrations: YouTrack, RoboHelp.

Demo

Diagrams + showroom UI (Acme stubs, :3100). No live YouTrack or corporate collections.

Corporate assistant — control dashboard — UI (showroom) · dashboard · collection showroom_acme_faq

Corporate assistant — Qdrant collections — UI · collections / KB layer

Corporate assistant — collection documents — UI · Acme FAQ documents · ingestion complete

Corporate assistant — chat with answer — UI · chat · stub LLM + sources

Corporate assistant — Workspace run — UI · Workspace · ACME-101 · events/answer with citation

Corporate assistant — YouTrack stubs — UI · U-Track stubs ACME-101… · no live YouTrack

Diagram: solution evolution (L1)

flowchart TB
  subgraph phase1 [Phase 1: Hypothesis]
    OpenWebUI[OpenWebUI RAG]
  end
  subgraph phase2 [Phase 2: Own KB layer]
    Sources[FAQ, Help, Support sources]
    Ingest[Ingest, index, collections]
    Qdrant[(Qdrant)]
    SimpleChat[Simple chat]
    Sources --> Ingest --> Qdrant --> SimpleChat
  end
  subgraph phase3 [Phase 3: Expand]
    Multi[Multi-collection and trust]
    YT[YouTrack]
    Attach[OCR and attachments]
    Profiles[Role profiles]
  end
  subgraph phase4 [Phase 4: Workspace]
    Router[Request router]
    Caps[Capabilities]
    Events[Events, artifacts, tool calls]
    Router --> Caps --> Events
  end
  OpenWebUI -.->|rejected| Ingest
  SimpleChat --> Multi
  Multi --> Router
  YT --> Caps
  Attach --> Caps
  Profiles --> Router
  Next[Next: multi-step agents]
  Events -.-> Next

Diagram: Workspace runtime (L1)

flowchart LR
  User[User] --> UI[Workspace UI]
  UI --> API[Workspace API]
  API --> Runtime[Workspace runtime]
  Runtime --> Router[Request router]
  Router --> Direct[Direct answer]
  Router --> Retrieval[Retrieval]
  Router --> Attach[Attachments]
  Router --> Domain[Domain capabilities]
  Retrieval --> Evidence[Evidence pack]
  Attach --> Evidence
  Domain --> Evidence
  Direct --> Composer[Answer composer]
  Evidence --> Composer
  Composer --> Events[Run events]
  Composer --> Artifacts[Run artifacts]

Full case · 2 / 4 Meridian Lab

Meridian Lab — ML/DS research

market data · hypotheses · analytics · ML + GPU

In one line

ML/DS research environment for market data: integrations with broker and exchange APIs → history and intraday cache → hypotheses on price behavior → analytics and charts; backend/frontend, prod/dev, remote ML service with GPU.

Cycle

We started by developing and validating integrations with Finam and Tinkoff APIs. Designed architecture for exchange connectivity, including MOEX API. Built collection and caching of historical series and intraday data. Worked through a set of hypotheses with insights on price behavior across instruments. Defined the main environments: backend, frontend, production and development, remote ML service with GPU acceleration. Substantial analytics work — dependencies, visualizations, charts — as a way to test hypotheses.

Outcome

A working research and engineering environment: from APIs and data through hypotheses to an ML pipeline with separated environments and GPU. Publicly — technology capabilities and the research cycle; trading rules, thresholds, and the “recipe” stay off the showcase.

Stack

Backend (Go/gRPC/API), frontend, PostgreSQL; Finam / Tinkoff / MOEX; remote ML + GPU; prod and dev.

Demo

Diagram + local UI demo. New captures are draft: click to enlarge; final redaction to be confirmed separately.

Meridian Lab — UI shell, instrument catalog — UI · catalog / shell

Meridian Lab — hypotheses and archive — ML Labs · hypotheses · active + archive · completion status

Meridian Lab — source data summary — Source data · layer summary Raw / ETL / meta

Meridian Lab — ETL processing layer — Source data · ETL · processing tier

Meridian Lab — operations dashboard — Operations dashboard · production variant · dates/prices masked

Meridian Lab — ML Labs summary — ML Labs · services / pipeline summary · Helios

Meridian Lab — training lab, top section — Archive · ML Labs → training lab · top (runs / results)

Meridian Lab — learning curve and heatmap — Lab · learning curve + calendar/heatmap (+ price charts)

Meridian Lab — training lab, full screen — Lab · full longread (click — scroll in lightbox)

Architecture (L1)

flowchart TB
  subgraph apis [Market APIs]
    Finam[Finam API]
    Tinkoff[Tinkoff API]
    MOEX[MOEX API]
  end
  subgraph data [Data layer]
    Ingest[Ingest and integrations]
    Cache[History and intraday cache]
  end
  subgraph research [Research layer]
    Hyp[Hypotheses]
    Analytics[Analytics, charts, dependencies]
  end
  subgraph app [Application environments]
    BE[Backend]
    FE[Frontend]
    Dev[Development]
    Prod[Production]
  end
  subgraph ml [ML environment]
    MLS[Remote ML service]
    GPU[GPU acceleration]
    MLS --- GPU
  end
  Finam --> Ingest
  Tinkoff --> Ingest
  MOEX --> Ingest
  Ingest --> Cache
  Cache --> Hyp
  Cache --> Analytics
  Hyp --> MLS
  Analytics --> FE
  BE --> Ingest
  BE --> Cache
  BE --> MLS
  FE --> BE
  Dev --- Prod
  BE --- Dev
  BE --- Prod

Full case · 3 / 4 tg-magician

Telegram → knowledge base → RAG

Idea + technology · group/channel KB → RAG

In one line

Local pipeline: long group/channel history in Telegram (via personal account) → topics and facts in KB → RAG grounded in sources.

Cycle

Problem: unpack a channel or group with a long history — many threads, answers spread across years, impractical to scan manually. Pull history through a personal Telegram account, extract topics and focus areas, assemble facts in KB, and expose via RAG. Designed ingest → flows/KB → Qdrant → ask. Delivered MVP (Telethon/export, Postgres, retrieve/ask, CLI) and validated on live dialogues. Adapted: hybrid thread stitching, KB pipeline (summary/facts/qa with message links), migration to Postgres and background workers, SwiftUI orchestrator instead of CLI-only.

Outcome

End-to-end pipeline: from group history to topics, focus areas, and facts in the knowledge base, plus source-backed search, managed UI and continuous sync. No metrics captured — value is in the idea and the technology brought to working shape.

Stack

Python (Typer, FastAPI, Telethon), PostgreSQL, Qdrant, vLLM, embedding service, Docker Compose, SwiftUI.

Demo

Diagram + SwiftUI orchestrator (public FINAM API channel) + showroom ask. No session files / PII.

tg-magician — home screen, flows — SwiftUI · home · flow catalog and folders/dialogs

tg-magician — flow settings — SwiftUI · flow · channel @finam_trade_api · TRADEAPI collection

tg-magician — pipeline — SwiftUI · pipeline · KB / ingest / index

tg-magician — KB threads — SwiftUI · knowledge base · threads

tg-magician — KB chunks — SwiftUI · knowledge base · chunks with summary

tg-magician — KB graph overview — KB Graph · overview · ~2.5k nodes / facts·qa·threads

tg-magician — KB graph focus — KB Graph · thread → facts (kb_source)

tg-magician — showroom shell — Web showroom · ask orchestration without live Telethon

tg-magician — ask with sources — Web showroom · ask + retrieved sources (stub LLM)

Pipeline (L1)

flowchart LR
  TG[Telegram history]
  Ingest[Ingest and export]
  PG[(PostgreSQL)]
  KB[KB: topics, facts, QA]
  Qdrant[(Qdrant)]
  Emb[Embedding service]
  Ask[Ask RAG]
  LLM[vLLM]
  UI[SwiftUI orchestrator]
  TG --> Ingest --> PG --> KB
  KB --> Qdrant
  Emb --> Qdrant
  Qdrant --> Ask
  LLM --> Ask
  UI --> Ingest
  UI --> Ask

Full case · 4 / 4 safe_dialog

Safe Dialog

Cloud LLM without leaking sensitive data

In one line

A corporate user sends a cloud LLM a prompt with sensitive data — a local processing layer masks it, the cloud responds, and the answer is demasked.

Cycle

Problem: use ChatGPT / DeepSeek / any cloud LLM without exposing commercial, legal, or other sensitive data — for example, a counterparty email that needs a draft reply. On-prem LLM is weaker and cheaper: enough to find and hide sensitive fragments (replace with codes/terms). The masked prompt goes to the cloud; the reply is demasked locally. Delivered MVP of a three-step mask → cloud LLM → demask cycle: entity catalog, API, step-by-step UI, prompt configuration.

Outcome

Working end-to-end pipeline: sensitive data does not leave for the cloud in the clear, while generation quality comes from the external LLM.

Stack

FastAPI, React/TS/Vite/Tailwind, Ollama (detection), OpenRouter (generation), Docker.

Demo

Diagram below. Live UI: showroom texts → masking, settings, catalog (original values redacted).

Safe Dialog — text input step — UI (local demo) · step 1 — showroom source texts

Safe Dialog — masking step — UI (local demo) · step 2 — after “Mask” · masked view

Safe Dialog — settings — UI (local demo) · settings · OpenRouter, prompts, modes

Safe Dialog — entity catalog — UI (local demo) · catalog · original fragments replaced with synthetic data

Pipeline: mask → LLM → demask (L1)

flowchart LR
  User[User sensitive text]
  Local[Local processing layer]
  Detect[Detect and mask]
  Catalog[Entity catalog]
  Cloud[Cloud LLM]
  Demask[Demask]
  Out[Safe reply]
  User --> Local --> Detect
  Catalog --> Detect
  Detect -->|masked prompt| Cloud
  Cloud -->|masked reply| Demask
  Demask --> Out

Short cases

Other projects

Short · CV okno-vozm

CV balancing

Assistant for structuring and aligning CV positioning: different angles on yourself as a candidate, different platforms and profiles — which aspects to emphasize in each. Explored integrations with LinkedIn and HH — and hit platform constraints. HH discontinued a job-seeker API suited to such tasks by late 2025: full resume/response sync is now heavily limited; on LinkedIn, without Talent API, you effectively get basic profile only. Still assembled a working solution: several local positioning variants and CV types, import of published resumes as files (PDF/HTML), local ↔ platform reconciliation, parsing of “your resume caught attention” emails, application bundles for vacancies, and job search via the public HH API.

Python/FastAPI, React, Electron, SQLite, Docker

CV balancing — pool and reconciliation columns — UI (local demo) · reconciliation · demo “Ivan Ivanov”

CV balancing — full comparison screen — UI (local demo) · full screen · Senior Go vs backend team lead

Short · MVP slides_wanted

Slides Wanted

Built an MVP presentation builder as a base platform for extension: at the time, cloud LLMs did not yet deliver finished decks at scale — they suggested slide structure that still had to be copy-pasted into PowerPoint, and specialized export services were narrowly limited. In one week, delivered form → LLM → preview → PPTX export. Further development paused pending funding; backlog items included corporate styling, knowledge base connection (talking points → slide content from KB), and pipeline expansion.

React + Express/TS, OpenRouter/OpenAI, pptxgenjs

Slides Wanted — presentation creation — UI (local demo) · presentation creation form

Contact Story Profile