# 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.

Company: Thal.E

Contribution: Founding Product Lead

Company tenure: Thal.E · May–Dec 2023. This is not a claim about individual project dates.

Context: 3 campus canteens · 20-member team

## TL;DR

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.

Outcome: 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

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

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

Rejected: Pre-ordering only It removes the first queue and makes the second one worse if the kitchen cannot see when orders are due.

Rejected: 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

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.

Figures 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.

The takeaway: Fix both sides of the counter, on one campus first.

Last updated: 2026-09-13