This article is part of the Flatstudio × Mollybet case study series. It’s for founders and product teams building complex B2B products who want to understand how a design system becomes infrastructure for white-label scaling. The main article in the series is here.
How Mollybet’s Design System Became a White-Label Sales Engine
The brief from James Clark arrived on March 22, 2023. The product aggregated odds from 15+ bookmakers at the same time, executed orders faster than any competitor, and was technically unmatched. It also looked exactly like it was built: a system made by technical engineers for technical engineers. That works when your entire audience is engineers. MollyBet’s audience wasn’t — or at least it couldn’t stay that way after the planned B2B expansion.
The task was clear: make the product ready for white-label use. Not just visually cleaner, but structurally prepared so partners could take it, customize it, and deploy it under their own brand. Gabriel Burne and James Clark knew their product deeply. They needed a team that could translate that technical depth into a scalable design language without breaking the workflows professional traders already relied on.
We had 17 months.
The Brief: A Bloomberg Terminal Without Branding
MollyBet is not a sportsbook. It’s trading infrastructure — an aggregator that routes bets through Betfair, Betdaq, SBOBet, PS3838, Singbet, and others through a single account. It always finds the best available odds and splits orders across providers when one source cannot cover the full volume.
There were three audiences:
- Professional bettors who treat the platform like a trading desk
- B2B partners with white-label configurations
- Liquidity providers inside the network
The core product was dense: real-time odds from 15+ sources, an order book with dark orders and cashout mechanics, win-loss grids, and position tracking — all constantly updating.
It worked. But it didn’t communicate value to anyone who didn’t already understand it deeply. A potential white-label partner opening the interface for the first time only saw a wall of numbers.
That became the real brief: build a visual language that lets a partner immediately see themselves inside the product without needing a two-hour onboarding session.
Tokens First, Screens Later
We didn’t open Figma and start drawing screens, we started with the design system.
Light and dark themes were planned from day one. This was a foundational architectural decision. We’ve followed this approach on every iGaming and fintech project since Stavka and BoxBet: when you are building the 200th component, adding a second theme later becomes extremely painful. If the token system is done properly from the beginning, adding themes later costs almost nothing.
The full token architecture covered:
- Color
- Typography
- Motion
- Spacing
- Icon sizing
- Charts and graphics
- Responsive grids
- Navigation patterns for desktop, tablet, and mobile
Everything lived inside Figma with structured layer naming, slots, and Auto Layout. Dev Mode was connected and versioned because James’s frontend team needed specifications they could implement directly — not PDFs with annotated screenshots.
That mattered. James and his team spoke the language of CSS. Our documentation had to speak the same language.
981 Components — The Cost of Complexity
One number tells the whole story: 981 components in the system by the end of the project. A trading platform has a very different component profile than a standard SaaS dashboard. It’s not a few card types and table variations. It’s hundreds of small, highly specialized elements, each with multiple states, all working correctly across every theme.
A price cell behaves differently when:
- It shows the best available odds
- It updates in real time
- It is selected
- It is unavailable
Now multiply that across 981 components. Then multiply again for every theme. Multi-theme validation became the part that took longer than expected because the platform was genuinely complex. Every component required visual QA in every theme and every state.
Performance optimization added another layer. The Sonic core processed real-time odds updates, so every component displaying live data had to be designed around that refresh cycle. There were no shortcuts.
Roman and I drove this process together. Roman joined the project as an interface designer. By month six, he was already proposing structural improvements to the design system without being asked — better typography scales for desktop and mobile, improved developer documentation for James’s team, and independent research he brought into the project himself. The project became a catalyst for his growth. He was also consistently available outside working hours during critical moments. On a project of this scale, that matters.
Gabriel and James attended every call with cameras on, giving direct and technically precise feedback. They always saw exactly what we were looking at. There were no empty “looks great!” comments without technical discussion — and we preferred it that way.
Two Days for a New Partner Theme
This is where the investment paid off. When the first partner requested a custom color configuration, we estimated two days. We finished in one.
Because when the token architecture is done correctly, adapting a new theme really is a two-day task at most. We had already built the same mechanism for the Bookmaker.xyz template system. The muscle memory was there.
For a white-label business, this matters more than almost any other metric.
A partner asks:
“Can you adapt this to our brand?”
And they hear:
“Yes, by Thursday.”
That creates a completely different sales conversation than:
“Yes, in four to six weeks.”
The first answer closes deals, the second opens negotiations. Our design system powers the entire B2B pipeline.
17 Months, Two Products
The project moved through several phases:
- Product Audit & Discovery
- Wireframes
- Design concept
That design phase eventually split into two separate directions:
- The current platform
- A parallel Gen Z concept with a completely different visual language and interaction model
The Gen Z version targeted a younger audience expecting professional betting tools to feel as sharp and modern as the financial apps they already used daily.
The current platform and the parallel Gen Z concept came from the same DNA, but served different audiences with different visual systems.
The landing page redesign came after launch. Reworking the public face of the product — clearer positioning, stronger hierarchy, and presenting the platform for partners instead of developers — significantly reduced inbound friction. Partners arrived already understanding the core value proposition before the first call even happened.
Along the way, Bereal (my dog) and Trip (Elena’s dog) became regular participants in calls with Gabriel and James. Eventually they joked that these dogs had collected a dangerous amount of corporate intelligence and that nobody should trust dogs around confidential information anymore.
That was the relationship: relaxed enough for jokes, professional enough to build successful products together.
The Main Lesson
A design system built for one product is infrastructure. A design system built with partners in mind from the very first token becomes a sales asset. The difference is invisible during production and obvious six months after launch.
If you are planning white-label expansion and your design system still doesn’t include:
- Token architecture
- Multi-brand configuration
- Clean developer documentation
Build those first. Everything else is doing the work twice.
Building a complex B2B product that needs to scale across partners, brands, and teams? Our Dedicated Product Team and Post-MVP Evolution services are built for exactly that. We’ve done it across iGaming, fintech, and SaaS. The token architecture stays the same. Industry knowledge does not.
Other articles in this series:
→ Why Your Betslip Is Wrong: Designing for Traders, Not Players — link
→ Mollybet Gen Z: A New Product from the Same DNA — link
→ How We Redesigned the Mollybet Marketing Website — link
Frequently Asked Questions
Who are these solutions best suited for?
We design around complex, high-stakes products rather than simple marketing sites. Our solutions are best suited for B2B and B2C SaaS, fintech, sports tech and iGaming teams dealing with high-load dashboards, internal tools, betting platforms or multi-platform ecosystems. Most of our clients are startups and scale-ups that need a consistent design and engineering partner instead of a one-off creative studio.
What's the difference between a fixed‑price sprint and a long‑term retainer?
Fixed‑price sprints (like Fundraising Concept or Product Audit & Discovery) have a clearly defined scope, timeline and deliverables — for example, a 4‑week concept sprint or a 2–3 week audit. They are ideal when you need a sharp, focused outcome. Long‑term retainers (like Post‑MVP Evolution or Dedicated Product Units) are built for continuous evolution: we join your roadmap, work in sprints, and adjust priorities as your product and metrics change. You get a predictable monthly budget and an embedded team instead of re‑negotiating every feature.
How do I choose between Pitch Deck & Product Concept, Post‑MVP Evolution, Product Audit & Discovery, and Product Rebuild & Redesign?
Pitch Deck & Product Concept is for 0→1 founders who need to raise capital before writing production code – we turn your vision into an investable narrative and clickable concept. Post‑MVP Evolution is for Seed / Series A teams with a live product that needs faster iteration, stronger UX and a real design system. Product Audit & Discovery is for products facing churn, stagnation or negative feedback – we diagnose UX and tech friction and give you a prioritised roadmap. Product Rebuild & Redesign is for mature or legacy platforms that have hit a growth ceiling – we modernise brand, UX and code without breaking the business logic that already works. If you’re unsure, we start with a short discovery call and map your current stage to the right model.
How is "Engineering Design" different from a regular creative agency?
Regular agencies optimise for “wow” moments and campaigns. We optimise for systems and product performance. We treat design like code: modular, scalable and logic‑driven. Instead of drawing standalone screens, we build design systems, patterns and documentation that your developers can implement without guessing. That’s why our solutions always combine product & interface design, brand identity, web app engineering and marketing assets into one coherent system.
Do you work with startups or only established companies?
Both. Our clients range from early-stage founders raising their first round to enterprise teams scaling complex platforms with millions of users.
What do clients value most about working with Flatstudio?
Clients consistently highlight three things: deep industry knowledge, logical and scalable design systems, and honest communication. We challenge weak decisions early rather than executing them blindly.
.png){kind=small}
