The problem
Restaurant teams juggle orders, tables, stock and billing across disconnected tools, and every role — from chef to cashier — needs a different view of the same operation.
My approach
DineFlow is a single workspace where the interface adapts to the signed-in role. Each role sees only the modules it needs, while owners and super admins get the full operational and financial picture.
How it's built
- Marketing1
Next.js App Router
Landing, features, pricing and about pages
- Auth2
Session + auth module
Sign-up, login and verification flow
- RBAC3
TypeScript role map
navigationByRole drives which modules render
- Workspace4
Dynamic [slug] routes
Per-restaurant, multi-tenant dashboard
- Insights5
Recharts
Revenue trends over 7 days, 30 days and 12 months
Role-based access
Six roles with a typed permission map — impossible states don't compile.
Live floor view
Tables with occupied, reserved, cleaning and available states.
Order pipeline
Dine-in, pickup and delivery orders tracked from preparing to completed.
SaaS billing
Tiered Starter / Pro / Enterprise plans and a super-admin subscriptions view.
Challenges & decisions
One UI, six audiences
Centralised permissions in a typed map instead of scattering role checks across components.
Dense data, calm interface
Built a consistent component system with shadcn/ui so busy screens stay readable during service.
More screens
Tech stack
- Next.js 16
- React 19
- TypeScript
- Tailwind CSS
- shadcn/ui
- Recharts
What I learned
- →Modelling RBAC in the type system
- →Structuring a large App Router project with shared layouts
- →Designing dashboards around real operational workflows