Por qué abrimos un café para construir un sistema de punto de venta

Un sistema de punto de venta se juzga en el peor momento del turno. La fila llega hasta la puerta, un barista está cubriendo la caja, la cocina va tres comandas atrás y alguien quiere dividir la cuenta entre cuatro. Lo que haga el software en ese momento es lo que el software es. La demo de ventas, la lista de funciones y la llamada de onboarding describen un producto que la persona del mostrador nunca llega a conocer.

Esa distancia es la razón de ser de Atlético Café. Atlético es un lugar de café de especialidad y brunch en San Pedro Garza García, Monterrey, abierto todos los días de ocho de la mañana a ocho de la noche. Lo operamos en WAOF, un estudio de tecnología, producto y creatividad que nació en Monterrey, como laboratorio de I+D para retail. Es un negocio real con clientes reales. Y es también, por diseño, donde construimos y probamos Nara, el sistema de punto de venta con el que opera su mostrador.

La distancia es lo normal

Años de trabajo como agencia para operadores de retail, salud, hospitalidad e instituciones nos dejaron un patrón que describimos sin rodeos en nuestra tesis: el software se construye demasiado lejos de las personas que lo usan. Casi nunca es por negligencia. Quienes escriben software para restaurantes suelen estar en oficinas, y la retroalimentación les llega filtrada por tickets de soporte, ejecutivos de cuenta y roadmaps. Para cuando una queja sobre un flujo torpe de modificadores llega a un ingeniero, ya es una línea más que compite con otras cuarenta.

El contraejemplo más conocido es revelador. Toast, que salió a bolsa en 2021 con unos 48,000 restaurantes como clientes, empezó con una app móvil para que los comensales pagaran en la mesa. Según F-Prime Capital, uno de sus primeros inversionistas, la app fracasó en un pub de Boston porque les daba a los meseros una cosa más que hacer en una noche llena. Los fundadores lo aprendieron estando en restaurantes: CNBC reportó, cuando salió a bolsa, que construyeron la empresa probando productos en bares, restaurantes y cafés locales. Su giro hacia reconstruir el POS mismo salió de esa cercanía.

El software tiene un nombre para usar lo que uno mismo hace: dogfooding. El recuento que publicó GeekWire en 2025 lo sitúa en Microsoft a finales de los ochenta, cuando Paul Maritz, al frente de un producto de redes casi sin clientes, le dijo a su equipo que si no tenían usuarios tendrían que convertirse en sus propios usuarios. La idea sobrevivió porque funciona. Quien depende del producto nota cosas que ninguna encuesta pregunta.

Operar un café lleva esa idea más lejos. Los ingenieros que usan su propio cliente de correo son usuarios indulgentes. Un café lo es menos. A un cliente que espera un flat white no le interesa si el bug ya está registrado. El costo de una mala decisión de interfaz aparece en minutos, en una fila, frente a las personas que la tomaron.

Lo que una semana viral le enseña a un POS

Durante la primera semana de apertura suave de Atlético, las publicaciones de clientes en Instagram y TikTok sumaron más de 40,000 vistas orgánicas sin ninguna campaña detrás. Esa atención dejó expuesta la operación: filas largas, una cocina saturada y una experiencia de cliente bajo presión. Los equipos de software gastan dinero de verdad en simular ese tipo de carga. Atlético la recibió sin aviso, en su primera semana, y esos son los problemas en los que estamos trabajando ahora.

La lección que sirve para otros tiene poco que ver con lo viral. La carga pico es donde viven los requisitos reales de un sistema de hospitalidad, y esos requisitos tienen más que ver con decisiones que con funciones. ¿Cuántas decisiones toma un cajero por pedido? ¿Qué pasa cuando la cocina se atrasa y la caja sigue aceptando comandas? El estándar de diseño de Nara, al que llamamos UX de grado operativo, es menos toques y menos decisiones en horas pico. Ese estándar solo se puede medir cuando uno está parado donde ocurren las horas pico.

Sin conexión es el centro del diseño, no un plan B

El segundo principio es que Nara funciona sin conexión por defecto (offline-first). La operación no puede detenerse porque se cae el internet.

Suena a una función, pero en realidad es una decisión sobre dónde vive la verdad de un turno. La mayoría de las plataformas POS modernas son sistemas en la nube que se degradan cuando se pierde la conexión. La documentación de soporte de Toast es inusualmente franca sobre lo que eso significa en la práctica. Tras unos 40 segundos sin conexión, los dispositivos entran en un modo sin conexión en el que siguen los pedidos y los pagos con tarjeta, pero no se puede editar el menú, ni siquiera para marcar un producto como agotado, no se pueden cerrar los cortes de turno y los reportes dejan fuera los datos sin conexión hasta que los dispositivos se resincronizan. Al personal se le indica no cerrar sesión, porque nadie puede volver a entrar hasta que regrese la conexión. Son concesiones razonables para una arquitectura que parte de la nube. También revelan qué considera normal esa arquitectura.

En México, ese supuesto merece revisarse. El índice Pulse de Internet Society, con datos de enero de 2026, le da al país 52 de 100 en resiliencia de internet, por debajo del promedio de 55 de las Américas, y lo coloca en el lugar 28 de la región en desempeño. Un índice no es un registro de caídas, y una colonia bien conectada de Monterrey dice poco del resto del país. Aun así, un sistema diseñado para un mostrador mexicano debería esperar que la red falle, y tratar el mostrador como el lugar donde se crea el registro.

Empezar por la operación, no por la terminal

Hay una razón regional por la que esto importa. Los pagos con tarjeta en México crecen rápido. El informe anual de Banco de México sobre las infraestructuras de los mercados financieros, según el resumen de El Economista de septiembre de 2026, contó más de seis millones de terminales punto de venta instaladas en comercios a diciembre de 2025, 79 por ciento de ellas operadas por proveedores de pagos no bancarios. La terminal de tarjetas se ha vuelto la pieza de tecnología comercial más distribuida del país. En nuestra opinión, eso ayuda a explicar por qué tantos productos POS en América Latina siguen construidos alrededor del hardware: primero van el dispositivo y la transacción, y la operación se acomoda a ellos.

Nara empieza por el otro extremo. Su primera pregunta es cómo corre un turno. Los pagos se diseñan en función de la velocidad del servicio, y lo que pasa en el mostrador está pensado para convertirse en datos operativos útiles y no en un montón de tickets.

Los límites de un laboratorio de uno

Un café como laboratorio tiene una debilidad evidente. Es un solo café. Una cafetería de especialidad en San Pedro tiene un menú particular, un cliente particular y un equipo que puede trabajar a unos metros de quienes escriben el software. Una taquería con parrilla de carbón, o una cadena de cuarenta sucursales con cocina central, romperá supuestos que Atlético nunca pone a prueba. Quien es dueño de su propio sitio de pruebas también corre el riesgo de confundir sus hábitos con algo universal.

La disciplina está en tratar a Atlético como el primer entorno y no como el único. Nuestra tesis describe el ciclo como observar, prototipar, operar y productizar, con productos que regresan a operaciones reales para seguir probándose. Nara sigue en etapa de construcción, y el café va primero.

La pregunta de fondo aplica mucho más allá de los restaurantes. Cualquier equipo que construya software para operaciones físicas puede preguntarse qué tan lejos está su ingeniero más cercano del momento en que el producto falla. Para la mayoría, la respuesta honesta se mide en semanas y en capas de reportes. Abrir un café fue nuestra manera de reducir esa distancia a unos cuantos metros.