The problem
Restaurant staff juggle orders, tables, stock and billing across separate tools, and every role (chef, waiter, cashier) needs a different view of the same data.
My approach
DineFlow is one workspace where the UI changes based on who's logged in. Each role only sees the modules it needs, and owners and super admins see everything including the money side.
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 decides which modules render
- Workspace4
Dynamic [slug] routes
A dashboard per restaurant
- Insights5
Recharts
Revenue over 7 days, 30 days and 12 months
Role-based access
Six roles with a typed permission map, so a wrong role setup fails at compile time.
Live floor view
Tables marked as occupied, reserved, cleaning or available.
Order pipeline
Dine-in, pickup and delivery orders tracked from preparing to completed.
SaaS billing
Starter / Pro / Enterprise plans and a subscriptions page for the super admin.
Challenges & decisions
One UI, six kinds of users
Put all the permissions in one typed map instead of sprinkling role checks through the components.
Lots of data on screen
Used shadcn/ui for a consistent set of components so busy screens are still easy to read.
More screens
Tech stack
- Next.js 16
- React 19
- TypeScript
- Tailwind CSS
- shadcn/ui
- Recharts
What I learned
- →Modelling RBAC with TypeScript types
- →Organising a large App Router project with shared layouts
- →Designing dashboards around how restaurants actually work