The cafe ordering project

Why QR ordering was everywhere and then wasn't

In 2020 and 2021, QR code ordering appeared in nearly every cafe and restaurant that survived. By 2023 a large share of them had taken the table tents away and gone back to counters and menus.

The usual explanation is that it was a pandemic measure and the pandemic ended. I do not think that is the whole story, and the more interesting explanation is the one this project ran into: QR ordering solves a problem most cafes do not have, while creating several they do not want. It reduces the time a customer spends waiting to order. It does not increase how many coffees get made per hour, it removes the conversation where a barista sells a pastry, and it hands the staff a new device to monitor during the exact ninety minutes they have no attention to spare.

Status: design and research project. Not confirmed as deployed. Three days of on-site observation happened. An interface and service model were designed. There is a pos-prototype repository in my archive from March 2026 that is plausibly this project's implementation, and I cannot confirm that link, so I treat it as unproven throughout this document.

Four outcome figures previously published about this project, covering repeat orders, queue time, average order value and staff time recovered, are excluded here. Section 13 explains why.

---

01 · Context

A small independent cafe. One espresso machine, a small team, and a demand curve that is not remotely flat: the day's revenue is concentrated into a morning window, and the rest of the day is comparatively quiet.

I spent three days there. Not interviewing, shadowing. Standing where I could see both the counter and the machine, mapping the floor plan, and timing the queue through the eight-to-ten peak.

That is a modest research method and it is the most useful research in this entire archive, because operations problems are visible and nobody had watched. The staff knew the mornings were bad. They did not have a description of why they were bad that pointed at anything actionable, because when you are inside the rush you experience it as undifferentiated pressure.

What the three days produced was not a solution. It was a bottleneck.

02 · Problem

The stated problem was the queue. During the peak the line reaches the door, some people leave, and the ones who stay are unhappy. That is what the owner wanted fixed and it is a real business problem: a customer who walks away at 8:40 is lost revenue and possibly a lost regular.

The observed problem was narrower and more interesting. The queue is not one wait, it is three, and they behave differently:

1. Waiting to reach the counter
2. Ordering and paying at the counter
3. Waiting for the drink to be made

Only the second is a transaction. The first is a consequence of the second and third. And the third is governed by the espresso machine and the person operating it, which no software touches.

A second observed problem, which the owner had not raised. Order taking and drink making compete for the same person. In a small cafe the barista is often both cashier and operator, so every interaction at the till is time the machine is not being worked. That is not a queue problem, it is a resource contention problem, and it is the one worth solving.

A third: table service does not exist during the peak. Nobody has time to bring anything anywhere. Customers order, wait, collect. Any design that assumes a server visiting a table is designing for the wrong ninety minutes.

And the problem that makes cafe ordering software hard commercially: the pastry. Coffee margin is thin. Attach rate is where the money is, and attach happens because a person asks. A screen does not ask in the same way, and a cafe that adopts self-ordering and loses attach rate has traded revenue for throughput it may not even gain.

03 · Why the problem mattered

Because the peak is where the business lives. Improving the quiet afternoon is worth almost nothing. Everything that matters happens in the compressed window, and that concentration is what makes small improvements valuable and large redesigns dangerous.

Because queueing behaves non-linearly and this is not intuitive. When a service system runs close to capacity, waiting time does not rise in proportion to demand, it rises much faster. Kingman's approximation for queue waiting time is driven by a factor of utilisation over one minus utilisation, which means the difference between running at eighty percent of capacity and ninety percent is roughly a doubling of expected wait, for a ten percent change in load. The practical consequence for a cafe is important and counter-intuitive: during a peak, small reductions in per-customer service time produce disproportionately large reductions in queue length. Ten seconds saved per order is not ten seconds of benefit, because the system is operating in the steep part of the curve.

Because walk-aways are invisible in the till data. The cafe's numbers show what was sold. They do not show the person who looked at the line and kept walking, and that person may be the marginal customer whose behaviour determines whether the morning is good.

And because staff experience is not a soft concern in hospitality. A stressful peak produces mistakes, worse service and turnover. Turnover in a small cafe with one machine is genuinely expensive, because competence at that machine takes weeks to build.

04 · Research

Method: three days of on-site observation. Shadowing baristas, mapping the floor plan, and timing the queue during the eight-to-ten peak. No customer interviews, no survey, no A/B test.

