CASE STUDY
API endpoints
Multi-tenant restaurant SaaS: 132 endpoints, 9 languages
API endpoints
frontend pages
languages (incl. RTL)
RBAC permission scopes
A multi-tenant restaurant SaaS platform with 132 API endpoints across 9 languages — ordering, kitchen display, inventory and aggregator reconciliation, built so a single deployment serves many venues with strict isolation between them.
Restaurant groups were stitching together five tools that did not talk to each other — orders, kitchen, inventory, reservations and analytics all lived in different tabs.
We designed and shipped a production multi-tenant SaaS covering POS, kitchen display systems, QR ordering, inventory, reservations and analytics: 132 API endpoints, 53 frontend pages.
Real-time order orchestration runs over Socket.IO; Stripe subscription billing handles the full webhook lifecycle; a conversational AI agent takes bookings and orders.
The platform ships with 9-language i18n including RTL Arabic and 23 RBAC permission scopes — enterprise-grade access control out of the box.
What made this hard
It runs during service
Anything needing staff attention mid-rush is switched off within a week, whatever its accuracy. The design case is a Friday night with nobody free to supervise it.
Nine languages, not one translated nine times
Menu content, interface and receipts each have different localisation requirements, and getting that wrong is visible to every customer.
Tenancy decided first
Multi-tenant isolation shapes schema, authorisation and background work. It is the most expensive decision to reverse, so it came before any feature.
Aggregators hold data the venue never sees
Orders arriving through delivery platforms never reach the restaurant's own systems without deliberate reconciliation.
How we built it
Tenancy and isolation
A single deployment serving many venues, with data separation enforced at the data layer rather than in application code.
Ordering and kitchen display
The operational core, built for use all day by people under time pressure — a stricter standard than occasional use.
Inventory and reconciliation
Stock deduction on sale, plus reconciliation against aggregator platforms whose order data would otherwise stay outside the business.
API surface
132 endpoints with authentication, validation and errors that tell the caller what to do.
The stack
What should you take from this?
- The operational surface — admin, support tooling, reconciliation — is most of what determines whether a platform is runnable at a hundred venues. It is invisible in a demo.
- Localisation is not translation. Menus, interfaces and receipts each carry different requirements, and treating them as one job produces nine broken versions.
- If you have one venue, you have custom software rather than SaaS. Building multi-tenancy before the second customer exists is an expensive way to be slow.
Frequently asked questions
How do you handle multi-tenancy?
Isolation enforced at the data layer rather than trusted to application code, decided before any feature was built. It is the most expensive architectural decision to reverse under load.
Does it work with existing POS systems?
Integration with the POS is normally the largest single piece of work, because it is the system of record and frequently the least accessible thing in the building.
What about delivery aggregators?
Reconciliation is deliberate work. Orders arriving through aggregator platforms hold data that never reaches the restaurant's own systems unless something is built to bring it back.
Related service: AI-Powered SaaS Development
Build something at this level
Tell us what you are building. We reply within one business day.