SaaS

Valley of Flavours: canteen ordering and operations SaaS

Turning a paper-based canteen into a digital ordering and operations system

The canteen looked simple from the outside: order at the counter, pay, collect, leave. Up close it was a surprisingly complex workflow running entirely on a paper register. I built a lightweight SaaS that connects the customer, the kitchen and the owner, and the client now pays for it every month.

Observe the workflow. Find the bottleneck. Build the system.
Project type
Canteen operations SaaS
Role
Product builder and full-stack developer
Timeline
Started as a personal experiment; ongoing, evolving product
Client
Valley of Flavours
Users
Customers and canteen operators
Stack and services
SupabasePostgreSQLOffline-first cachingQueued batch syncQR orderingKanban workflowRevenue dashboard
Valley of Flavours - SaaS
01

The problem

Once I watched the counter closely, I noticed what was really happening. Orders were written by hand into a register. Payments were sometimes forgotten. Customers kept crowding the counter asking "Bhaiya, mera order ready hua?" ("Is my order ready?").

The operator was juggling all of this at once:

  • incoming orders
  • handwritten records
  • payments
  • unpaid balances
  • kitchen status
  • customer questions
  • daily sales
Could the entire canteen operation be turned into a simple digital system?
02

The first observation

The biggest issue wasn't just ordering. Several connected problems were happening at the same time, on three sides of the counter.

Customer side

  • Stand in line
  • Order verbally
  • Remember the order
  • Return to the counter repeatedly
  • Ask for status updates

Counter side

  • Write every order by hand
  • Calculate totals
  • Track payments
  • Maintain unpaid balances
  • Relay to the kitchen
  • Answer status questions

Business side

  • No revenue tracking
  • No view of customer behaviour
  • No order-volume monitoring
  • No handle on recurring tasks
What I learned

The problem wasn't one broken feature. It was the entire workflow.

03

The idea

I decided to build a lightweight SaaS that connected the customer, the kitchen and the operator. Instead of replacing one manual step, the goal was to connect the whole workflow.

  1. Scan
  2. Order
  3. Track
  4. Prepare
  5. Pay
  6. Analyse
04

Designing the customer experience

I started at the counter. Rather than making customers download an app, I used a QR code as the entry point, something everyone already knows how to use.

  1. Scan QR
  2. Open digital menu
  3. Select items
  4. Enter name + phone
  5. Add special instructions
  6. Place order
The Valley of Flavours customer site, with menu, outlets, order tracking and cartOrder form with dine-in, delivery and pick-up options, special instructions and payment method
The customer site, and the order form: dine-in, delivery or pick-up, special instructions and payment method. Customer details blurred.
05

From order to kitchen

Once placed, an order appears automatically in the manager's dashboard. Instead of reading handwritten notes, the operator works from a structured digital queue. Each order carries:

  • customer name
  • phone number
  • selected items
  • special instructions
  • total amount
  • order status
06

The kitchen Kanban

One of the core interfaces is a Kanban-style kitchen board. The operator moves each order through its stages visually, and the board becomes a shared source of truth between the customer and the kitchen.

  1. New
  2. Preparing
  3. Ready
  4. Delivered
  5. Paid
Kitchen board with a prep list and New, Cooking and Ready-to-serve columns
The live kitchen board: a prep list on top, orders moving from New to Cooking to Ready to serve.
Everyone could see where an order was.
07

Customer order tracking and notifications

The same order state is exposed to the customer through a tracking link. Instead of walking back to the counter several times, they check the status, which removed a whole category of repetitive questions.

I added a notification layer on top, so a status change reaches the customer without another trip to the counter. The customer shouldn't have to remember to keep checking. It's a small interaction with a surprisingly large operational effect.

  1. Order received
  2. Being prepared
  3. Ready
  4. Delivered / completed
08

Payment and ledger

The next problem was money. In the old workflow some customers left without paying, and the operator noted the amount in a ledger by hand.

The software added structured payment tracking and a digital ledger that separates "order created" from "payment completed", giving the operator a clear view of outstanding balances instead of handwritten notes.

Printed tax invoice from Valley of Flavours showing items, total and payment status
Every order ends in a proper tax invoice with its payment status.
09

The scaling problem

The first version worked. Then real usage exposed a new problem. The menu carried a lot of data, and because this started as an experiment I had kept the setup deliberately low-cost on a free Supabase tier. As customer activity grew, the app generated a large number of database reads and writes. The architecture had to change.

Menu management screen with category switches and per-item price, special and availability toggles
Menu management: whole categories or single items switch on and off, which is a lot of data to keep in sync.
10

The offline-first shift

Instead of hitting the database for every small interaction, I added a caching and queueing layer and moved the app toward an offline-first approach: keep frequently used data close to the user, and synchronise changes intelligently instead of constantly querying the database.

Menu data is cached locally on both the customer's and the manager's device, and changes are queued and synced in batches. That cut unnecessary database traffic, made the system more resilient to patchy connectivity, and kept the product viable on low-cost infrastructure.

Before: every action hits the database

  1. Read
  2. Write
  3. Read
  4. Write
  5. Read
  6. Write

After: local first, batched sync

  1. Local action
  2. Queue
  3. Batch synchronisation
  4. Database
11