What shadowing showed that timing did not. The order in which a barista does things during a rush is not the order printed on the tickets. They batch: all the milk steaming together, all the espresso pulls together, similar drinks combined. That is a rational efficiency behaviour and it means the queue is not first-in-first-out at the machine even when it is at the counter. Any software that assumes strict sequencing fights the operator's own optimisation.

What floor-plan mapping showed. The physical path of the queue and where it collides with people waiting to collect, and with people trying to leave. Some of the observed congestion was spatial rather than temporal, which is a category of problem no app addresses.

What queue timing showed. Where the time actually went inside a transaction: choosing, ordering, paying, and then waiting. Choosing was frequently the longest part for anyone who was not a regular, which is a finding with a design consequence, because it means the menu is a throughput component.

What I did not do, and it matters. No before-and-after measurement, because nothing was deployed under measurement. No customer research, so the entire assumption that customers wanted to order from their phones is untested, and that is precisely the assumption the mass abandonment of QR ordering in the wider industry casts doubt on. No staff interviews as such, though three days of proximity produced a reasonably clear picture of what they thought of new devices.

05 · Insights

The constraint is the machine, not the till. This is the central finding and it reframes the whole project. Goldratt's basic point about constraints is that improvements anywhere other than the bottleneck do not increase throughput. If the espresso machine and its operator set the ceiling, then eliminating the ordering step does not produce more coffees per hour. It produces a shorter line of people waiting the same total time, differently distributed.

That is not nothing. Perceived wait is a real quality attribute and a customer seated with an order placed is happier than the same customer standing in a line. But it is a different claim from "faster", and conflating the two is how self-ordering gets oversold.

Where self-ordering genuinely does raise throughput: when order taking competes with production. In this cafe the same person often did both. Every till interaction is a pause at the machine. Removing order taking from that person's responsibilities returns their attention to the bottleneck, and that is a real throughput gain. So the value of the system is not that customers order faster. It is that the barista stops being interrupted. That distinction determines whether the product is worth anything, and it is entirely dependent on the staffing model.

Choosing is part of service time, so the menu is an operational component. For non-regulars, deciding took longer than ordering. A menu structured for fast decisions, with a small number of obvious defaults, does more for the peak than a faster payment flow.

Account creation is where mobile ordering dies. This is well established outside hospitality: forced account creation is consistently among the leading causes of checkout abandonment in Baymard Institute's checkout research. In a cafe the tolerance is far lower than in ecommerce, because the purchase is three pounds and the customer is standing up. Anything that asks a person to make an account before their first coffee has lost. Apple Pay and Google Pay with no account at all is not a convenience feature here, it is the entire viability of the concept.

Regulars do not want this and should not be forced into it. A regular's order is a five-second exchange, often wordless, and it is part of why they come. Replacing that with a phone is a downgrade of the product for the most valuable customer segment. Any honest version of this system is additive and optional.

Staff will not accept a new screen to monitor unless it removes work. A kitchen display that shows orders is another thing to watch during the worst ninety minutes of the day. It is only accepted if it visibly replaces something, and it competes with a system baristas already trust: a row of cups on the counter, marked.

06 · Product thinking

What this product actually is, correctly stated: a way to remove order taking from the person operating the machine during a ninety-minute window. Not a digital menu. Not a modernisation. One operational effect, in one time window, and its value is entirely conditional on the cafe's staffing model.

The scope that follows. QR at the table and at the queue. A menu built for fast decisions. Account-free payment. A display for the barista that sequences and batches. Nothing else. No loyalty programme, no reservations, no marketing, no CRM, because each of those adds surface to a product whose whole justification is removing load during a rush.

Why the segmentation matters more than the features. Three customer types with different needs: the regular who wants the five-second exchange and should keep it, the occasional customer who wants speed and will scan, and the sit-down customer who wants to linger and for whom ordering from the table is genuinely better. One system, three intents, and a design that forces all three down one path will fail for at least two of them.

Where the earlier version of this project overreached. It presented outcomes as though the system had run in production under measurement. Reading my own case study now, it never actually says the system was deployed, which is a tell. A project that has real observational research behind it does not need borrowed outcomes, and the four figures actively undermine the part that is genuinely good.

The tradeoff I would put in front of an owner honestly. You may gain throughput if your barista is currently doing both jobs. You will probably lose some attach rate. You will need to keep the counter open for regulars. If your bottleneck is the machine and your staffing already separates till from production, this system will make your queue shorter and your revenue flat.

