Savorar
Multi-tenant restaurant ordering — customer app, admin console, one backend
2025 · Accra, Ghana
In one paragraph
Savorar is a multi-tenant restaurant ordering platform: one codebase and one deployment serving many restaurants, each with its own menu, branding and orders. A customer web app for ordering, an admin dashboard for running the kitchen side, and a Go backend that keeps every tenant's data strictly separated.
The problem
A restaurant that wants online ordering has two bad options. Marketplace platforms take a heavy commission and own the customer relationship — the restaurant becomes a supplier to someone else's brand. Building bespoke is far beyond the budget of a single restaurant.
Savorar is the third option: the restaurant gets its own ordering front door, its own menu and branding, and its own customers, on shared infrastructure that makes the economics work.
What I built
A customer ordering app — browse a specific restaurant's menu, build an order, check out. The restaurant's identity, not the platform's.
An admin dashboard — menu and category management, live order handling as tickets arrive, and per-restaurant settings.
A Go backend with tenant-scoped authentication and authorisation, serving every restaurant from one deployment.
The multi-tenancy decision
The alternative was a deployment per restaurant. That is trivially isolated and operationally miserable:
Deployment per tenant | Single multi-tenant deployment | |
Isolation | Free — separate processes and databases | Earned — every query must filter by tenant |
Releases | Multiply by the number of restaurants | One |
Cost per tenant | A full stack each | Marginal |
Blast radius | One restaurant | All of them, if scoping is wrong |
Single-deployment multi-tenancy concentrates the entire risk into one property: tenant scoping must be correct, everywhere, without exception. Every query filters by tenant, and authorisation is enforced server-side on every request rather than inferred from what the client claims to be. Get that wrong once and one restaurant reads another's orders.
That concentration is actually the argument for it. One property, enforced in one place, audited hard — rather than operational complexity spread across N environments that drift apart. It's the same pattern the portfolio you're reading runs on: one codebase, one deployment, many sites resolved by hostname.
Stack
Go · MongoDB · Next.js · multi-tenant auth with per-tenant scoping