Revenue dashboard and customer insights

Once ordering and payment worked, the client asked: "How much business are we actually doing?" The system was already generating the data, so I turned it into a management dashboard with daily, weekly, monthly and yearly revenue.

Order history also surfaces recurring customers and buying patterns. "Who buys the most?" is now answered from real transactions, not guessed from a register.

That changed the product from order-management software into operational and business-intelligence software.
12

The unfinished idea: dinner opt-in

A cloud kitchen supplied meals at set times, and the operator had to collect the expected number of meals by hand. People sometimes forgot to opt in. I designed the next part of the product around that workflow:

The WhatsApp integration for this workflow was planned but not completed in the version I deployed. That distinction matters: I would rather document what shipped than claim what was only designed.

  1. Customer opens the app
  2. Selects dinner
  3. Participation recorded
  4. Total visible to operator
  5. Kitchen prepares the right quantity
13

Client collaboration

I wasn't building in isolation. I worked directly with the owner, and the loop became continuous product development driven by real use. Each question the client asked turned another manual process into a software workflow: can we have a ledger? track payments? see revenue? manage customers? know how many dinners are needed?

  1. Build
  2. Deploy
  3. Observe usage
  4. Collect feedback
  5. Identify the next problem
  6. Improve
  7. Repeat
14

From experiment to paid product

This started as an experiment, but it created enough value that the client began paying for it as a recurring monthly SaaS service, and became a recurring customer for continued development.

A real business was willing to pay to keep using software I built to solve its operational problems.
15

The complete system

Customer

  1. QR entry
  2. Digital menu
  3. Order
  4. Tracking
  5. Notifications

Kitchen

  1. Order queue
  2. Kanban workflow
  3. Preparation
  4. Completion

Business

  1. Payments
  2. Ledger
  3. Customer records
  4. Revenue dashboard
  5. Operational insights

Infrastructure

  1. Caching
  2. Local data
  3. Queued updates
  4. Batch sync
  5. Supabase
16

Before and after

Before: paper register

  1. Customer arrives
  2. Waits at the counter
  3. Orders verbally
  4. Operator writes the order
  5. Customer pays, or forgets
  6. Order enters a manual workflow
  7. Customer waits
  8. Customer asks for status
  9. Operator checks the register
  10. Customer collects food
  11. Revenue stays in handwritten records

After: connected workflow

  1. Scan QR
  2. Open menu
  3. Place order
  4. Digital order created
  5. Kitchen receives it
  6. Kanban workflow
  7. Customer tracks status
  8. Order completed
  9. Payment recorded
  10. Revenue appears in the dashboard
17

The real problems I solved

It started with one visible problem, manual ordering. Solving it revealed deeper ones:

  1. 1

    Manual order entry

    Replaced by a digital ordering interface.

  2. 2

    Counter congestion

    Reduced through QR ordering and order tracking.

  3. 3

    Order-status questions

    Answered by customer-facing tracking.

  4. 4

    Kitchen coordination

    Handled by a visual Kanban workflow.

  5. 5

    Forgotten payments

    Caught by structured payment tracking and a ledger.

  6. 6

    High database usage

    Cut with local caching, queued updates and batch synchronisation.

  7. 7

    Revenue visibility

    Provided by the reporting dashboard.

  8. 8

    Changing requirements

    Absorbed through continuous collaboration and iterative development.

18

What this project taught me

  1. 1

    Good software ideas come from ordinary places

    I didn't find this idea on a startup blog. I watched someone write "Chole Bhature - ₹10" in a register and asked: what if this entire page was software?

  2. 2

    Software should adapt to the workflow

    There was no perfect spec. Requirements emerged through use, so I built the core, watched the real workflow, and adapted the product around the business.

  3. 3

    Scaling isn't only about more servers

    I didn't fix the first performance problem with more infrastructure. I changed the application's behaviour: more work done locally, changes synced strategically.

  4. 4

    Product development is continuous

    There was never a single moment it was "finished". Every solution exposed the next problem, and that cycle became the process.

  5. 5

    A working product creates evidence

    This isn't a GitHub demo. A real business used it, a real operator gave feedback, a real client paid for it, and it kept evolving.

19

My role

I built this independently, alongside my full-time role as a research analyst at GreyB.

Problem discovery

  • Observing the canteen workflow
  • Identifying operational bottlenecks

Product design

  • Customer, kitchen and management workflows

Development and deployment

  • The application and its infrastructure
  • Hosting and maintaining the live system

Performance architecture

  • Caching
  • Local state
  • Queued synchronisation

Analytics

  • Revenue reporting
  • Customer insights

Client collaboration

  • Collecting feedback
  • Continuously adapting the product
20

Impact

  1. 1

    Operational

    Less dependence on handwritten order management.

  2. 2

    Customer experience

    Customers order and track food without repeated trips to the counter.

  3. 3

    Business visibility

    The operator has structured transaction and revenue data.

  4. 4

    Technical

    The system handles higher activity without constant database reads and writes.

  5. 5

    Commercial

    The experiment became a recurring paid SaaS relationship with the client.

Don't start by asking what technology to use. Start by asking where people are wasting time.

Have a similar problem? Let's talk.

Kartik Saxena - open to remote roles, contract work and new projects.

more web work