07 · Strategy

Additive, never replacing. The counter stays. QR ordering is offered, not imposed. This is the single most important strategic decision, and getting it wrong is the most common way hospitality technology fails: it optimises for the operator's efficiency and degrades the regular's experience.

Design for the peak and ignore the rest of the day. Every decision is evaluated against the eight-to-ten window. A feature that is pleasant at two in the afternoon and adds a step at half past eight is a net negative.

Zero-account checkout as a hard requirement. Apple Pay and Google Pay, no registration, no email, no app. The moment this needs a download it is dead, which means it is a web product, not an app product, and that decision is forced rather than chosen.

Respect the batching behaviour instead of overriding it. The barista display groups similar drinks rather than enforcing arrival order, because that is what the operator already does and a system that fights the operator gets ignored.

Preserve attach explicitly. If the pastry conversation disappears, the digital flow has to do that work: one well-placed prompt at the right moment, not an upsell carousel. This is the commercial hinge of the whole system and it deserved more design attention than I gave it.

08 · Information architecture

The customer path:

Scan                    table tent, or a card in the queue
  ↓                     no app, no account, no login
Menu                    small, decision-optimised, defaults visible
  Item
    Options             minimal: size, milk, one modifier
  ↓
Add                     running total always visible
  ↓
One prompt              the attach moment, once, skippable
  ↓
Pay                     Apple Pay / Google Pay, single gesture
  ↓
Status                  order number, position, collect-at-counter

The barista path:

Queue                   incoming orders
  Grouped by drink type not strictly by arrival time
  Order card            items, table or collection, elapsed time
  ↓
Mark ready              triggers customer status change

Two decisions worth defending.

No account, anywhere in the flow. Not optional-with-a-prompt. Absent. Every account prompt in a three-pound transaction is a place to abandon, and the loyalty benefit that would justify it is not worth the conversion cost at this order value.

Elapsed time on every order card, visible to the barista. Not a target, not an alarm. Just the number, because in a rush the operator's own sense of how long something has been waiting is unreliable, and the one piece of information a display can add that a row of marked cups cannot is duration.

09 · UX and design

No interface artifacts from this project are published. This section is the design reasoning.

The menu is the throughput surface. If choosing is the longest part of service time for non-regulars, the menu's job is to make deciding fast rather than to display the range. That means a short list, the popular items first, a visible default for the common configuration, and options collapsed to the two or three that actually vary. A cafe with forty items on a phone screen has built a browsing experience for someone who is standing up in a queue.

Cognitive load in the worst possible conditions. The user is standing, possibly holding something, in a noisy room, in a hurry, on a phone in one hand. Sweller's distinction between intrinsic and extraneous load is directly useful: the intrinsic task is choosing a drink, and every other decision the interface introduces is extraneous. One-handed reach, large targets, no horizontal scrolling, no multi-step configuration.

Payment as a single gesture. Apple Pay and Google Pay compress the highest-friction moment in the flow into one authentication. Any card form here is a failure, because manual card entry standing in a cafe is slower than paying at the counter, which means the product has lost to the thing it was replacing.

Status is the trust surface. After paying, the customer's question is immediate and singular: does anyone know I ordered. An order number and a clear place to collect answers it. Ambiguity here sends the customer to the counter to ask, which restores exactly the interruption the system existed to remove.

The barista display, designed against a system that already works. A row of marked cups is fast, glanceable, physical and trusted. A screen replacing it must be readable from two metres, in one glance, with wet hands and no touch interaction beyond one large action. High contrast, large type, minimal chrome, no scrolling during a rush.

Accessibility, which QR ordering routinely fails. A phone-only ordering path excludes people without a smartphone, with visual impairments, or unfamiliar with the pattern. This is one more reason the counter stays open, and it is the strongest argument for the additive model that has nothing to do with commerce.

Error and empty states. Item unavailable must be visible before it is chosen, not discovered at payment. Payment failure needs an immediate fallback to the counter. A dead QR code, a wet table tent, a phone with no data: all of these end at the same place, which is a person and a till, and that is the correct fallback rather than a failure.

10 · Technology

I cannot confirm what was built. There is a pos-prototype repository in TypeScript from 12 March 2026 in my archive. It has no description. It is plausibly this project and I will not assert it, because the whole premise of this archive is that unverified links stay unverified.

What the design requires technically, stated as requirements rather than as an implementation:

