01 / Operations
Manager UI
Control the network, configure products and resolve exceptions.
ProductsOffersPartnersConversionsStatisticsDocumentsApprovals
01 / Production fintech · CPA partner platform
Tinkoff fintech platform
Built and evolved partner and internal operations frontends for a fintech platform serving 300,000+ users, spanning onboarding, analytics, approvals, documents, and real-time workflows.
- Role
- Frontend Developer → Senior Frontend Developer
- Period
- Aug 2021 — Feb 2026
- Scale
- 300,000+ users
- Status
- Featured case
01 / Product system
Two products.
One operating model.
The frontend was not a collection of screens. It coordinated two connected experiences, shared infrastructure, and business workflows that crossed role boundaries.
Shared foundationAuth · UI · routing · API · eventsImpersonation bridge
02 / Self-service
Partner UI
Discover offers, track results and complete operational workflows.
Offer discoveryPerformanceOnboardingQuizAcademySigningSupport
02 / The hard part
Identity was a runtime context.
A manager could open multiple tabs as different partners while global notifications and chat still belonged to the manager session.
Original sessionManager identityOwns global features
Every requestAuthentication · permission check · audit contextBackend remains authoritative
03 / Architecture
Data changed shape at deliberate boundaries.
An MVVM-inspired flow kept transport models away from view concerns. Components received UI-ready data instead of interpreting backend responses themselves.
State ownership matrixAuthority × lifetime × update radius
Remote data, caching, invalidation and request lifecycle
Active partner identity and short-lived impersonation tokens
Cross-feature client state with an intentional lifetime
Forms, drawers and interactions owned by one component tree
04 / Decisions
Architecture followed the constraints.
The important choices were less about picking libraries and more about making ownership, identity and change safe at product scale.
How should one product serve two very different roles?
A modular SPA with explicit domain boundaries
Why this fitThe teams shared authentication, routing, UI foundations and release cadence. Independent deployments would have added coordination cost without solving an organisational problem.
How can a manager safely work as several partners?
Identity became explicit request context
Why this fitEach browser tab owns an active partner ID; an in-memory map resolves it to a short-lived token. Manager-owned features remain attached to the original session.
Where should changing product data live?
State ownership follows authority and lifetime
Why this fitRemote data stays in the server-state layer. Session, shared UI and local interaction state each have smaller, deliberate update paths.
How could the system evolve while it was still shipping?
Sequenced migration into shared foundations
Why this fitProduct delivery continued while shared contracts, tooling and components became stronger. Each migration reduced risk without requiring a disruptive rewrite.
05 / Contribution
Built inside a living product.
I built the frontend from scratch, defined its architecture and state-management approach, and owned delivery for critical workflows. From requirements through release, I worked with product, design, backend, and QA. I was promoted to Senior in January 2024.
The diagrams use simplified flows and generalized domain names. They contain no proprietary source code, customer data, or internal system details.
06 / Outcome