Restaurant SaaS

Dineri

All-in-one platform for independent restaurants: a mobile-ready restaurant page with menu, commission-free reservations, food ordering, QR codes, reviews, and analytics, live in about 10 minutes.

Visit live site Book a call

Year: 2025
Platform: Next.js · React · TypeScript
Status: Live in production

https://dineri.app/

At a glance

Modules: menu, reservations, ordering, QR, reviews, analytics: 6
Commission on reservations and orders: €0
From sign-up to a live restaurant page: 10 min
Online bookings accepted: 24/7

The challenge

What Dineri needed.

Restaurants needed a single platform to manage menus, customer-facing pages, and growth tooling without requiring technical staff. The product had to scale across multiple locations and languages from day one.

Goals

Let non-technical restaurant owners manage their own menus
Support multiple locations and languages from day one
Give every restaurant a branded, mobile-first customer menu

Our approach

How we built it.

We architected Dineri as a multi-tenant SaaS so each restaurant gets an isolated, fully branded experience while running on shared infrastructure.

01
Sitting in Restaurants
2 weeks
We spent the first two weeks talking to real restaurant owners and watching how they actually scanned QR codes at their own tables. Two things became obvious fast: every owner spoke a different language, and almost none of them knew what "multi-tenant" meant. But they all instantly understood "your menu, your colors, our problem."
- Owner interviews (8 restaurants, 3 countries)
- Tenant isolation model on paper
- i18n strategy. Translatable per dish, not just per shell
- A rough roadmap the client could read without us
02
Designing the Menu, Not the Dashboard
3 weeks
We designed the customer menu first, before the admin. Most SaaS does this backwards. The whole product exists to make the menu great. So we got the menu right, then worked backward to the dashboard that produces it.
- Customer menu in 6 brand variants
- Owner dashboard built around the menu, not vice versa
- Design tokens for per-restaurant theming
- Mobile interactions tested on real phones at restaurant lighting
03
The Multi-tenant Bones
4 weeks
We made the tenancy boundary the first thing the code knows about. Every query takes a tenant ID before it takes anything else. We caught two early bugs in code review where a developer forgot to pass it. And made it a compile-time error after that.
- Subdomain routing with tenant context propagated everywhere
- Theming engine (CSS variables resolved at runtime per tenant)
- Auth + onboarding wired to the new tenant flow
- Type-level guarantee that tenant ID can't be forgotten
04
Menu Builder + i18n
3 weeks
The menu builder went through three rewrites. The first was technically clean but felt fiddly. The second was easy to use but skipped translations. The third, which shipped, let owners switch languages while editing and see the customer view update in a panel beside them.
- Drag-and-drop menu builder
- Per-dish translation editor with live preview
- Image uploads with client-side compression
- Schema validation that prevents broken menus going live
05
Launch
2 weeks
We launched with the first three restaurants from the original interviews. One of them onboarded entirely on their own while we were on a call with another. That was the moment we knew the flow worked. Analytics and monitoring went up the same week.
- Production launch at dineri.app
- Self-serve onboarding (tested by a non-engineer in 11 minutes)
- Per-restaurant analytics on the dashboard
- Short owner-facing runbook

The outcome

What we delivered.

We built Dineri so a restaurant owner with no tech background can open their phone at the table, change the price of a dish, and have it live before the customer puts the menu down.

Dineri is live at dineri.app as a full platform for independent restaurants, replacing a separate website, booking tool, and delivery app with one commission-free page.

Menu in seconds
Owners change dishes, prices, and photos from their phone, and the change is live straight away.
Commission-free reservations
Online bookings around the clock, with no per-booking fees and no-show protection built in.
Direct food ordering
Takeaway and delivery orders come straight to the restaurant, with zero commission instead of the 25 to 30% charged by delivery platforms.
QR codes with tracking
Restaurants create QR codes for the menu, reservations, or any page, and see how often each one is scanned.
Reviews and analytics
Google rating and review count shown automatically, plus analytics on what guests view, click, and where they come from.
Live in production
Running at dineri.app for independent restaurants.

Before and after

What changed.

Before

Most restaurants we talked to were emailing a PDF menu to a Linktree page, or worse, asking a cousin to update a printed flyer
Multi-location owners maintained the same menu in three places, and at least one was always wrong
Changing the price of a single dish meant a phone call, a Photoshop edit, and a re-upload. Sometimes a day's wait
Customers landed on the menu, pinch-zoomed a PDF, gave up, and asked the waiter
Owners had no idea which dishes people actually looked at
Staff could not update anything without help from the friend who originally set it up
Nothing across the menu, the social links, or the booking page looked like the same restaurant

After

Each restaurant gets its own subdomain, its own colors, its own logo. Sharing one quiet platform underneath
One dashboard, every location, every menu. Including the one in the second city the owner kept forgetting to update
Edit a dish, hit save, and the customer scanning the QR code at table 4 sees the new price on their next refresh
Customer menus designed for one-handed scrolling on a phone at the table, not a desktop browser
Owners can see exactly which dishes get viewed, which get skipped, and which photos people actually open
The onboarding flow is short enough that the owner finishes it themselves before we get on the call
Customer-facing pages feel like the restaurant. Same fonts, same colors, same warmth. Not like Dineri

Technology

Built with.

The tools behind the build, and why each one was chosen.

Frontend

React: We needed per-tenant theming at render time. Passing one theme object down the tree was simpler than fighting a framework about it.
TypeScript: Made tenant ID a non-optional argument at the type level. Two bugs caught at compile time that would have caused tenants to see each other's data.
Tailwind CSS: Theming via CSS variables wired into Tailwind tokens. Owners change their primary color in a picker, the entire UI follows, no rebuild.

Tenancy

Subdomain routing: Each restaurant gets its own host. The router resolves the tenant before any data fetch. No "oops, wrong restaurant" possible.
Theme tokens: Stored per tenant, injected as CSS variables. Falls back to safe defaults if an owner clears a value mid-edit.

i18n

Per-dish translations: Most i18n libraries translate the shell, not the content. We needed the content too. A paella in Madrid and London are not always described the same way.
Locale switcher with memory: Customer's language choice sticks across visits via a cookie. The owner can preview every translation before publishing.