Commercial · 2024 — 2025
RestroX
Multi-tenant restaurant management platform
Commercial product · private codebase
Overview
A multi-tenant restaurant management platform spanning three applications — Product Owner, Client Admin and customer-facing — inside a monorepo with a shared design system. I built frontend modules across all three, gradually taking ownership through sprint planning, code reviews and production releases.
The Problem
Restaurants juggle orders, tables, menus and payments across tools that don't talk to each other. RestroX needed one platform serving three very different audiences — platform operators, restaurant admins and diners — without building three separate products.
The Solution
A monorepo of three apps on a shared design system, so a diner's order, an admin's dashboard and the platform owner's controls all speak the same visual and data language. Real-time WebSocket features keep orders and operational notifications live across roles.
Architecture
- Monorepo with three deployable apps sharing one design system for cross-module UX consistency.
- Zustand for local UI state, React Query for server state — a deliberate split that kept caching predictable.
- Payment gateway integration wired into order workflows with real-time status updates.
Key Features
- Tenant-scoped admin dashboards for menus, tables and staff
- Live order tracking with WebSocket-driven notifications
- Integrated payment gateway workflows
- Shared component library across all three apps
Challenges
Three audiences, one design system
A component library serving a POS-style admin and a consumer app pulls in opposite directions. We kept primitives unopinionated and moved opinion into app-level composition.
Server-state consistency across live updates
WebSocket events and React Query caches can disagree. Events were funneled through cache invalidation rather than direct state writes, keeping one source of truth.
Performance
- React Query caching tuned per-resource to cut redundant fetches in high-frequency order views.
- Route-level code splitting keeps the customer app lean — it never pays for admin code.
Lessons Learned
In multi-tenant systems, the data model is the product. UI mistakes are cheap to fix; tenancy mistakes are not.
Owning modules end-to-end — planning to production — taught me more than any amount of ticket work.
Next case study
Simple Patro