Anything you can open by link comes first.
01
Live products and open code: publicly running, links work.
An ISP’s CCTV and intercom, opened up for a smart home
The provider exposes its cameras and intercom only through its own app. I reverse-engineered the private protocol and built an integration: RTSP and WebRTC cameras, intercom call history, snapshots and archive-clip retrieval through Home Assistant services. Installable via HACS and running in other people’s homes — hence the issues and the stars.
A map of Russian filling stations: fuel prices and availability
A product I own end to end: collecting and normalising data across fuel-station networks, the backend and database, a filterable map, SEO, and deployment to my own nginx VPS. There is nobody to split product decisions or on-call with.
Subscribe to seats that do not exist yet
A Telegram bot on aiogram: step-by-step train search, then a subscription that polls the railway API every few minutes and pings you the moment a seat frees up. Filters by seat type, finding seats next to each other, and parsing the carriage seat map. The hard part was not technical but interface: the whole dialogue lives in a single message the bot rewrites, so the chat stays clean. SQLite for subscriptions, pytest and GitHub Actions inside.
Services with no public API, wired into the smart home
Custom components for services that never promised an API: meter readings and billing from Центр-СБК and Теплоэнерго, balance and data usage from Tele2 (plus tele2api, a standalone client library). The recipe is the same every time — take the client apart, write the protocol down, wrap it in an async client with a config flow, and hand the user an “Add integration” button.
An MCP server exposing a coffee roaster’s catalogue to LLM agents
A deployed MCP server that hands a coffee roaster’s catalogue to an AI assistant: product search and detail, prices, reviews, discounts and an anonymous shared cart. It connects with a single command — the server page ships ready-made config for Claude Code and Claude Desktop.
02
Dozens of external sources with unstable formats
A backend platform continuously pulling data from a large number of external systems, each free to change its format whenever it likes. Data models and API design, ETL pipelines, handling upstream schema drift, retries, logging and data-quality monitoring. For the least structured sources, ML-based extraction.
What exactly is built from what — in one place
Centralised inventory and analysis of software components: collecting data from artifact repositories (Nexus) and external sources, normalising and matching components and versions, analytics and reporting on top. The hard part is not collection but reconciliation: the same library arrives from different sources under different names and versioning schemes.
Authentication, role model, file storage
The architecture of a set of FastAPI services over PostgreSQL and Redis: single sign-on built on ORY Hydra (OAuth2/OIDC), a role model and access control, sessions, file storage and internal APIs. DDD, modular structure, dependency injection, migrations — plus the code review and mentoring around all of it.
REST APIs and microservices behind a mobile client
REST APIs in Python alongside Node.js services, contracts described in Swagger. Microservice architecture on Redis, Kafka and MongoDB, async and multiprocessing. Tests with pytest and unittest, services in Docker.