Web, not native. No download can stand between a person in a queue and a coffee. That constrains everything to a mobile web application and makes fast first load the dominant technical requirement, since the page is being fetched on cafe wifi or patchy mobile data by someone who will not wait.

Payment via the Payment Request API. This is the browser mechanism that surfaces Apple Pay and Google Pay from a web page, which is what makes account-free single-gesture payment possible without an app. It is the technical fact that makes the entire product concept viable, and without it the flow reverts to a card form and dies.

Real-time order state. The barista display and the customer status view need to agree within a second or two. A short-polling or push channel, and honest handling of disconnection on both sides, because a display that has silently stopped updating during a rush is worse than no display.

Offline tolerance. Cafe wifi fails. A barista display that goes blank when the connection drops loses orders and trust simultaneously. The requirement is that the display holds last-known state visibly and says it is stale, which is the same three-state honesty problem that shows up everywhere in this archive.

Menu availability as first-class state. Sold out has to propagate immediately. A customer who pays for something that ran out has had a worse experience than if they had queued.

11 · Marketing and GTM

Not marketing in the usual sense. Adoption inside one venue, which is its own discipline.

The customer-facing adoption problem. A table tent is a weak call to action competing with a queue people already know how to use. Adoption requires the signage to state the benefit rather than the mechanism: not "scan to order" but something that tells a person standing in a line that they can skip it.

The staff-facing adoption problem, which is the harder one. New systems in hospitality are frequently defeated by the staff, and reasonably so, because they are usually imposed by someone who will not be working the rush. The display had to be understood in one shift and had to visibly remove work. Any system that requires training during a peak will be switched off during a peak.

The owner-facing case. Honest version: this may shorten your queue, it will change your attach rate, and its throughput benefit depends on whether your barista is currently taking orders. That is a less exciting pitch than a percentage and it is the one that survives contact with a month of operation.

Removed from this section. Four figures covering repeat order rate, queue time reduction, average order value increase and staff time recovered. See section 13.

12 · Execution

What was done:

• Three days of on-site observation: barista shadowing, floor-plan mapping, queue timing through the eight-to-ten peak
• A service model designed around table-tent and in-queue QR entry
• A mobile-web menu designed for decision speed
• Account-free checkout via Apple Pay and Google Pay
• A barista-facing display with grouping and elapsed time

What is unconfirmed:

• Whether any of it was implemented, and whether pos-prototype is that implementation
• Whether it was ever used in the venue

What was not done:

• Customer research
• Before-and-after measurement
• Any deployment I can evidence

13 · Results

No outcome metrics exist for this project. Nothing was measured, and I cannot confirm the system ran in the venue. What exists is the observational research and the service design.

Removed and recorded:

Previously claimed	Why it is not here
60% repeat order rate	No dataset. No confirmation the system was in production to generate one.
Queue time reduced 40%	No before-and-after timing under a deployed system. Baseline timings were taken; there is no post-deployment comparison.
Average order value up 15%	No till data. This is the attach-rate claim, and section 05 argues the effect may run the other way.
One barista freed during peak	A design intention, not an observed outcome.

What the project does have, and it is the best research in this archive: three days of direct observation that located a bottleneck the owner had not identified, a queueing argument for why small service-time savings matter disproportionately at peak, and a design that is honest about the conditions under which it would and would not help.

The fourth claim is the one I find most instructive. "One barista freed during peak" is exactly the right design goal for this system. Writing it as an achieved outcome converted the strongest idea in the project into its least credible sentence.

14 · What went wrong

I published outcomes for a system I cannot confirm was deployed. Four figures, including a repeat-order rate that would require months of production data. The case study never actually claimed deployment, which means the numbers were doing the implying. That is the worst kind of overstatement because it is deniable.

I did not do customer research at all. Three days watching operations and zero minutes asking customers whether they wanted to order from their phones. And the wider industry evidence is that many do not, given how widely QR ordering was adopted and then withdrawn. The one assumption the entire product rests on is the one I never tested.

I baselined but never re-measured. Queue timings were taken during observation. That is half of a study. Without a post-deployment comparison the baseline is just a description, and the effort of collecting it is largely wasted.

I designed the attach moment carelessly. Attach rate is where cafe margin lives, and my design gives it one prompt and a paragraph of thought. If self-ordering costs the pastry conversation, the system can shorten the queue and reduce revenue, and I did not take that risk seriously enough in the design.

