MrQ

From two engineers to millions of players

I joined MrQ in February 2016 as its second engineer. I built the frontend, while Iulian, my CTO and mentor built the backend. Starting from scratch let us own the product instead of working within the limits of a white-label platform, giving the business endless flexibility.

From the first commit through to release, I built the customer-facing UI and frontend architecture. MrQ soft-launched in August 2018 and had its official launch that October. All of its software was built in-house. MrQ started with bingo and now offers slots, live casino and bingo, with more than a thousand games.

MrQ won the EGR Rising Star Award and a BingoPort.com Player’s Choice Award in 2019, then EGR Slot Operator of the Year in 2021. Since then, the original frontend has been extended for more than ten years without a full rewrite, proving the architecture.

Those systems now support:

• Personalized content delivered to more than 3 million users each month via server-driven UI.
• A component system used by more than 60 people across engineering, design, content and other teams.
• Distributed and serverless services handling more than 10 TB of traffic each month.
• A typical development cycle of one or two days.
• An extremely low change failure rate, meaning developers were developing features instead of fighting bugs and tech debt.

Good patterns, cutting edge

In 2016, React and Redux gave us useful building blocks but no blueprint for a large application. Redux deliberately left structure to each team. Its early ecosystem also required a lot of repetitive setup. I studied the emerging practices and built an internal framework around Redux. It gave every feature the same structure and removed much of that setup.

In 2019, the Redux team released Redux Toolkit to solve many of the same problems. It later became the standard way to write Redux, and its design had a lot in common with ours. Consistent structure meant an engineer could open an unfamiliar feature and know where each piece belonged.

Function components before Hooks

In 2016, React components with state were usually classes. I wanted small function components as the default, with stateful behavior we could reuse. I introduced Recompose. Its helpers let us add state, handlers, lifecycle behavior and render optimizations without turning components into classes. It felt much like Hooks before Hooks existed.

When React 16.8 made Hooks stable in February 2019, the approach already felt familiar. We could adopt the native API without a broad rewrite because our component boundaries and shared logic already matched the Hooks model.

Component-level responsiveness

Media queries only know the viewport width. A card might sit in a narrow sidebar, a carousel or a full-width grid, but it cannot adapt to that space without page-specific CSS. Container queries let the card respond to the width it actually receives.

I designed our component system around that idea from the start, using a polyfill about six years before native support reached browsers. Components adapted wherever we placed them, which kept us from creating variants for every page. When container queries became stable across modern browsers, the underlying model did not need to change.

A UI the business could change

A conventional API sends data while the frontend decides how to assemble the page. Campaign and compliance changes then wait for a frontend release, as do many product experiments.

I designed a server-driven UI protocol for MrQ that made page composition part of the contract. The frontend still controlled how each component rendered and behaved. The server chose the components, their order, content and configuration for each context.

Marketing could update campaigns without a frontend deployment, and compliance changes could be applied consistently. Product teams could test variations without leaving permanent branches in the application. The same protocol now delivers personalized content to more than 3 million users each month.

Three years after our implementation went live, Airbnb Engineering published a deep dive into its Ghost Platform. The designs are not identical, but both let the server assemble interfaces from parts owned by the client.

Consistent quality and fast scaling

I established a component-first development workflow via Storybook, with preview deployments for every change and error monitoring. We also made reviews and testing routine, and implemented advanced product analytics to guide experiments and strategy.

We adopted Storybook soon after it launched in April 2016. Engineers and designers could develop and review components in isolation. Together with preview deployments and PR workflows, quality checks became an integral part of daily work, with automation moving as much as possible out of our way.

After creating an interview process, I recruited, managed and mentored engineers across teams. We defined what each role required and assessed candidates against the same criteria. Once hired, engineers had clear conventions and quick onboarding.

A decade without a rewrite

A decade without a rewrite only matters if the product can keep changing. MrQ grew from a bingo site into a casino serving millions of users. Its interface, regulatory work, campaigns and engineering team all grew with it. The frontend absorbed those changes one at a time.

Several early choices later became common: function components with reusable stateful logic, opinionated Redux tooling, container-aware design, isolated component development, server-driven interfaces and server-side rendering. We chose each one carefully, so later features didn't force architectural changes.

Those decisions let a much larger organization keep changing a frontend built by a very small team. More than ten years after the first commit, the team still ships new work on that foundation.