Todos los proyectos
Producto propio

APB Resto

SaaS multi-tenant para restaurantes: pedidos y pagos desde la mesa con QR, cocina en tiempo real y delivery propio.

Rol
Diseño, arquitectura y desarrollo full-stack
Año
2026
Estado
En producción
Cliente
Producto propio
Ver en producción
Multi-tenant
con RLS de PostgreSQL
OAuth
cobro por local
Realtime
cocina y delivery
PWA
instalable

Resumen

APB Resto es una plataforma SaaS que un restaurante contrata para digitalizar toda su operación, de cara al cliente y de puertas adentro. El comensal escanea un QR en la mesa, pide y paga desde su celular sin instalar nada; la cocina recibe el pedido en tiempo real; y el dueño gestiona carta, stock, caja, empleados, delivery y reservas desde un panel único.

Contexto

El problema

Los restaurantes operan con sistemas fragmentados: una app para pedidos, una planilla para stock, WhatsApp para delivery y un cuaderno para reservas. Nada se habla entre sí, y el dueño no tiene una foto única de su operación.

La solución

Una sola plataforma que cubre el circuito completo — mesa, cocina, caja, stock, delivery y reservas — construida como arquitectura multi-tenant: una instancia sirve a múltiples restaurantes con aislamiento de datos garantizado a nivel de base de datos, y cada local cobra en su propia cuenta de Mercado Pago.

Qué hace

Pedido y pago desde la mesa

El comensal escanea el QR, ve la carta, arma su pedido y paga desde el navegador sin instalar nada.

Cocina en tiempo real

Los pedidos llegan a la pantalla de cocina en el momento, con Wake Lock API para que el display no se apague durante el servicio.

Control de stock por gramaje

El descuento de insumos se calcula por cantidad real usada en cada plato, no por unidad de producto.

Delivery propio con seguimiento en vivo

Mapas con Leaflet y OpenStreetMap, geocoding con Nominatim y GPS del navegador para seguir el pedido en curso.

Aislamiento por tenant a nivel de base

Row Level Security de PostgreSQL: el aislamiento no depende de que la aplicación se acuerde de filtrar, sino de políticas en la base. Un bug en el código no puede filtrar datos entre restaurantes.

Cobro con OAuth por restaurante

Cada local conecta su propia cuenta de Mercado Pago vía OAuth y cobra directo, sin que la plataforma intermedie el dinero.

Decisiones técnicas

  1. 01

    Supabase sobre backend propio

    Para un producto multi-tenant donde el aislamiento es el requisito crítico, RLS en la base es más sólido que cualquier capa de autorización en aplicación. Supabase suma Auth, Realtime y Storage sobre el mismo PostgreSQL, lo que eliminó tres servicios que habría tenido que construir y operar.

  2. 02

    Sistema de diseño propio “Brasa”

    Paleta OKLCH cálida con dark mode por defecto, pensada para pantallas de cocina en ambientes de poca luz y para el celular del comensal en un salón oscuro.

  3. 03

    PWA en vez de app nativa

    El comensal no va a instalar una app para pedir una cerveza. Manifest y service worker dan instalabilidad para el personal del local, sin fricción de store para el cliente final.

Stack

Frontend

  • Next.js 16
  • App Router
  • Server Actions
  • RSC
  • React 19
  • TypeScript

UI

  • Tailwind CSS 4
  • shadcn/ui
  • Base UI
  • Motion
  • Sistema de diseño Brasa (OKLCH)

Backend / Datos

  • Supabase
  • PostgreSQL multi-tenant
  • Row Level Security
  • Auth
  • Realtime
  • Storage
  • Triggers y funciones SQL

Integraciones

  • Mercado Pago OAuth + webhooks
  • Leaflet
  • OpenStreetMap
  • Nominatim
  • Wake Lock API

Infra / QA

  • Netlify SSR
  • Supabase Cloud
  • Migraciones versionadas
  • Playwright

Siguiente proyecto

Clases Suite