Selected work — one case, one principle
Architecture decisions that aged well.
Case studies of mobile products where I led architecture, foundation, or rescue. Each one is a decision that had to survive the next two years — not a sprint demo.
Yandex Pro — superapp architecture for 1M+ active users.
Mobile superapp for drivers, couriers, and self-employed professionals. I owned Flutter architecture, technical quality, and team coordination inside a 100+ engineer organization.
- Audience
- 1M+ active users
- Stack
- Flutter · Dart · BLoC · Clean Architecture · REST
- Org
- 100+ engineers · cross-team coordination
- Tenure
- 4 years 10 months
Context
Yandex Pro is the entry point for the people who actually deliver Yandex services — drivers, couriers, self-employed. It is not a consumer app with a marketing budget. It is a working tool that has to be reliable on cheap Android devices, on patchy 3G, in the rain, at the end of a 12-hour shift.
When I joined, the codebase had grown across several teams without a clear module structure. Every feature touched shared code. Releases were slow. The on-call rotation was burning out.
Problem
Three things were at stake. First, the architecture needed to let 100+ engineers ship in parallel without blocking each other. Second, business logic had to be changeable without a release — A/B tests, regional rollouts, regulatory branches. Third, incoming bug reports from a 1M-user base were overwhelming the on-call rotation.
Approach
- Feature-first modularization. Moved the codebase from layer-first to feature-first. Each feature owns its UI, state, data, and dependencies. Shared code is a contract, not a dumping ground.
- Dynamic redirection protocol. A server-driven routing layer that lets product add new business-logic branches without shipping the app. Used for regional rollouts, regulatory variants, and A/B experiments.
- AI bug triage. An internal classifier that routes incoming bug reports to the right team and surfaces duplicates and regressions before they reach a human.
- Architecture review as a process. Formal review for every cross-team change. Documented, opinionated, fast — under 48 hours.
Results
- Architecture supporting 100+ engineers across multiple teams shipping in parallel.
- Dynamic logic updates shipped without app releases — measured in days, not weeks.
- AI bug classifier reduced on-call load and shortened time-to-triage.
- 5 interns grown to middle level. 200+ technical interviews run.
Foundation Sprint — a mobile app built right the first time.
For founders, CTOs, and funded startups launching a mobile-first product. The work is short, intense, and decides the next two years.
- Format
- 2–4 week sprint
- Stack
- Flutter · chosen per product
- Deliverable
- Shippable foundation + team-ready standards
- Handoff
- Internal team continues without me
Problem
Most mobile products make their most expensive architectural decisions in the first six weeks — and then pay for them for the next six years. The default outcome is a codebase that resists every change and a team that ships slower every quarter.
Approach
- Architecture. Module structure, dependency rules, state management chosen for the team, not the trend.
- Project structure. Feature-first layout, code generation, testing pyramid that matches the product.
- Core flows. Auth, navigation, theming, error handling, logging — all wired and tested.
- CI/CD. Build, test, distribute, sign, release — automated and boring.
- Analytics & release. From day one. Not added later.
Result
A foundation that an in-house team can take over and extend. No rewrite at month six. No "we should have done it differently" conversation at the Series A.
Working on a Flutter app at scale? Let's talk.
Book a 30-min architecture call