Caso de estudioNo encontré un sistema que se adaptara a mi café. Así que construí uno.
Lo que empezó como un POS/KDS interno evolucionó a un sistema operativo multi-tenant para hospitality — construido con un workflow de desarrollo AI-native y probado todos los días dentro del negocio para el que fue diseñado.
El sistema que quería no existía
Me estaba preparando para abrir mi propia cafetería, Origen 22. Miré los sistemas de POS y hospitality disponibles, pero ninguno encajaba exactamente con cómo quería operar el negocio.
En vez de adaptar el café al software, decidí construir el software alrededor del café.
OrigenOS empezó como una herramienta interna relativamente pequeña para controlar lo esencial:
La intención inicial nunca fue construir un SaaS enorme. Era resolver mi propio problema. A medida que aparecieron nuevas necesidades operativas, el sistema creció con ellas.
Primera versión funcional en 6 días
OrigenOS no se construyó en seis días — la primera versión funcional, sí. Los primeros seis días consecutivos del repositorio contienen 173 commits. Al sexto día ya existía software funcionando:
Esa versión funcionaba. Y a la vez estaba lejísimos del producto en el que OrigenOS se convertiría.
De POS a sistema operativo
El alcance no creció por un roadmap. Creció porque operar el café hacía visible la siguiente necesidad real.
Construir el producto desde adentro del negocio
OrigenOS se desarrolla dentro del mismo negocio que lo utiliza. La mayoría de las features no nacen en un backlog — nacen detrás del mostrador.
Mostrador vs. servicio de mesa
Mostrador
- Pedir
- Pagar
- Preparar
- Entregar
Servicio de mesa
- Abrir mesa
- Enviar ítems
- Preparar
- Agregar más ítems
- Cerrar mesa
- Pagar
Una orden, múltiples estaciones
Una misma orden puede incluir un cappuccino y un plato. La barra prepara uno, la cocina prepara el otro — así que el sistema envía cada ítem solo a la estación que tiene que prepararlo, en tiempo real. La pantalla de barra además trabaja con tiempos más exigentes que la cocina, porque las bebidas deben salir más rápido que los platos.
KDS Cocina
Tostado
KDS Barra
Cappuccino
El motor de combos
Una oferta real: café a elección + 2 medialunas. Para el cliente es un producto simple. Para el sistema implica representar ítems fijos y elecciones del cliente dentro de una misma entidad comercial — que después impacta en pricing, representación de la orden y ruteo a estaciones.
COMBO
├── 2 × Medialunas — fijo
└── Café — a elección del cliente
├── Espresso
├── Cappuccino
├── Latte
└── …
Las experiencias simples para el cliente suelen requerir modelos de producto no triviales por debajo.
La IA no definió el producto. Cambió qué tan rápido podía construirlo.
Cada feature sigue el mismo camino — de una necesidad real observada en el café a software validado en producción. La IA acelera el medio de ese camino, no los extremos.
Necesidad real
Cada feature empieza por un problema o necesidad que observo en la operación.
Definición de producto
Defino qué quiero que ocurra y cómo debería comportarse.
Discusión
Uso Claude de forma conversacional para discutir opciones de implementación, edge cases, interacción con features existentes y problemas potenciales.
Especificación
De esa conversación surge una especificación concreta.
Implementación
Claude Code acelera la implementación.
Testing
Pruebo el comportamiento y verifico que corresponda con la necesidad original.
Producción
Cuando corresponde, el equipo usa el cambio dentro de Origen 22.
Iteración
El feedback real vuelve al producto.
Decisión humana. Aceleración con IA.
Decisión humana
- Dirección de producto
- Conocimiento operativo
- Priorización
- Decisiones de UX
- Reglas de negocio
- Validación
Acelerado con IA
- Implementación
- Research
- Refactoring
- Debugging
- Asistencia en testing
- Trabajo de ingeniería repetitivo
Esta separación es conceptual, no absoluta. El mensaje es simple: la IA acelera la implementación. El criterio de producto sigue siendo humano.
Construido en software. Probado en hospitality.
OrigenOS no es software que construí para un usuario hipotético. Yo soy el usuario. Mi equipo es el usuario. Y cada día que el café abre, el producto se prueba en producción.
Una aplicación, legible en veinte segundos
Todo el sistema — POS, pantallas de cocina, administración, jobs de fondo y API pública — corre como una única aplicación Next.js. A alto nivel se ve así:
Problemas que valía la pena resolver
Cinco problemas que definieron la ingeniería — cada uno nace de una restricción operativa, no de una elección de tecnología.
Aislamiento multi-tenant
Cada query y cada fila deben quedarse dentro de su tenant. El aislamiento se aplica en dos capas independientes — aplicación y base de datos — para que un solo error no pueda filtrar datos.
Sincronización de estaciones en tiempo real
Una orden tomada en el POS tiene que aparecer al instante en la pantalla de cocina o barra correcta, y mantenerse sincronizada a medida que cambia de estado.
Gestión de estados de la orden
Las órdenes pasan por estados que no siempre avanzan de forma lineal — agregar un ítem a una orden lista la reabre intencionalmente. Cerrar una orden coordina pago, comprobante fiscal, stock y fidelización en una sola transacción.
Integraciones fiscales y externas
La facturación electrónica depende de proveedores externos. Cuando un proveedor se cae, el POS sigue vendiendo — los comprobantes se encolan offline y se procesan automáticamente cuando vuelve la conectividad.
Impresión confiable en segundo plano
El servidor nunca habla directamente con una impresora. Los trabajos de impresión se encolan y un pequeño agente dentro de la red del café los toma — diseñado para que un mismo ticket no pueda imprimirse dos veces.
Para ingenieros que quieren el detalle
Lectura opcional. La historia de arriba funciona sin esta sección — esto es para el lector técnico que quiere bajar un nivel.
Frontend
- Next.js 16 App Router, React 19, TypeScript estricto
- Tailwind CSS 4 con primitivas de Radix UI
- Pantallas de cocina con suscripciones realtime, sin polling
- PWA instalable para los dispositivos del mostrador
Backend
- Una sola aplicación — sin backend separado
- Server Actions para mutaciones disparadas por personas
- API routes para crons, webhooks, el agente de impresión y una API pública versionada
- Contextos de autenticación separados para staff, clientes y admin de plataforma
Datos
- PostgreSQL en Supabase
- Row-level security más un guard de tenant a nivel de aplicación en cada query
- Precios, stock y configuración fiscal por sucursal
- Canales realtime para las pantallas de estación
Seguridad y confiabilidad
- Credenciales fiscales cifradas en reposo
- Webhooks firmados y rate limiting en endpoints públicos
- Colas offline para comprobantes fiscales e impresión
- Migraciones retrocompatibles — la evolución multi-tenant nunca requirió una reescritura
Primero un café. Después, más.
Hoy OrigenOS opera un negocio: Origen 22.
Durante aproximadamente un mes más, el plan es seguir usándolo intensivamente dentro del café — dogfooding: usar tu propio producto todos los días antes de pedirle a alguien más que lo haga.
Los objetivos de esa fase:
Después: empezar el onboarding de otros negocios gastronómicos. La arquitectura ya es multi-tenant — pero hay una diferencia entre una arquitectura que soporta muchos negocios y un producto probado por ellos. Prefiero ganarme lo segundo antes de vender lo primero.
Me gusta construir software así.
Problemas reales. Iteración rápida. Feedback de producción. Si así es como querés construir productos, hablemos.