I'm a Computer Engineering student in Ahmedabad, and I'm building Nirvaan Tech, my own software company.

Our first product is RestaurantOS, a restaurant operations system that connects the owner, waiter, kitchen and cashier in one workflow.

The hardest part wasn't the UI. It was deciding who is allowed to change what, and when.

Start with the flow, not the screens

One order in a restaurant touches four people:

Table → Order → Kitchen → Serve → Billing → Payment → Reports

Each role sees the same order differently and can only change it in a way that fits their job. If every role gets its own copy of the data, they will eventually disagree about what's happening.

So the design rule I followed: one order, one status, many views.

Model the order as states

Instead of building four separate dashboards, I treat the order as a state machine. Each role can only move it forward in the way its job allows.

A simplified version of the idea:

const transitions = { placed: { by: "waiter", next: "preparing" }, preparing: { by: "kitchen", next: "ready" }, ready: { by: "waiter", next: "served" }, served: { by: "cashier", next: "billed" }, billed: { by: "cashier", next: "paid" }, };

Now the rules live in one place:

  • The kitchen can't mark an order as paid.
  • The cashier can't skip the kitchen.
  • The owner sees everything without disturbing the flow.
  • Reports are just a read of what already happened.

4 lessons for multi-role software

  1. Trace one real transaction through every role before designing any screen.
  2. Make state changes explicit. If anyone can edit anything, bugs become untraceable.
  3. Permissions belong to actions, not pages. Hiding a button is not security.
  4. Clean states make reporting simple. Reports become a query, not a separate system.

What I'm still learning

I'm a first-time founder, and I don't think this approach is perfect. I'd like to hear where it breaks.

Question for you

If you've built software where several roles share one workflow (restaurants, hospitals, logistics, anything):

Did you model it as states and transitions, or did you end up with a different approach? What would you change in the design above?

I'm building this in public at Nirvaan Tech. The comments are open, and I'll reply to every one.