Overview
I co-founded this interactive consumer live-streaming platform and wrote its first line of code in 2019. Creators go live from a webcam-and-PC setup, and an audience watches, chats, reacts, and sends virtual gifts in real time. It is the kind of product where every second of latency and every dropped frame is felt immediately by thousands of people at once — and where the social layer around the video matters just as much as the video itself.
Over six years I led it as CTO and technical founder. In the early days that meant writing large parts of the system myself: the API, the real-time layer, the first version of the player, the streaming pipeline. As it grew, my job shifted from writing most of the code to designing the architecture, setting the engineering standards, and building the team and culture that could keep a fast-moving product reliable at scale. In 2024 the company was acquired by an international group, and I continued to lead engineering through 2025.
The product
At its core the platform is live video plus a live room. A creator broadcasts; viewers join a room around that broadcast and interact with the creator and each other through chat, presence, reactions, and a virtual-gift economy. None of those pieces is interesting in isolation — the product is the way they come together into something that feels alive and immediate.
That shape drove almost every technical decision. The video has to arrive with low latency across continents. The chat and reactions have to feel instant even when a popular room has a large, bursty audience. The gifting economy has to handle real money correctly, every time. And the whole thing has to stay up, because a live platform that goes down is not degraded — it is simply off, in front of everyone, at once.
The challenge
Real-time, two-way live video at consumer scale is unforgiving on several axes simultaneously.
Latency and delivery. Live video is judged in seconds, not page-load milliseconds. We needed adaptive-bitrate delivery that held up across regions and network conditions, and an architecture where the video path could scale independently of everything else.
A responsive real-time layer. Chat, presence, reactions, and gifting all have to land in well under a second, and the load is spiky by nature — a room can go from quiet to crowded the moment a popular creator goes live. That ruled out anything that assumed steady, predictable traffic.
Correctness under money. A virtual-gift economy means real-money top-ups, balances, and creator payouts. Those flows have to be idempotent and auditable; "mostly right" is not acceptable when it is someone's earnings.
Organisational scale. The quieter challenge was turning a three-person codebase into something a dozen engineers could work in at once without constant collisions — which is as much an architecture problem as a process one.
Architecture
The platform is a single TypeScript monorepo built with Turborepo and pnpm. Keeping the web client, mobile-web client, backend services, and shared packages in one repo — with one type system end to end — was one of the highest-leverage decisions we made. A change to an API type surfaces immediately in every client that uses it, and shared logic lives in one place instead of being copy-pasted across services.
The backend is a set of NestJS services exposing a GraphQL API (Apollo). GraphQL gave the clients a single, typed, code-generated contract: the frontend never hand-writes a request or guesses a response shape. Persistent state lives in Postgres (via Sequelize), with Redis for caching and hot state and RabbitMQ for queues and event-driven workflows so that slow or bursty work never blocks a request path.
Everything runs as containerised services on AWS ECS, with infrastructure defined as code in the AWS CDK. Deploying the platform across two regions — one in the US and one in Asia — kept latency low for a genuinely global audience rather than serving everyone from a single continent.
The real-time layer
The interaction layer — chat, presence, reactions, gifting events — runs on Socket.IO with a Redis adapter. The Redis adapter is what lets it scale horizontally: connections can land on any instance, and a message published in one room fans out to every subscriber regardless of which instance they happen to be connected to. That meant we could add capacity by adding instances instead of re-architecting every time a room got bigger.
Designing this layer was an exercise in deciding what has to be perfectly consistent and what merely has to be fast. A chat message can tolerate best-effort delivery; a gift that moves real value cannot. Drawing that line carefully — fast paths for the ephemeral social signals, durable and idempotent paths for anything touching balances — is what let the system stay both snappy and correct under load.
Delivering live video globally
On the client side, the web and mobile-web apps are Next.js / React applications with a typed, code-generated GraphQL layer and HLS adaptive-bitrate playback, fully internationalised for a global audience. HLS lets each viewer's player negotiate the best quality their connection can sustain and shift down gracefully rather than stalling, which matters enormously when your audience spans continents and network conditions.
Pairing adaptive playback with multi-region delivery — the US and Asia regions, plus CDN-backed distribution — is what kept the experience smooth whether a viewer was near a region or far from one. The video path was treated as a first-class, independently scalable concern rather than something bolted onto the API.
Reliability, safety, and observability
A live platform has no quiet maintenance window — it is always someone's prime time somewhere. We invested early in observability (Sentry for errors, product analytics for behaviour) so that problems were visible before users had to report them, and in the operational discipline — health checks, alerting, and clear ownership — that a 24/7 product demands.
A real-time consumer platform also needs trust-and-safety tooling built in rather than bolted on: moderation surfaces, rate limits, and abuse controls that operate in real time alongside the chat and streaming systems. Later in the platform's life we added AI-powered features on AWS Bedrock, layering machine assistance onto parts of the experience.
Scaling the team
As technical co-founder and CTO I owned both the architecture and the engineering organisation, and the two are not separable — the system's structure and the team's structure end up mirroring each other. I grew engineering from three people to around twelve, while the company as a whole grew to about fifty, and a large part of that work was putting in place the standards that let the team keep shipping safely: end-to-end typed GraphQL, a well-factored monorepo with clear module boundaries, testing, CI/CD, and feature-branch deployments so changes could be reviewed and verified in isolation.
The hardest stretch of that growth ran straight through COVID. Between 2020 and 2022 we were trying to hire aggressively into a climate where almost nobody wanted to change jobs or relocate — the world felt too uncertain to make a move — so building the team meant working much harder for every hire and keeping the people we had through a deeply unsettled period. We grew it the way the talent allowed: the first engineers were in China, then we built up a team in Taiwan, and in 2023 the engineering organisation settled in the Netherlands. Holding a distributed, multi-timezone team together across that journey — and keeping it shipping the whole time — was as much of the job as any architecture decision.
The goal throughout was to keep the marginal cost of the twelfth engineer's change as low as the third engineer's had been — to grow the team without the codebase grinding to a halt. The repository records that whole journey: more than eleven thousand commits from dozens of contributors over the years, starting with mine.
Outcome
What began as a prototype I wrote in 2019 grew into a global live-streaming platform with a substantial engineering organisation behind it, and was acquired by an international group in 2024. I continued to lead engineering through to 2025 — across the integration that follows an acquisition, with the architecture and the team both holding up under the change.