All work

PvP gaming mini-app interface
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
4M

Users in ~3 months

a 100K paid base turned into millions.

10×

Growth in week one

100K paid users became 1M players in seven days.

TON

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

Open to frontend & fullstack roles.