Plataforma SaaS multi-tenant para hostelería: divide cuentas por QR, gestiona pedidos y cobra sin fricciones.
Los restaurantes enfrentan fricciones constantes al momento de cobrar: clientes que quieren dividir cuentas, camareros haciendo cálculos manuales, y sistemas POS que no hablan con pasarelas de pago modernas.
El 73% de los comensales prefiere pagar de forma digital, pero solo el 12% de restaurantes en España ofrece división de cuenta por items.
| ❌ Sin Tally | ✅ Con Tally |
|---|---|
| Divisiones manuales con calculadora | División automática por items con QR |
| POS desconectado de pagos | Un solo sistema: pedidos → cocina → cobro |
| Propinas en efectivo (pérdidas) | Propinas digitales integradas |
| Sin visibilidad del negocio | Dashboard con métricas en tiempo real |
Resultado: Reducción del 40% en tiempo de cierre de mesa y aumento del 25% en propinas digitales.
Decisiones Clave:
| Elegí esto... | En lugar de esto... | ¿Por qué? |
|---|---|---|
| Supabase + RLS | Firebase | Row Level Security nativo para multi-tenancy |
| Zustand + Immer | Redux | API más simple, mejor DX con mutations inmutables |
| Astro (landing) | Next.js SSG | 0 JS por defecto, perfect Lighthouse scores |
| Tailwind v4 | CSS Modules | Design tokens + dark mode con CSS variables |
|
|
|
|
El problema: Múltiples clientes seleccionando items simultáneamente causaba condiciones de carrera y claims duplicados.
La solución:
- Implementación de optimistic locking con campo
versionenorder_items - Validación server-side con
UPDATE ... WHERE version = $current - Retry automático con backoff exponencial en conflictos
Tech stack: PostgreSQL • Zustand • Server Actions
El problema: Cada restaurante debe ver SOLO sus datos, pero las queries no pueden depender de filtros manuales.
La solución:
- Row Level Security (RLS) policies en todas las tablas
restaurant_idpropagado automáticamente desde el JWT- Service role bypass solo para API routes autorizadas
Tech stack: Supabase RLS • PostgreSQL Policies • Middleware Auth
El problema: La app debe funcionar en zonas con mala cobertura dentro del restaurante.
La solución:
- Store dedicado
offline-queue-storepara acciones pendientes - Sincronización automática al recuperar conexión
- UI optimista con rollback en caso de error
Tech stack: Zustand • Service Workers • IndexedDB
El problema: Animaciones scroll-based complejas sin sacrificar performance ni SEO.
La solución:
- Astro para 0 JS en carga inicial
- GSAP ScrollTrigger con lazy-loading
- Lenis para smooth scroll nativo
Tech stack: Astro 5 • GSAP • Lenis • Split-Type
flowchart TB
subgraph Cliente
A[📱 Customer App] --> |QR Scan| B[/go/slug/]
C[🍽️ POS App] --> |Orders| D[/hub/pos/]
E[📊 Admin] --> |Config| F[/hub/admin/]
end
subgraph Backend["Next.js 16 + App Router"]
B --> G[API Routes]
D --> G
F --> G
G --> H[Middleware Auth]
end
subgraph Data
H --> I[(Supabase PostgreSQL)]
G --> J[Stripe API]
I --> |RLS| K[Row Level Security]
end
subgraph Landing["Astro 5 - Static"]
L[paytally.app] --> |CTA| A
end
Componentes Principales:
| Componente | Responsabilidad | Tecnologías |
|---|---|---|
| Customer Flow | División y pago de cuentas | React 19 • Stripe • Zustand |
| POS System | Gestión de pedidos y mesas | Next.js • Server Actions |
| KDS | Display de cocina en tiempo real | Supabase Realtime |
| Admin Dashboard | Configuración del restaurante | React Hook Form • Zod |
| 🎯 Métrica | 📈 Resultado |
|---|---|
| Tiempo de cierre de mesa | -40% |
| Propinas digitales | +25% |
| Errores de facturación | -90% |
| Lighthouse Performance | 98/100 |
| Cobertura de tests | 85% |
Tres tiers de suscripción adaptados al tamaño del negocio:
- Essential: Pasarela de pagos inteligente para venues con POS existente
- Pro: Sistema POS completo con división por items y KDS
- Enterprise: Integraciones API con ERPs externos (Oracle, Micros)
