CASE STUDY · REAL-TIME MULTI-BRAND PLATFORM · INDEPENDENT · 2024–2026

One brand in.
Nine brands out.

1 → 9 BRANDSONBOARDING: IMPOSSIBLE → 4 DAYSEU · MULTI-LANGUAGEREAL-TIME OVER WEBSOCKETS

The inheritance

The platform I took over ran exactly one brand, and it could never run two. The theme was hardcoded. Brand logic was tangled through the codebase. Onboarding a second brand wasn't slow or expensive; it was not possible.

The business wanted a fleet. The domain: a regulated, high-traffic consumer platform serving EU markets, where the interface deals in real money and real time.

The re-architecture

I re-architected the frontend into a true white-label platform: brand as configuration, not code. JSON-driven theming and feature config, managed from a back-office console. A new brand's look, content, markets, and features are defined, not developed.

Real-time, where stale costs money

Live balances and odds/game state stream over WebSockets, across every brand, on one codebase. In this domain real-time UI isn't a feature; it's the product. A stale number on screen is a support ticket at best and a compliance problem at worst.

The team was the exit plan

I hired and mentored a small frontend team, leading architecture and review while shipping alongside them. From day one the goal was a platform and a team that wouldn't need me.

April 2026: handed the platform off to the team I'd hired. No dependency on me left behind. That was the point.

The numbers that matter

1 → 9
brands on the same codebase, up from the single hardcoded brand I inherited
4 days
best-case new-brand onboarding, previously not possible at all
3–4 wks
typical onboarding, depending on customization depth
2–5
frontend engineers hired, mentored, and led

STACK · REACTJS · REDUX · NODE.JS · WEBSOCKETS

Anyone can start a rewrite. The job is leaving behind a platform and a team that doesn't need you.

LET'S TALK →
©2026 PRATIK KULSHRESHTHPRATIKKULSHRESHTH@GMAIL.COMINDORE → REMOTE · IST