Servrr
Problem
Restaurants lose orders to paper chits and shouting across the floor. Existing QR systems assume app installs and card payments customers here don't do.
Constraint
Cash-first customers, staff with zero dashboard experience, and printed QR codes that can't be reissued every order without chaos.
Decision
Permanent table tokens with staff-controlled session lifecycle: the QR never changes, but a waiter opens and closes each table's session, so a stale scan can't place a ghost order.
Result
Multi-tenant SaaS live at servrr.ng with Growth and Pro tiers, onboarding real restaurants, full legal stack covering local data protection requirements.
My product, from the first decision to deployment
Servrr is a product I build and operate, rather than a client landing-page commission. My responsibility covers the workflow, product positioning, interface, frontend, backend, and deployment. The public website is only the entry point; the product has to coordinate what happens between a diner, the restaurant team, and an active table session.
The engineering problem is operational correctness: an order must belong to the right restaurant and session, staff must control when a table can order, and the software must fit service on a busy restaurant floor. A polished interface matters, but it is useful only when those underlying rules hold.
Why this exists
Walk into a busy restaurant and watch how an order travels: a customer flags a waiter, the waiter scribbles on a chit or memorises it, shouts it to the kitchen, and hopes. Orders get lost, tables get the wrong food, and during rush hour the whole system runs on adrenaline.
QR ordering solves this everywhere else in the world, but the imported playbook fails here. It assumes customers will install an app, pay by card, and that the restaurant can print fresh QR codes per order. None of that matches how people actually eat here.
The architecture decision that matters
The core problem was QR lifecycle. A printed code glued to a table lives for months, so it can't carry order state. Servrr separates identity from session: every table gets a permanent token, and staff open a session when guests sit down and close it when they leave. A scan outside an open session simply can't order, which kills ghost orders from stale codes and screenshots.
Everything is multi-tenant from the schema up: one deployment, many restaurants, each with its own menu, staff roles, and theming. Email delivery runs on Resend, the backend deploys on Render, and the legal layer (ToS, Privacy Policy, NDA) is drafted under applicable data protection law.
What shipped
Servrr is live at servrr.ng with Growth and Pro pricing tiers, and outreach is running across local restaurants. It's a real product in a real market, being sold, not a portfolio piece wearing a SaaS costume.
What this project demonstrates
The permanent QR token is a small surface detail backed by a larger lifecycle decision. Separating a table's identity from its current session lets a physical code remain usable while keeping ordering under staff control. Restaurant-specific menus, roles, and branding sit within a shared deployment rather than separate copies of the application.
Servrr also involves the work around the application: packaging the offering into subscription tiers, deploying services, handling email delivery, documenting privacy and product terms, and bringing the product to restaurant operators. These are responsibilities I own alongside the code.