White-label food tech
SaaS for restaurants

Year: 2026 Role: UX/UI Designer Team: Project manager, frontend developer, backend developer, mobile developer
Figma
Design system
Mobile
Web

A white-label platform that helps restaurants launch branded delivery apps. I built a token-based design system and resolved key UX edge cases — cutting client onboarding from 2 hours to 20 minutes and bringing consistency across all white-label variants.

Desktop version
iPhone version

Problem

Preparing a client-ready layout took around 2 hours. Critical flows — address lookup, order contact, cart actions — had unresolved edge cases that caused drop-off at conversion.

Focus

  • Build a token-based component system to make white-label delivery consistent and scalable
  • Resolve edge cases in ordering flows that caused drop-off
  • Reduce manual rework so the team could ship improvements faster

Reducing time-to-launch

Without shared tokens or reusable components, every new client build started from scratch. I standardized the component library and introduced a token system for brand colors, spacing, and typography.

Components
UI Kit

Working closely with developers, we defined a minimal, essential set of tokens to keep the system lightweight yet flexible enough for scaling and custom client branding. We used Material UI's token architecture as our foundation.

Design Tokens

This brought consistency across client apps and cut layout preparation time from ~2 hours to ~20 minutes.

Consistency - Menu Consistency - Item card Consistency - Cart

Address fallback

The map had known limitations, but there was no fallback — users who couldn't find their address hit a dead end and dropped off. A manual pin option already existed in the system but wasn't surfaced. I added a clear entry point with guidance, turning a dead-end into a recoverable state. Affected an estimated <1% of orders (per PM estimate) — small in volume, but a real, previously unaddressed drop-off point.

Address Search edge case 1 Address Search edge case 2

Fixing misrouted support requests

The contact screen placed restaurant and platform support at equal weight, so users regularly contacted the wrong party — creating noise for support and frustration for customers. I separated the flows: restaurant contact became the primary action, platform support moved to a secondary screen. Support stopped flagging this as an issue after the change.

Before Contact options - Before
After Contact options - After

Integrating a custom feature

A client requested a "like" feature, but the card already had "favorites" — two semantically similar icons in limited space risked confusing users and competing with "add to cart". I reworked the icon semantics to differentiate the two actions clearly and explored placements that kept the primary CTA dominant. The feature shipped without disrupting the ordering flow.

Before After
Item card with likes and favorites

Outcome

Building a shared foundation changed how the team worked. Client onboarding became faster, UI stayed consistent across apps, and the team had bandwidth to address real product problems instead of rebuilding layouts.

20 min

Reduced branded app setup from ~2 hours to ~20 minutes.

Shared tokens

Made brand customization predictable across client apps.

Consistent UI across clients

Each white-label variant shared the same token foundation, reducing visual drift between apps