Before we build anything, let’s figure out what would actually be useful.
You bring the problem. I listen, ask questions, and help work out whether AI belongs there at all. If it does, we turn that understanding into a working product together.
Live Navigator is a free Russian-language Telegram bot for searching the public YouTube archive of the Apeiron school of thought. Ask a question in your own words, and it finds the closest questions discussed in the archive and opens the source video at the relevant moment.
The problem is simple: people remember the meaning, not the exact wording, and the thought they need may be buried inside a long live session.
My independent initiativeEarly public betaRussian only
Ask a free-form question → review the closest questions and related topics → open the original video at the matching timestamp.
Current state
Early public beta, presented to the community and tested by a small group. The index covers 89 public videos, 57 topics, and over 27,000 searchable question formulations.
What I owned
This was my independent initiative. I defined the problem, product flow, search architecture, safety boundary, cost controls, testing, and launch. Coding agents assisted implementation. I checked the result through tests and the working interface.
Product decisions
• Search, not advice. It searches. Not playing psy games with you. Results stay tied to public videos and timestamps.
• Natural wording. Original viewer questions are expanded with alternative formulations. Users do not need the exact phrase from a live stream.
• Recovery flow. Clarification and related-question buttons handle weak, multi-topic, or empty results.
• Controlled operation. Admin panel, a two-stage gatekeeper, cached answers, and per-user and global limits control cost and abuse.
Interface
Russian-language Telegram flow: ask, review the closest questions, open the source video.
Suggested topics and a free-form question.Ranked questions with source links.Related questions for continued search.
Technical architecture
The bot runs as a TypeScript/Node.js hybrid-search system on Railway. Mastra coordinates the workflow. Gemini 2.5 Flash on Vertex AI handles classification, planning, scoring, and synthesis.
Knowledge layer
Public transcripts become original and synthetic question indexes: over 27,000 searchable formulations across 57 topic-based JSON files. Search data stays in inspectable JSON files. SQLite stores Mastra state.
Search path
Regex filter → LLM gatekeeper → FAQ fast path or file-first grep → parallel Map scoring → Reduce → source-linked results. Original and synthetic hits are deduplicated by video and timestamp.
Content updates
A playlist-delta pipeline processes only new videos, classifies extracted questions, and builds synthetic variants. Base indexes update immediately. The heavier FAQ-cache rebuild runs only when needed.
Operations
Private-chat enforcement, per-user and global limits, an admin dashboard, and usage, cost, and latency tracking. Cached follow-ups can bypass the full LLM pipeline.
People remember the meaning, not the exact words. The system had to match that loose wording to the right video moment, show the public source, and stop there.
Experts Panel lets you choose several AI practitioners, ask one question in English or Russian, and get separate answers grounded in each practitioner's published material. It then shows agreement and disagreement, with links to original posts, comments, and videos.
I built it because useful practitioner knowledge kept getting lost across Telegram channels, Reddit threads, and videos. Search was manual. A general-purpose LLM could produce a plausible answer. It could not show whose position it was or where it came from.
My everyday toolPublic and workingEnglish and Russian
Select practitioners → ask once → receive separate source-backed answers → compare consensus and disagreement → open the original sources.
Practical result
I use it almost every day. That already adds up to hundreds of small decisions. Refat’s explanation of the file-first approach directly influenced Live Navigator, where I stored questions and answers as a file-based database.
What I owned
This was my independent product. I defined the corpora, retrieval and comparison flow, source checks, Codex integration, expert admission, project-review mode, testing, and deployment. Coding agents assisted implementation. I checked the result with automated tests, by opening cited sources, and in the working interface.
Product decisions
• Evidence stays attached. Posts, comments, and links remain visible. Cited source IDs are validated before synthesis.
• Experts stay separate. Each corpus is processed on its own before cross-expert comparison, so disagreement does not disappear into one average answer.
• Panex connects other Codex projects to the panel. A project can request a source-backed digest and expand selected sources. That project still makes the decision.
• The Knowledge Matrix filters new experts. It maps corpus coverage and overlap before I add someone to the panel. The final decision stays human.
• Expert Lens stays bounded. It applies one corpus to a project review without simulating the expert or inventing a verdict.
One query across three expert corpora.Expert answer beside the source post.Consensus and recommendations after individual analysis.Unique signals kept outside consensus.Source comments retained as context.
Technical architecture
The system uses a Python/FastAPI backend and a React/TypeScript frontend. Telegram corpora, search indexes, embeddings, comments, and source links are stored in SQLite. Gemini models run through Vertex AI. Flash Lite handles per-source analysis. Stronger models handle synthesis and comparison.
Retrieval
The hybrid retrieval mode used by Panex expands the query, then runs Gemini embeddings and FTS5/BM25 search in parallel. Reciprocal Rank Fusion merges both rankings before LLM relevance scoring. Every query stays inside its selected expert corpus.
Analysis pipeline
Selected experts run in parallel, but each corpus stays isolated through retrieval, reranking, source resolution, synthesis, language validation, and comment processing. The system checks cited post IDs against the supplied context before comparison. Reddit and Video Hub run separately.
Agent and roster layer
Panex exposes source bundles, expert digests, and source expansion through explicit API and CLI calls. The Knowledge Matrix builds semantic passports to compare expert coverage before admission. Expert Lens uses the same evidence layer for source-grounded project reviews.
Delivery
SSE streams progress. Large results are saved server-side and recovered by request ID instead of being pushed as one browser payload. Optional-stage failures do not remove completed expert answers.
Keeping expert corpora separate lets me compare positions without losing who said what. I can open the source before applying an answer to a real project.
NEXX is a B2B procurement platform that brings the full buyer-supplier flow into one place: discover suppliers, establish a relationship, order, and follow up. Each company works in its own space and can operate as a buyer, supplier, or both.
The practical problem was fragmentation across tools and handoffs. NEXX keeps the process inside one company-scoped flow.
Client projectFunctional early demoMulti-tenant by designEnglish · Latvian · RussianInterface kept private
How it works
Choose the active company → find suppliers and catalog items → establish a buyer-supplier relationship → build the cart → validate checkout → create supplier-specific orders.
Current state
Was it finished? No. The client saw a functional early demo built against the real API contract, covering catalog, relationships, cart, checkout, and orders. The UI/UX remained intermediate, and client screens stay private.
What I owned
I used Codex to build part of the backend at the start. When a dedicated backend developer took over, I moved fully to the frontend. I built the Next.js interface against the real API contract and used Codex to implement the intermediate UI/UX direction developed in Claude Design. That was the version shown to the client.
Development decisions
• Multi-tenant and multilingual from the start. Company context, buyer/supplier roles, and all three languages were built into the architecture.
• Files, not chat. I worked in Codex. The backend developer worked in Claude Code. Both agents worked from OpenAPI, handoff files, a generated typed client, and contract checks.
• Behavior before code. Daily work followed BDD/TDD: define behavior, record RED, implement the smallest change, run GREEN checks, and review the diff.
• The ERP boundary stayed explicit. NEXX owned the procurement workflow. Official documents, numbering, PDFs, VAT/accounting, and warehouse records remained outside the platform.
Frontend to platform contract
FrontendNext.js · React · TypeScript
→
API contractOpenAPI · typed client
→
PlatformDjango REST Framework · PostgreSQL
Cross-agent handoff
Andrey + CodexFrontend · behavior · verification
↔
Shared artifactsContract · handoff · evidence
↔
Backend developer + Claude CodeBackend · API implementation
BehaviorREDImplementationGREENReview
Technical architecture
The frontend used Next.js, React, and TypeScript. The platform used Python, Django REST Framework, and PostgreSQL. The browser reached it only through a same-origin Next.js proxy and the versioned /api/internal/v1 contract.
Runtime boundary
Browser → Next.js proxy → NEXX platform. The ERP/1C boundary was defined, but the demo used a mock instead of a final integration. ERP-owned documents, accounting, and warehouse records stayed outside the platform.
Tenant and procurement model
Bearer JWT, X-NEXX-Company-ID, and backend membership checks enforced the active company boundary. Buyer/supplier roles and active relationships gated procurement. Checkout produced supplier-specific order snapshots. English, Latvian, and Russian were built in from the start.
Contract handoff
OpenAPI generated the typed schema. frontend-handoff.json pinned the backend commit, schema hash, changes, required actions, and known limitations. Contract checks caught drift. Codex and Claude Code worked against those files instead of inferring API behavior.
Verification harness
Each task moved from written behavior to RED, the smallest implementation, GREEN evidence, and diff review. The Architecture Impact Gate ran before non-trivial changes. After GREEN, a separate pass simplified the diff. Checks covered API contracts, Vitest, deployed Playwright and accessibility smoke, lint, typecheck, and build.
NEXX was where I learned to coordinate frontend and backend work through different coding agents. OpenAPI, handoff files, and the BDD/TDD loop kept both sides aligned through the demo.
Private · Case study
Oyster Logistics.
Connects customer orders to supplier invoices. Flags what needs attention.
Oyster Logistics is a Russian-language MVP for an oyster distributor. It connects customer orders with supplier requests and incoming invoices, then shows where quantities, units, or records do not match.
Before the MVP, the process was spread across messages, emails, documents, spreadsheets, and manual checks. I brought it into one workflow built around Google Sheets, Gmail, and Telegram.
Client MVPTested with real historical business dataNot launched into daily operationsRussian only
How it works
Order form → shared working sheet → French supplier drafts for review → invoice extraction → four-field matching → visible exceptions → follow-up in Google Sheets and Telegram.
Current state
I tested the MVP in a separate environment with real historical orders, supplier emails, and invoices, then demonstrated it to the client. Development stopped before a live pilot because the next stage did not fit the available budget. The client and I tested the order form with prepared data. The distributor's customers did not use it.
What I owned
I handled the project end to end: process discovery, workflow design, product decisions, architecture, implementation, testing with historical data, and the client demo. Coding agents assisted me. There were no other developers on the project.
Product decisions
• One row keeps both sides. The original order and supplier invoice stay side by side. Differences remain visible.
• AI extracts. Code decides. Gemini reads email bodies, PDFs, and images. Explicit rules control matching, status, and exceptions.
• Supplier messages stay under human control. The system prepares separate French Gmail drafts grouped by farm. The client reviews and sends them.
• Victor can read, not act. The Telegram assistant answers operational questions and sends morning briefings. It has no write path to the working sheet.
Interface
The order form is rendered from the MVP code. The operational sheet and Telegram views are reconstructions with synthetic data. No client records are shown.
Synthetic AIRPLANE view. Original order and supplier invoice data stay in one row.
The working mobile order form, shown with synthetic data.Synthetic Telegram view of Victor's read-only morning briefing.
Technical architecture
The MVP is a serverless Google Workspace application. The mobile HTML/JavaScript form writes to Google Sheets through Apps Script. Gmail handles supplier drafts and invoice intake. Drive stores source documents. The Telegram bot reads the same operational data but cannot change it.
Operational record
AIRPLANE is the main working sheet. It keeps order data on the left and supplier invoice data on the right. Status colors show unsent requests, mismatches, unmatched lines, and revised invoices.
Supplier workflow
Selected rows are checked for product, quantity, unit, delivery date, farm, recipient, and carrier. A maintained dictionary translates product names and units into French. Apps Script groups rows by farm and creates separate Gmail drafts for review.
Invoice pipeline
A scheduled Gmail process sends the email body and every PDF or image attachment to Gemini. The extracted rows are normalized and matched to orders by product, recipient, delivery date, and farm. Source documents are archived in Drive.
Telegram operations
A Cloudflare Worker acknowledges Telegram webhooks before Apps Script processing. Duplicate update IDs are filtered. Victor answers text and voice questions from the operational data, can inspect attached documents, and sends a morning briefing. It cannot edit the sheet.
Stack: Google Apps Script · JavaScript · HTML/CSS · Google Sheets · Gmail · Google Drive · Gemini · OpenRouter · Telegram Bot API · Google Cloud TTS · Cloudflare Workers
What mattered
I had to understand the client's process before deciding where AI could help and where it had to stop. Gemini handled the messy documents. Matching, changes, and outgoing messages stayed under explicit rules and human review.
Public · Try it
Ukido AI Sales Assistant.
Answers parents. Sends ready leads to HubSpot.
Parents ask about courses, prices, teachers, or a problem their child is having. The assistant replies in Russian, Ukrainian, or English. It keeps the conversation context and sends a trial request to HubSpot when the parent is ready.
I started with a narrow technical question: how can the assistant find the right part of a knowledge base without loading everything into every prompt? Then I moved to the conversation itself: context, changing intent, refusals, and next steps across multiple turns.
This is my independent experiment. Ukido did not commission or validate it. I used the school as a setting. The courses, prices, knowledge base, and dialogue scenarios are synthetic.
Independent experimentWorking public demoSynthetic dataRussian · Ukrainian · English
A parent asks a question → the assistant answers from selected knowledge → keeps context across follow-ups → backs off after a refusal or sends a trial request to HubSpot when the parent is ready.
Current state
A working public demo. I tested the main paths through multi-step dialogue scenarios. It was not used by a real sales team, so I do not claim conversion or business results.
What I owned
I built the whole project from A to Z: product idea, synthetic business, knowledge base, dialogue logic, backend, web interface, HubSpot integration, test scenarios, and deployment. Coding agents helped me write the code. I decided what the system should do and checked what it actually did.
Product decisions
• Only relevant knowledge enters the prompt. The Router selects up to four documents. The Generator receives only that material.
• The conversation can change direction. The system tracks exploration, anxiety, price sensitivity, and readiness to enroll. It uses those signals to adjust the tone and next step.
• No selling on repeat. Refusals, completed actions, and CTA limits are tracked so the assistant can stop pushing the same offer.
• One flow works in three languages. Russian, Ukrainian, and English use the same knowledge and sales logic.
Interface
Conversations captured from the public demo. All courses, prices, and school data shown are synthetic.
Russian: a shy child.Ukrainian: prices and lesson format.English: course guidance.Russian: the assistant backs off after a refusal.
Technical architecture
The demo runs as a Python/FastAPI application on Railway. Gemini 2.5 Flash handles both AI stages through OpenRouter. The Router classifies the message and selects knowledge. The Generator writes the answer. FastAPI streams it to the browser over SSE. The orchestration stays in plain Python without LangChain or an agent framework.
Knowledge and routing
Fourteen Markdown documents describe the synthetic school, courses, prices, teachers, methods, safety rules, and conditions. JSON summaries help the Router select up to four documents for each answer.
Conversation behavior
The system keeps the last ten messages and tracks four parent signals, social state, refusals, completed actions, and CTA use. Per-user limits and bounded history keep each dialogue contained.
Dialogue testing
Multi-step scenarios model different parents and changes inside one conversation. Reports track signal transitions, context, tone, CTA behavior, refusals, and regressions across turns.
Delivery and integration
Trial requests create or update HubSpot contacts. Pydantic validates data. CORS restrictions, per-user limits, protected admin routes, Docker health checks, Pytest, and Playwright cover the path from API to browser.
A single good reply told me very little. I needed to see the whole dialogue: what the assistant remembered, how it reacted when the parent changed direction, when it offered a trial, and whether it stopped after a refusal. The multi-step scenarios made those checks repeatable.
Ask a question. Find a thought from a family collection.
Papa's Phrasebook is a Russian-language family archive. You describe a situation or ask a question. It finds one or two matching thoughts from a collection that began with 99 sayings my father had gathered himself.
I first built it for my family, then opened it to everyone. It is already used by my father, relatives, and friends. I do not track usage numbers.
My independent projectPublic and workingRussian only
Choose the full collection or one author → ask in your own words → receive one or two exact entries from that source. The full collection can also be browsed by topic.
Current state
The live search spans 3,774 entries. The main collection contains 2,497, including 2,398 additions I reviewed against the original 99. Separate collections for Khayyam, Rumi, Zhvanetsky, Guberman, and La Rochefoucauld are merged and deduplicated at runtime.
What I owned
I built the project from A to Z. I defined the product, expanded and reviewed the collection, designed the search and source rules, built the interface and backend, tested the result, and deployed it on Fly.io. Coding agents assisted implementation. The decisions stayed mine.
Product decisions
• The model does not write wisdom. Gemini selects IDs. The backend checks them and returns the exact stored text.
• The original collection sets the tone. My father collected the first 99 entries. I do not present later additions as his own words.
• An author is allowed to stay silent. A personal collection is used only for a direct match with high confidence. Otherwise, the system says so and searches the full collection.
• Cost has a hard boundary. The service has a daily Vertex AI budget and runs on one auto-starting Fly.io machine.
Interface
The public product is in Russian. The screenshots use the live interface and its stored collections. No generated sample data was added for the portfolio.
The full collection with 3,774 entries and topic filters.One question answered from a selected author collection.Mobile question screen.Two exact entries returned on mobile.One author shelf on mobile.
Technical architecture
The backend uses Python and FastAPI. The frontend is plain HTML, CSS, and JavaScript. Gemini runs through Vertex AI, and the application is deployed on Fly.io.
Corpus and provenance
The physical base contains 2,497 entries: 99 from my father's collection and 2,398 reviewed additions. At runtime, the base and five author collections are merged and deduplicated into 3,774 entries. Runtime text and provenance stay in inspectable JSONL files.
Retrieval and selection
For the full collection, Gemini 2.5 Flash Lite routes each question into one or two of 15 topics. Gemini 3 Flash then selects IDs from that smaller set. The backend rejects IDs that were not supplied to the model and inserts the exact source text.
Author collections
Each author has a separate exact-text corpus. New author collections are prepared on a private VPS through Harvester research and staged Codex workers. Research, source review, curation, deduplication, and human approval remain separate steps.
Evaluation and operations
The old full-corpus path matched the expected thematic cluster in 79 of 80 test situations. The route-topic path matched 80 of 80 and used about 81% fewer tokens in the same evaluation. The service also limits memory, avoids recent repeats, tracks corpus versions, and caps daily spending.
I wanted to test the technology properly and give people something they could use and enjoy. The difficult part was knowing when to add embeddings and FTS. The current route-topic path matched the expected thematic cluster in 80 of 80 test situations and used about 81% fewer tokens than the old path. For now, that is enough. Embeddings and FTS can wait.
