nda case — visuals are illustrative, the live ui is hidden
Scope of work
We began with five moments in which a competitive match loses value: a seasonal reset breaks the continuity of progress, lobby transitions lose context, a no-show or leaver wastes everyone else’s time, a server failure threatens the result, and opaque fair play erodes trust. BAKS exists to preserve the player’s time, progress and trust across that journey, so the unit of product became not a lobby found, but a match that reaches a valid result.
BAKS brings the player client, party and lobby, matchmaking, rating, fair play, game-server orchestration and post-match into one lifecycle. Rating, matchmaking, trust and the server lifecycle are implemented in backend contracts and code; Play is a stateful frontend prototype. We first tested the hypotheses through synthetic scenarios, transition tests and backend protocol tests; real CS2 staging and the closed alpha are the next level of proof.
I owned product direction, roadmap and priorities, managed the team and delivery process, led UX/UI, the design system and motion, and built the key frontend surfaces hands-on. Backend and game-server work was delivered with the team.
Product solutions
Rating without a seasonal reset
A season does not erase the skill estimate. Inactivity increases uncertainty and may lower the displayed rating so subsequent matches recalibrate faster. An external rank maps through relative position and records its source. One engine calculates win and loss stakes in advance; the final change may include a limited positive bonus for personal performance.
The lobby as a match contract
Party, readiness, search, warm-up, veto, side selection, connection and post-match stay in one scene without losing context. Additional signals replace the baseline split only when they strictly improve it. As liquidity falls, constraints gradually relax so the pursuit of precision cannot turn into an endless queue.
Recovery before cancellation
Before assignment, Flash Fill invites a solo player into a stalled search. Afterwards, Flash Save seeks a role-matched replacement for the same server. Within the limited shield, a protected defeat carries no rating loss, while a win counts in full. Without a replacement, parties requeue after a no-show while a live match resumes short-handed. The protocol is implemented; real CS2 staging validation has not yet run.
Server reliability as product
Auto-region prefers an available region with free capacity and uses ping supplied by the client. Repeated assignment cannot create a second server. With persistent storage, the result is stored before delivery, while a restarted orchestrator reattaches to a surviving match or explicitly aborts a lost one. Reliability becomes part of the player journey rather than invisible infrastructure.
Trust without a black box
The trust API exposes only a coarse standing, safe factors and ways to improve while hiding detector logic and reporter identities. Smurf suspicion is non-punitive: it may accelerate calibration upward and influence balancing. When the signal is strong or repeated enough to confirm the suspicion, the system opens human review rather than applying an automatic ban. After a permanent cheating ban, clean players recover their net rating loss from recent voided matches through a separate correction.
Stages of work
Before — the match was split across systems
Key backend modules already existed, but rating, lobby, server and result did not form one coherent player journey, and the frontend lagged behind the platform foundation.
One match as the primary goal
Following category research, we chose a product thesis: differentiation would come from match continuity, not feature count. I rebuilt the roadmap and team priorities around the first completed match.
Contracts and critical states
One lifecycle contract connected rating, lobby, replacement and server work and aligned design, frontend, backend and game-server delivery around incomplete data, no-shows, leavers and failed result delivery.
Team, implementation and tests
I led the player experience work and built the shell, home, friends and the typed Play state machine hands-on. Shared components, tokens and motion rules became one implementation language for the team, while critical transitions were checked through automated tests and synthetic scenarios.
Live validation as the next step
Next comes live auth and realtime integration, real CS2 plus MatchZy validation, and a closed alpha. It will measure first-match completion, the share of matches saved after a leaver, successful connection and result registration, and the start of a second match.
