MyCricle
White-label hospitality SaaS unifying guest WiFi, multi-channel marketing, loyalty, and POS — 253 screens across 10 modules, 3 repositories, built solo over 6–7 months for a Canadian direct client.
My Role
Sole Principal Designer + Primary Frontend Developer
Duration
6–7 months
Year
2023
Tools
Figma · React 18 · TypeScript · Apollo GraphQL · MUI v5 · Redux Toolkit · AG Grid Enterprise
Project Brief
Build a white-label SaaS platform consolidating guest WiFi analytics, SMS/email blast marketing, loyalty programs, reputation management, and POS integration — for restaurant and hotel operators across North America — from design system through production code across three repositories.
White-label hospitality SaaS unifying guest WiFi, multi-channel marketing, loyalty, and POS — 253 screens across 10 modules, 3 repositories, built solo over 6–7 months for a Canadian direct client.
Platform Architecture
5 surfaces. 3 repositories. 1 design system.
White-label hospitality SaaS covering every operator and guest touchpoint — governed by a single token-based design language.
Operator Admin Dashboard
Restaurant & Hotel Operators
Main platform — sole designer and primary frontend developer (Repo 1)
Smart WiFi Module
Operators managing guest WiFi
Separate repository (Repo 3) — complete design and engineering ownership
Guest WiFi Splash Pages
In-venue guests joining WiFi
White-label, operator-branded mobile web experience
Loyalty Check-in Kiosk
In-venue customers earning loyalty points
Tablet-first loyalty check-in — design owned, partial dev contribution
Email & SMS Campaign Templates
Campaign recipients
Branded templates with live two-panel preview in campaign builder
My Ownership Breakdown
The Problem
5 tools. No shared guest data. Zero unified marketing. Every guest interaction was siloed — WiFi didn't know about loyalty, loyalty didn't know about campaigns.
Restaurant operators had no single view of guests. WiFi logins, loyalty check-ins, email blast history, and reputation alerts lived in separate dashboards with no cross-platform intelligence. Coordinated promotions required manual export-import across tools — work that rarely got done.
No unified guest intelligence
Operators couldn't correlate a guest's WiFi login with their loyalty tier, past orders, or email engagement — all in separate databases.
Campaign tools outside the platform
SMS and email blasts required manual CSV export from POS into external marketing tools — audience targeting was always stale.
No real-time operator visibility
WiFi performance, loyalty redemption rates, and reputation trends couldn't be seen together — let alone acted on together.
White-label with no token system
Every new operator brand required manual screen duplication. No token architecture existed to support multi-tenant customisation at scale.
UX Audit
What was broken before we redesigned
A heuristic evaluation of the existing system identified these critical issues before any design decisions were made.
No shared data layer
WiFi, loyalty, and marketing had separate databases with no real-time bridge.
ArchitectureNo white-label system
Operator branding required manual screen duplication — not a scalable token system.
Design SystemNo live preview in builders
Campaign builders had no preview panel — operators sent test messages to see output.
UX PatternNo data-dense admin tables
Guest management required spreadsheet exports — no in-platform filtering, sorting, or bulk operations.
Admin UXOur approach: Build a hub — not a feature list
Designed MyCricle as a hub architecture — a central platform where all 10 modules share one guest identity and one data layer. Every campaign builder uses a live-preview pattern. Every data surface uses a shared AG Grid Enterprise table system. Every operator surface renders under their own brand via a token system that requires zero redesign to switch.
Process & Approach
How I approached the challenge
Platform Discovery
Mapped all 10 module workflows against operator mental models. Competitive analysis of Toast, Square, and Lightspeed to identify white-label and data-sharing gaps.
Design System First
Built token system — colors, spacing, typography, radius, elevation — before designing any screen. 80+ auto-layout components in Figma.
Live-Preview Pattern
Established two-panel wizard as the platform signature pattern: left = configuration form, right = live device preview. Applied across all campaign builders.
Multi-Surface Execution
Designed 5 surfaces sequentially — admin dashboard, WiFi module, splash pages, kiosk, email/SMS templates — each adapting the design system for its form factor.
Engineering Across 3 Repos
Implemented in React 18 + TypeScript. Built custom AG Grid Enterprise wrappers, DnD builder interfaces (@dnd-kit, react-beautiful-dnd, react-nestable), and runtime token provider syncing Figma tokens to CSS variables.
Design Principles
Design for operators who are also running a restaurant
Every decision was filtered through one constraint: a restaurant operator has 8 seconds per task during a busy service.
One brand, any operator
Every component is white-label by default. Colors, logos, and domain swap via tokens — no screen-level redesign when a new operator onboards.
Show the output, not the form
Campaign builders never hide the end result. The live-preview panel makes configuration confidence instant — reducing test sends.
Data density without complexity
Operator tables show everything relevant per row. AG Grid Enterprise handles the heavy lifting; the design handles the hierarchy.
Tokens all the way down
Colors, spacing, radius, elevation, and typography are all token values. This is what makes white-label work and what keeps 3 repos consistent.
When the design system is strong enough, the 5th surface costs less than the 1st. That's the only scalable hospitality SaaS strategy.
Why This Was Hard
Complexity signals
What set this project apart from standard product design work — the technical, systemic, and domain-specific challenges that demanded real depth.
White-label at token level
Every UI element supports operator-brand customisation via CSS variables synced from a Figma token provider — no rebuilding screens per operator.
5 distinct design surfaces
Operator admin dashboard, WiFi module app, customer splash pages, loyalty kiosk, and email/SMS templates — all sharing one design language across 3 separate codebases.
3 simultaneous DnD libraries
@dnd-kit, react-beautiful-dnd, and react-nestable coexisted in one frontend — each serving a different builder surface with incompatible interaction models.
Live two-panel preview wizards
Campaign builders across email, SMS, and WiFi all required a live right-panel device render that updated in real time as the operator configured settings on the left.
AG Grid Enterprise at operator scale
Guest management tables required AG Grid Enterprise with custom cell renderers, virtual scrolling, and multi-column sort — matching the design system.
Production integration stack
Twilio (SMS/MMS), Stripe (subscriptions), AWS S3, Firebase (auth/real-time), Redis (caching), PostgreSQL — each reflected in the UX through loading and async state design.
One designer. Five surfaces. Three codebases. Six months. North American hospitality operators depending on it in production.
UI Screens
Platform screens
253 screens across 5 surfaces — designed in Figma, implemented in React 18.
Feature Highlights
Key platform capabilities
White-label Token System
Operator brand tokens sync from Figma to runtime CSS variables — logo, palette, and domain switch per operator without rebuilding.
Core ArchitectureLive Two-Panel Wizards
Every campaign builder shows a live device preview on the right as operators configure settings on the left — real-time confidence, no test sends.
Signature PatternAG Grid Enterprise Tables
Guest data tables with virtual scrolling, custom cell renderers, multi-column sort, and bulk selection — thousands of records.
Data Density10 Integrated Modules
WiFi, Blast Campaign, Auto Responders, Loyalty, Reputation, POS, Signage, Scheduling, SMS Chat, and Tools — all sharing one guest data layer.
Platform ScaleDesign System
Tokens, typography & components
A shared token-based system built to ensure consistency across every screen and state.
Color Tokens
Type Scale
Components
User Flow
Core operator workflow
Configure, campaign, and track — all without leaving the dashboard.
Operator Login
SSO / Auth
Hub Dashboard
10 modules
WiFi Module
Hotspot config
Blast Campaign
SMS + Email
Loyalty Setup
Stamps + rewards
Tech Stack
Tools & technologies
Design & Prototyping
Frontend
React 18
TypeScript
Apollo Client
MUI v5
Redux ToolkitMy Contribution
End-to-end ownership
01
Sole Principal Designer
Complete design system, 5 surface types, and all 253 screens — from token architecture through high-fidelity production Figma.
02
Primary Frontend Developer
Built 3 React 18 + TypeScript repositories. DnD builders, AG Grid tables, runtime token provider.
Impact & Performance
Project at a glance
253
Screens designed
10+
Modules delivered
3
Repositories built
5
Design surfaces
Timeline
How 6–7 months unfolded
Month 1
Discovery + Design System
Platform audit, operator interviews, token architecture, 80+ component library in Figma.
Month 2–3
Admin Dashboard + WiFi Module
253 screens designed across 10 modules. WiFi module (Repo 3) built in parallel.
Month 4–7
Engineering + Multi-Surface
React implementation across 3 repos. Campaign builders with live-preview, loyalty kiosk, splash pages, email/SMS templates.
Outcomes
The impact we shipped
Measured results from usability testing, stakeholder reviews, and post-launch adoption tracking.
253
Screens designed
10
Modules delivered
3
Repositories built
6–7 Months
Engagement
"Delivered a production-grade white-label SaaS platform to major engineering milestone — 253 screens across 10 modules, 3 repositories, with a design system requiring zero redesign to onboard a new operator brand."
Learnings & Reflection
What I'd do differently
01
Token systems before screens
Jumping to screens before finalising the token architecture caused 3 rounds of rework when white-label requirements evolved. Token-first is not optional for multi-tenant products.
02
DnD library selection is non-trivial
Three DnD libraries coexisting created real engineering complexity. Earlier prototyping of each builder's interaction model would have clarified library selection before the scaffold was written.
Interested in working together?
Let's talk about your project or open role.
Live Prototype