Nobody was slow. Everybody was free at the same moment. — A case study
A counter becomes something you can read before you reach it.
Before
You joined the queue to find out what was on it. What had sold out was discoverable only at the front, which is the worst possible moment, and whether an item was suitable — vegetarian, halal, free of a particular nut — was a question you asked a busy person over a counter, in a language that might not be either of yours, with a line behind you.
Now
The menu is live before you go: what is on today, what has already gone, and what is safe for you. Dietary and allergen requirements are set once on the profile and filter the menu itself, so an item that does not suit you is never offered rather than being something you have to check every time.
- Today's menu published by the kitchen, with items removed as they sell out
- Dietary and allergen needs held on the profile, not retyped per order
- The menu filters itself; unsuitable items are not shown at all
- Read in advance, from anywhere, in your own time
An order becomes a time the kitchen can keep.
Before
The naive version of this product makes everything worse. Let every student pre-order for the moment the lecture ends and you have not removed the queue — you have moved it into the kitchen, where it is invisible, unmanaged, and where the student is now standing at a counter holding a confirmation for food nobody has started.
Now
Collection times are offered from a model of what the kitchen can actually produce: prep time per item against the staff on shift. If a slot is full it is not offered. The app never shows a time it has not reserved, which is the only thing that makes the promise worth anything — and because the timetable is known, the breaks can be provisioned for before they arrive.
- Slots derived from real kitchen throughput, not from a fixed grid
- The timetable read as a demand curve, so peaks are provisioned in advance
- A full slot is never offered; the next honest time is offered instead
- Capacity split with the walk-up counter rather than taken from it
A time becomes a collection, not a second queue.
Before
Collection is where most order-ahead systems quietly reintroduce the thing they removed. Everyone arrives at once for orders that are all ready at once, names are called across a hall nobody can hear in, and the pickup point becomes the queue with an extra step in front of it.
Now
Slots are staggered, so arrivals are spread across the break rather than stacked on the start of it. The order's state is the same document on both sides of the counter, so the student is told when it is genuinely ready, and collection is a short code on a screen — nothing to spell, mispronounce or shout.
- Staggered slots spread arrivals across the break
- One order record, read live by the student and the kitchen alike
- Notified when it is actually ready, not when it was ordered
- Collected against a code, with no name called across the hall
A university cafeteria does not have a throughput problem, it has a synchronisation problem. The timetable releases every student at once, so demand arrives as a spike no amount of staffing can flatten, and the queue eats the break it was supposed to fit inside. We built the ordering app that moved the wait off the students' time — with collection slots derived from what the kitchen can actually produce, so a promised time is a time that holds.
The obvious reading of a long cafeteria queue is that the kitchen is too slow, and it is almost always wrong. The kitchen is fine for most of the day. What it cannot absorb is the moment a timetable ends four hundred lectures simultaneously and every one of those students walks toward the same counter inside the same minute.
That distinction matters because it rules out the obvious fixes. Another till, another staff member, a faster process — all of them raise average throughput, and none of them touch a peak that is instantaneous by construction. The constraint is not capacity per hour. It is that the demand has no width.
For the student the cost is that the queue and the break are the same event. Eat or be on time; and because that choice repeats every day, plenty of them stopped eating rather than start being late. For an international campus there was a second cost sitting underneath it — working out which items were safe to eat, on dietary or religious grounds, is not something you can do while shuffling forward in a line, in a second language, under time pressure.
So the work was to give the demand some width. Ordering happens ahead of the break, from wherever the student is, and collection is scheduled into a slot the kitchen has actually reserved. The queue does not get faster; it stops being a queue.
The decisions
What was chosen, why it was chosen, and what it cost.
Collection slots are derived from kitchen capacity, never from a fixed grid.
A grid of times is a promise the kitchen never made. Offer a slot the kitchen cannot hit and the product dies the first time a student misses the start of a lecture standing next to their untouched order — because they will not use it again, and they will tell people why.
The cost: It only works if the throughput numbers are honest, which makes the kitchen a maintainer of the system rather than just a user of it. Prep times have to be kept current, and the app is only ever as truthful as the data it is given.
The timetable is treated as a demand curve, because it is one.
A normal restaurant discovers its peak. A campus is told its peak months in advance — demand is a published document. That turns capacity planning from a forecasting problem into a lookup, and lets the breaks be provisioned before anyone orders.
The cost: The model is confidently wrong outside term time. Exam periods, reading weeks and holidays break the assumption completely, so the kitchen needs a manual override — and a system that is usually right needs that override to be easy to reach, or nobody uses it in time.
Pre-orders do not preempt the walk-up counter. Capacity is split.
If the app always wins, everyone who did not use it — no smartphone, no data, first week on campus, simply preferred not to — waits longer than they did before. A product that fixes the queue by moving its cost onto the students least able to absorb it has not fixed anything.
The cost: The app is deliberately allocated less capacity than the kitchen could give it, so it sells out sooner than it needs to. That is the product choosing to underuse its own advantage, and it has to be explained to a client who can see the unsold slots.
Dietary and allergen needs filter the menu. They are not a note on the order.
On an international campus this is most of the cognitive load of eating, and a free-text box asking a kitchen to remember something during a rush is not a safety mechanism. Structuring it means the unsafe item is never offered in the first place, which is the only version that fails safe.
The cost: It obliges the kitchen to maintain structured ingredient data for every item, every day — real, recurring work — and it turns the app into a safety claim the university now has to keep. Being explicit about that during the build was better than discovering it after launch.
The order document is the shared state. Neither side polls the other.
The student and the kitchen need to be looking at the same thing at the same moment, and the difference between 'ordered' and 'actually ready' is the entire value of the notification. A live listener on one record is the simplest mechanism that makes both true.
The cost: The data has to be shaped for reading rather than for storing, so it is denormalised and some facts are written in more than one place. The security rules also become the authorisation model, and those are easy to get subtly, silently wrong.
Collection is by code, not by name.
On a campus with students from everywhere, names get mispronounced, misheard and misspelled, and calling them across a loud hall is slow for staff and singling-out for the student. A short code on a screen is faster and asks nobody to say anything.
The cost: It needs a fallback for a phone that is dead, lost or out of battery, and that fallback is a manual lookup by a member of staff — which is exactly the slow, name-based interaction the code exists to avoid. Rare by design, but it had to exist.
Ordering tolerates a bad connection; the slot is confirmed by the server.
The app is used from lecture theatres, basements and buildings where campus wifi is a rumour. An order composed on a weak connection should not be lost, and a student should not have to find signal to eat.
The cost: An order that syncs late may find its slot taken, so 'confirmed' has to mean confirmed by the server and the app has to handle losing a slot gracefully rather than pretending. A cheerful confirmation the server never agreed to is worse than a slow one.
A design system before screens, on a project that did not obviously need one.
The app is used by thousands of people, in a hurry, in a second language, on a spread of devices from flagships to whatever was cheap three years ago. Under those conditions consistency and touch target size do more work than any individual screen's cleverness — and the university's own brand had to survive contact with it.
The cost: It is slower to a first demo, and up-front investment in components is the least persuasive thing to show a client in week two. It pays back at the third screen and not before.
Built on
- Firebase
- Orders, menus, slots and the live listeners that keep both sides in step.
- Mobile app
- The student-facing ordering, profile and collection experience.
- Design system
- Components, type and touch targets — a deliverable in its own right, not a by-product.
- Push notifications
- Told when it is ready, rather than watching a screen.
Talks to
- Push notifications
- Kitchen display
- Campus payment
What changed
- The wait moves off the break and onto time the student was spending anyway
- A collection time is one the kitchen has reserved, not one a grid invented
- Peaks are provisioned from the timetable instead of discovered at the counter
- Unsuitable items are never shown, rather than checked at the counter each time
- Sold-out items disappear before the walk rather than at the front of the queue
- Collection is a code on a screen, with no name called across the hall
- Walk-up customers are not made to wait longer to make the app faster
- One design system across the app, carrying the university's own brand
A queue is rarely a speed problem.
Most of them are a timing problem wearing a speed problem's clothes, and the fix is to give the demand somewhere to spread rather than to make the service faster. If something in your operation goes from idle to impossible and back inside the same hour, describe it — and you leave the first conversation with a scope, a budget and a ship date.