Why we opened a café to build a point-of-sale system

A point-of-sale system is judged during the worst stretch of a shift. The line reaches the door, a barista is covering the register, the kitchen is three tickets behind, and someone wants to split a check four ways. Whatever the software does in that moment is what the software is. The sales demo, the feature list and the onboarding call all describe a product that the person at the counter never actually meets.

That gap is the reason Atlético Café exists. Atlético is a specialty coffee and brunch spot in San Pedro Garza García, Monterrey, open every day from eight in the morning to eight at night. We run it at WAOF, a technology, product and creative studio that started in Monterrey, as a retail R&D lab. It is a real business with real customers. It is also, by design, where we build and test Nara, the point-of-sale system that runs its counter.

Distance is the default

Years of agency work for operators in retail, health, hospitality and institutions left us with a pattern we describe plainly in our thesis: software gets built too far from the people using it. Negligence rarely has anything to do with it. The people who write restaurant software usually sit in offices, and the feedback that reaches them arrives filtered through support tickets, account managers and roadmaps. By the time a complaint about a clumsy modifier flow reaches an engineer, it has become one line item competing with forty others.

The best-known counterexample is instructive. Toast, which went public in 2021 serving some 48,000 restaurant locations, began with a mobile app that let diners pay at the table. According to its early investor F-Prime Capital, the app flopped at a Boston pub because it gave servers one more thing to juggle on a busy night. The founders learned that by being in restaurants: CNBC reported at the time of the IPO that they built the company by testing products on local bars, restaurants and cafés. Their pivot to rebuilding the POS itself came out of that proximity.

Software has a name for using what you make: dogfooding. GeekWire's 2025 account traces it to Microsoft in the late 1980s, when Paul Maritz, leading a networking product with almost no customers, told his team that if they had no users they would have to become their own. The idea survived because it works. A builder who depends on the product notices things a survey never asks about.

Running a café pushes that idea further. Engineers using their own email client are forgiving users. A café is less forgiving. A customer waiting for a flat white has no interest in whether the bug is already logged. The cost of a bad interface decision appears within minutes, in a queue, in front of the people who made it.

What a viral week teaches a POS

During Atlético's first soft-opening week, customer posts on Instagram and TikTok drew more than 40,000 organic views without any campaign behind them. That attention exposed the operation: long lines, a saturated kitchen and a customer experience under pressure. Software teams spend real money simulating that kind of load. Atlético received it unscheduled, in its first week, and those are the problems we are working on now.

The generalizable lesson has little to do with virality. Peak load is where a hospitality system's real requirements live, and those requirements are mostly about decisions rather than features. How many choices does a cashier make per order? What happens when the kitchen falls behind and the register keeps accepting tickets? Nara's design standard, which we call operator-grade UX, is fewer taps and fewer decisions during peak hours. That standard only becomes measurable when you stand where peak hours happen.

Offline is a design center, not a fallback

The second principle is that Nara is offline-first by default. The operation cannot stop because the internet does.

That reads like a feature, but it is really a choice about where the truth of a shift lives. Most modern POS platforms are cloud systems that degrade when the connection drops. Toast's own support documentation is unusually candid about what that means in practice. After about 40 seconds without a connection, devices enter an offline mode in which orders and card payments continue, but menu edits, including marking an item as sold out, are unavailable, shift reviews cannot be closed, and reports leave out offline data until devices resync. Staff are told not to log out, because nobody can log back in until the connection returns. These are reasonable tradeoffs for a cloud-first architecture. They also reveal what that architecture treats as normal.

In Mexico, that assumption deserves scrutiny. The Internet Society's Pulse index, using January 2026 data, gives the country 52 out of 100 for internet resilience, below the Americas average of 55, and ranks it 28th in the region on performance. An index is not an outage log, and a well-connected neighborhood in Monterrey says little about the rest of the country. Still, a system designed for a Mexican counter should expect the network to fail, and should treat the counter as the place where the record is created.

Starting from the operation, not the terminal

There is a regional reason this matters. Card payments in Mexico are growing quickly. Banco de México's annual report on financial market infrastructure, as summarized by El Economista in September 2026, counted more than six million point-of-sale terminals installed in businesses by December 2025, 79 percent of them operated by non-bank payment providers. The card terminal has become the most widely distributed piece of retail technology in the country. In our view, that helps explain why so many POS products in Latin America are still built around hardware: the device and the transaction come first, and the operation is fitted around them.

Nara starts from the other end. Its first question is how a shift runs. Payments are designed around service speed, and what happens at the counter is meant to become usable operational data rather than a pile of receipts.

The limits of a lab of one

A café as a laboratory has an obvious weakness. It is one café. A specialty coffee shop in San Pedro has a particular menu, a particular customer and staff who may work a few meters from the people writing the software. A taquería with a charcoal grill, or a chain with forty locations and a central kitchen, will break assumptions Atlético never tests. Builders who own their test site also risk mistaking their own habits for universal ones.

The discipline is to treat Atlético as the first environment rather than the only one. Our thesis describes the loop as observe, prototype, operate and productize, with products returning to real operations to keep being tested. Nara is still in its building stage, and the café comes first.

The question underneath all of this applies well beyond restaurants. Any team building software for physical operations can ask how far its nearest engineer is from the moment the product fails. For most teams the honest answer is measured in weeks and layers of reporting. Opening a café was our way of shrinking that distance to a few meters.