
- Role
- Frontend Developer
- Period
- 2024
Private Build
Under NDA. The numbers are real, and I'm happy to walk through the product on a call.
A Telegram-first PvP mini-app with live socket matches, Web3 payments, donations, referrals, and a fast tap loop shaped for high-volume player onboarding.
StackReact, Web3, Socket.IO
Users in ~3 months
a 100K paid base turned into millions.
Growth in week one
100K paid users became 1M players in seven days.
Real money on-chain
PvP stakes, donations and payments behind one wallet.
What I owned
Frontend ownership end to end: the game client and how it feels on low-end hardware, the realtime layer, and the Web3 payment surface.
Canvas rendering
Sprite animation
Game loop
Mobile controls
Haptics feedback
Economy UI / UX
Web3 payment UX
Frontend performance
The box it had to live in
- Platform
- A Telegram mini-app: instant open, a tight bundle budget, no app-store install.
- Devices
- Low-end Android, touch input, flaky mobile networks.
- Scale
- 100K paid users to ~4M in months: viral spikes, not steady traffic.
- Stakes
- Real on-chain currency, so every result has to be server-verified.
The problem
How I approached it
01
Rendering
02
Realtime
03
Anti-cheat
04
Payments
05
Attribution
06
Economy
How it helped
- Onboarding stopped being the funnel's drop-off point.
- Referrals, not paid spend, carried the growth.
What I chose (and what I didn't)
- Canvas 2D
- A custom 2D layer instead of a game engine: a couple-MB bundle and control of every frame on budget Android.
- Server-authoritative
- The server owns the result: with real currency in play, the client renders but never decides.
- One wallet provider
- TON Connect and Telegram Stars behind a single surface: one integration in place of three.
- Lazy accrual
- Passive income from one timestamp instead of a cron over every account: O(1) per active user, nothing spent on idle ones.
What the spike broke
100K → 1M in a single week surfaced what steady traffic never did.
- Too many client requests
- Trimmed and batched calls and added HTTP caching on the hot paths.
- Postgres under pressure
- Moved hot reads to Redis and recomputed passive income lazily, never for idle accounts.
- Heavy screens at peak
- Non-critical features degraded gracefully instead of taking the app down.
- Viral invite traffic
- Referral attribution stayed duplicate-safe and server-validated under the flood.
Tech stack
ReactTypeScriptMobXCanvas 2DWebSocketRedisPostgreSQLTON Connect