APB Resto
Multi-tenant SaaS for restaurants: order and pay from the table via QR, real-time kitchen and in-house delivery.
- Role
- Design, architecture and full-stack development
- Year
- 2026
- Status
- In production
- Client
- Own product
- Multi-tenant
- with PostgreSQL RLS
- OAuth
- per-venue payments
- Realtime
- kitchen and delivery
- PWA
- installable
Overview
APB Resto is a SaaS platform a restaurant subscribes to in order to digitise its entire operation, both customer-facing and behind the scenes. Diners scan a QR code at the table, order and pay from their phone without installing anything; the kitchen receives the order in real time; and the owner manages menu, stock, till, staff, delivery and reservations from a single panel.
Context
The problem
Restaurants run on fragmented systems: one app for orders, a spreadsheet for stock, WhatsApp for delivery and a notebook for reservations. Nothing talks to anything else, and the owner has no single picture of the operation.
The solution
A single platform covering the full circuit — table, kitchen, till, stock, delivery and reservations — built as a multi-tenant architecture: one instance serves multiple restaurants with data isolation guaranteed at the database level, and each venue collects payments into its own Mercado Pago account.
What it does
Order and pay from the table
The diner scans the QR code, browses the menu, builds their order and pays from the browser without installing anything.
Real-time kitchen
Orders reach the kitchen display instantly, with the Wake Lock API keeping the screen awake through service.
Stock control by weight
Ingredient deduction is calculated by the actual quantity used in each dish, not per product unit.
In-house delivery with live tracking
Maps with Leaflet and OpenStreetMap, geocoding via Nominatim and browser GPS to follow the order in progress.
Tenant isolation at the database level
PostgreSQL Row Level Security: isolation doesn't depend on the application remembering to filter, but on policies in the database. A bug in the code cannot leak data between restaurants.
Payments via per-restaurant OAuth
Each venue connects its own Mercado Pago account through OAuth and collects directly, without the platform holding the money.
Technical decisions
- 01
Supabase over a custom backend
For a multi-tenant product where isolation is the critical requirement, RLS in the database is stronger than any application-level authorisation layer. Supabase adds Auth, Realtime and Storage on top of the same PostgreSQL, which removed three services I would otherwise have had to build and operate.
- 02
A custom design system, “Brasa”
A warm OKLCH palette with dark mode by default, designed for kitchen screens in low-light environments and for the diner's phone in a dim dining room.
- 03
PWA instead of a native app
Nobody installs an app to order a beer. A manifest and service worker give installability to the venue's staff, without app-store friction for the end customer.
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 / Data
- Supabase
- PostgreSQL multi-tenant
- Row Level Security
- Auth
- Realtime
- Storage
- Triggers y funciones SQL
Integrations
- Mercado Pago OAuth + webhooks
- Leaflet
- OpenStreetMap
- Nominatim
- Wake Lock API
Infra / QA
- Netlify SSR
- Supabase Cloud
- Migraciones versionadas
- Playwright
Next project