THAL.E / CONSUMER 0 → 1

Two queues, one app.

Consumer 0→1 as founding product lead. Food ordering and queue management across 3 campus canteens: 1,000+ DAU and 2,000+ monthly orders.

THE PROBLEM

Lunch at a campus canteen meant queueing to order, then queueing again to collect, with a class starting soon after.

MY CALL

Build ordering and queue management for 3 canteens at Christ University, and own it from research to post-launch metrics.

WHAT CHANGED

1,000+ daily active users and 2,000+ monthly orders.

Daily active users
1,000+
Monthly orders
2,000+
Campus canteens
3
Team members
20

Context

Venture
Thal.E, Bengaluru
My role
Founding product lead, owning the full lifecycle
Users
Students, and the canteen vendors serving them
Team
20 members
08 / TWO QUEUES, ONE APPStudentOrders by phoneOrder queueManaged sequenceCanteenPrepares in orderReadyCollectNO SECOND LINE AT THE COUNTER
08 / TWO QUEUES, ONE APPStudentOrders by phoneOrder queueManaged sequenceCanteenPrepares in orderReadyCollectNO SECOND LINE AT THE COUNTER
Conceptual ordering and queue flow between students and canteen staff.

The problem

At peak hours, students stood in one line to order and another to collect, often in a short gap between classes.

Canteen staff had no view of demand until it was standing at the counter.

Thal.E was built to fix both sides: ordering for students, queue management for canteens.

EVIDENCE
  • User research with students and canteen operators before building.
  • Queues were concentrated in short windows between classes.

Constraints & non-goals

Constraints

  • A 20-member team to coordinate on a student-venture budget.
  • Every canteen had to agree to run on the platform, so vendor partnerships came first.
  • Canteens could not change how their kitchens worked to fit the software.

Out of scope

  • Delivery beyond the canteen counter.
  • Building our own payments infrastructure.
  • Expanding off campus before three canteens worked well.

Options I weighed

  • NOT CHOSEN

    Pre-ordering only

    It removes the first queue and makes the second one worse if the kitchen cannot see when orders are due.

  • NOT CHOSEN

    Launch across several campuses at once

    It spreads a 20-person team too thin before the operations are proven.

  • CHOSEN

    Ordering plus queue management, starting with 3 canteens on one campus

    Both sides of the counter improve, and one campus is small enough to run operations closely.

The spec

spec / thale.mdThal.E

Users

  • Students ordering food.
  • Canteen vendors and their staff.

Requirements

  • Food ordering for students.
  • Queue management for canteens.
  • Order-ready status, so students collect when food is ready.

Acceptance criteria

  • A student can order and know when to collect without standing in line.
  • Canteen staff see incoming orders in the order they will be prepared.

Guardrails

  • Walk-in customers are still served. The app does not take over the counter.
  • Post-launch metrics tracked from launch.

What shipped

  1. Order

    A student orders from their phone.

  2. Queue

    The canteen sees orders in a managed queue.

  3. Prepare

    Staff prepare in sequence, with demand visible ahead of time.

  4. Collect

    The student collects when the order is ready.

What changed

Thal.E reached 1,000+ daily active users and 2,000+ monthly orders.

  • I managed vendor partnerships, operations and investor pitches alongside the product.
  • I owned the full lifecycle: research, roadmap, launch and post-launch metrics.

HONEST CAVEATFigures are from the three-canteen deployment at Christ University in 2023.

Reflection

My only consumer 0 → 1. Different users and constraints, same discipline: understand the work on both sides of the counter.

If I did it again, I would define daily active use more tightly. Checking queue status and placing an order are different kinds of engagement, and the metric should separate them.

Last updated · Company tenure is Thal.E · May–Dec 2023, not a claim about individual project dates.