I did not resolve whether it shipped, and I have left it unresolvable. No deployment record, no photograph, no owner confirmation, and an undescribed repository that may or may not be it. A day of documentation at the time would have preserved the whole thing.

I solved the problem I was asked about instead of the one I found. The queue was the brief. Resource contention at the machine was the finding. I designed a queue product and buried the more valuable insight in the middle of it.

15 · What I learned

Find the constraint before designing anything. Improvements away from the bottleneck do not increase throughput. This is the most portable idea in this case study and it applies to software systems as directly as to espresso machines.

Utilisation is why peaks feel disproportionate, and it is why they are worth attacking. Near capacity, waiting time rises far faster than load. Ten seconds per order is worth more than it sounds, and only during the peak.

Observation beats interviews for operational problems. Nobody in that cafe could have described the batching behaviour to me, because it is automatic. Three days of watching produced findings no conversation would have.

Account creation is fatal at low order values. Every step before the first purchase costs more than it returns. In a three-pound transaction, one is too many.

Do not remove a human interaction that is part of the product. The five-second exchange with a regular is the cafe. Efficiency that erases it is a downgrade dressed as an upgrade.

Baseline measurements are only worth taking if you intend to re-measure. Otherwise you have collected numbers to no purpose, and worse, you have created figures that later look like evidence for something they never tested.

16 · What I would do differently

Ask twenty customers whether they would use it, over two mornings. The cheapest and most decisive research available, and the one thing I skipped. The industry's retreat from QR ordering suggests the answer is more mixed than my design assumed.

Test the staffing hypothesis directly, with no software at all. For one week, put a second person on the till during the peak and measure output. If throughput rises, order taking is a real constraint and the product has a basis. If it does not, the machine is the ceiling and no app helps. That is a week of labour cost against months of building, and it should have come first.

Design the attach moment as a first-class feature. One prompt, at the point where a barista would have asked, tested against the counter's baseline attach rate.

Measure after, or do not measure before. A defined comparison window, the same peak hours, the same metrics as the baseline.

Keep the counter open permanently and say so in the design rationale. Not a transitional accommodation. A permanent part of the system, for regulars and for accessibility.

Document deployment at the time. A photograph, a date, an owner's note. The reason this case study cannot state whether the work shipped is that nobody wrote it down, and that is a five-minute failure with permanent consequences.

17 · Current status

Research and design complete. Deployment unconfirmed. No measurement.

Item	Status
On-site observation	3 days: shadowing, floor mapping, peak queue timing
Service model	Designed: table-tent and in-queue QR, additive to the counter
Customer flow	Designed: decision-optimised menu, account-free Apple Pay / Google Pay checkout
Barista display	Designed: grouped orders, elapsed time
Customer research	None
Implementation	Unconfirmed. pos-prototype (TypeScript, 12 March 2026) is a possible but unverified link.
Deployment	Unconfirmed
Outcome metrics	None. Four previously published figures removed.

---

Related reading in this archive

• Why founders should care about activation before growth: friction before the first purchase
• Cognitive load is the real SaaS design problem: intrinsic versus extraneous load, and why a queue is the hardest context
• Designing under uncertainty: designing before the core assumption is tested
• TapQR: the other merchant-facing payments project, and the one that reached a price

Sources

1. devchopra.life /projects/cafe-brand: research method, project scope, and the four excluded outcome claims. https://devchopra.life/projects/cafe-brand
2. GitHub, TheDevChopra/pos-prototype: TypeScript, no description, pushed 12 March 2026. Link to this project unconfirmed. https://github.com/TheDevChopra?tab=repositories
3. J. F. C. Kingman, "The single server queue in heavy traffic", Mathematical Proceedings of the Cambridge Philosophical Society 57(4), 1961: the utilisation term that drives waiting time near capacity.
4. J. D. C. Little, "A Proof for the Queuing Formula: L = λW", Operations Research 9(3), 1961.
5. Eliyahu M. Goldratt, The Goal, North River Press, 1984: throughput is set by the constraint.
6. Baymard Institute, checkout usability research on account creation as a cause of abandonment. https://baymard.com/lists/cart-abandonment-rate
7. John Sweller, "Cognitive load during problem solving: Effects on learning", Cognitive Science 12(2), 1988.
8. W3C, Payment Request API specification: the browser mechanism behind Apple Pay and Google Pay on the web. https://www.w3.org/TR/payment-request/