# Platea

> Platea is a multi-tenant direct-ordering and restaurant-operations SaaS with full source code included.

Source page: https://saascode.ai/products/platea
Machine-readable record: https://saascode.ai/products/platea.md

One-time purchase · full source code · self-hosted by the buyer.

Price: $199 (one-time)

## How to read this document

Written for a model auditing this product on a buyer's behalf. Two labels
appear throughout and they mean different things:

- **measured** — produced by a script reading the product's own source tree
  or database at the stated date. The method is named beside each number.
- **stated** — written by the seller. True or not, it is a claim, and this
  document does not ask you to treat it as evidence.

The live demo is the strongest verification available from outside: it runs
the same source a buyer receives. Nothing to sign up for — the public side is
open, and the seeded credentials below get you into each role.

## What it is

Platea is a direct-ordering and operations system for restaurants. Each restaurant or restaurant group gets its own branded storefront, menu, orders, kitchen queue, delivery rules, drivers, diner history and payment account. The restaurant owns the diner relationship and receives diner money directly.

## Live demo

Two doors into the same running instance, and the same source a buyer
receives. There is no account to create; the public side is open, and the
seeded credentials below sign you into each role.

- **Guided (recommended):** https://saascode.ai/demo/platea — our shell, with a role switcher and
  the credentials in the menu. Best for a person.
- **Direct:** https://platea.saascode.ai — the product on its own, no chrome.
  Best when you are relaying steps to someone, or fetching a page.

5 roles seeded on the demo (of the 7 the schema defines — the build data below counts them all). Credentials are published deliberately: these
are demo accounts on a public demo instance, and a reviewer who cannot get
in cannot verify anything.

- **Delivery driver** (`driver`) — `driver@demo.com` / `see the page`
  Works assigned deliveries and records each permitted travel step.
- **Kitchen staff** (`kitchen`) — `kitchen@demo.com` / `see the page`
  Prepares station-scoped tickets and moves them through service.
- **Restaurant owner** (`org_admin`) — `org-admin@demo.com` / `see the page`
  Runs the restaurant's menu, orders, staff and finances.
- **Shift manager** (`manager`) — `manager@demo.com` / `see the page`
  Runs orders, availability and shift work for one location. Lands on `/dashboard/orders`.
- **Platform operator** (`super_admin`) — `admin@demo.com` / `see the page`
  Runs restaurants, plans, integrations and cross-org support.

Or open a role directly: https://saascode.ai/demo/platea?role={role}

## Measured build

*measured — each number names the method that produced it.*

- **roles: 7** — distinct roles accepted by the role CHECK constraint: admin, driver, kitchen, manager, member, org_admin, super_admin
- **tables: 88** — distinct CREATE TABLE statements across every applied migration
- **migrations: 110** — .sql files in supabase/migrations
- **page modules: 107** — files named page.tsx under src/app, excluding node_modules and .next
- **source lines: 199,116** — lines of code (comments and blank lines excluded) across 1297 TypeScript files (177,037) and 138 SQL files (22,079); node_modules and .next excluded
- **api route files: 292** — files named route.ts under src/app/api
- **http operations: 391** — exported HTTP method handlers across those files, de-duplicated per file, OPTIONS excluded as CORS preflight
- **schema graph: 88 tables, 160 relationships** — parsed from the applied migrations

A large number here is scope, not quality. It says the product models a
real domain rather than a CRUD skeleton; it says nothing about code
quality, duplication, test coverage or maintainability, and should not be
read as if it did.

Release: v1.0.0 · built 2026-08-19

## Complete capability inventory

14 capabilities. Each summary is *stated* — selected from the
product's own buyer documentation, or written by the seller where marked.

### What Platea is and who uses it

- **Core tenancy, auth, RLS, audit** *(seller-authored)* — Keeps each restaurant or group inside its own data and operating boundary while the platform owner retains a separate cross-restaurant control plane. Authentication, tenant isolation, role ceilings and the audit trail preserve that separation as staff and restaurant accounts accumulate.
- **Group controls** — A group with several locations manages them under one account; staff are scoped to the locations and stations they work at.

### Menu, storefront, availability and table QR

- **Direct ordering** — Each restaurant's public ordering page lives at /r/ followed by its slug — for example /r/bistro-jacaranda. It is responsive, needs no diner account, and carries the restaurant's own brand.
- **Table QR** — A restaurant can print QR codes per table. Scanning one opens the menu with a signed table token so the order is attached to that table, and the diner confirms the table before ordering. Assisted and paper service still work exactly as before — QR is a convenience, never a requirement. Tables have labels and capacities and can be enabled or disabled individually, and their tokens can be rotated if a code leaks or a printed card is replaced.
- **Tenant branding** *(seller-authored)* — Gives each restaurant a responsive ordering surface under its own slug with controls for logo, palette and typography. The restaurant presents its own identity while the release stays honest about the boundary: custom restaurant domains are not included.
- **Advanced branding** *(seller-authored)* — Expands palette and type-preset controls for restaurant groups while keeping every storefront on Platea's shared address structure. The broader brand range ships behind the Grupo tier and does not imply a custom-domain system that this release does not include.

### Orders, kitchen display, shifts and printing

- **Kitchen display** — Tickets appear on a station-scoped queue with timers. The critical behaviour: the display recovers the complete set of active orders when it loads, when the tablet wakes from sleep, when it comes back online, on reconnect, and when the browser tab becomes visible again. Live updates are treated as a hint; the database is the source of truth. A tablet that slept through the lunch rush comes back with every ticket it missed, not just the ones that arrived after it woke.
- **Managed printing** — A print job is only closed when the printing service acknowledges it. A successful submit is not treated as a successful print — that distinction is what stops silently lost tickets.

### Delivery zones, drivers, geocoding and diner tracking

- **Delivery operations** — Fulfillment modes are pickup, delivery and dine-in. A restaurant enables the ones it offers, per location.

### Diner records, promotions and email campaigns

- **Basic reports** — Reports cover sales, product performance, peak hours, average ticket and per-location rollups, plus shift close totals.
- **Promotions (Percentage, fixed-amount and free-delivery promotions with time windows and immutable order snapshots)** *(seller-authored)* — Percentage, fixed-amount and free-delivery promotions with time windows and immutable order snapshots
- **Diner CRM** — Because diners order without an account, Platea merges guest identities from the details they leave — building order history and frequency per restaurant. This gives a restaurant a view of who orders, how often and what they buy, without forcing anyone to register. Available on Operacion and above.
- **Email campaigns (Email campaigns from the restaurant support email, with consent checks, suppression controls and send tracking)** *(seller-authored)* — Email campaigns from the restaurant support email, with consent checks, suppression controls and send tracking

### Payments, connected accounts, plans and what Platea charges

- **Online payments** — A country + currency + provider + method combination appears at checkout only when it is on the operator-maintained tested list and the restaurant's connected account is genuinely ready. The list starts empty, so a new installation shows no online payment method until the operator records a combination they have actually tested in both sandbox and live mode. This is intentional — an untested payment method is absent rather than assumed to work. Cash on delivery is unaffected and works without it.

## What each system gives the operator

*stated.*

- **Platform ownership and access** — Keep platform ownership and restaurant work separated as the network grows.
- **Menu and direct ordering** — Give every restaurant a branded ordering surface it can operate with confidence.
- **Orders and kitchen** — Keep accepted orders moving through service, kitchen, shift close and print.
- **Delivery operations** — Run delivery without losing who owns the next step or the handoff.
- **Diner relationships** — Turn guest ordering history into repeat business without blurring consent.
- **Payments and plans** — Keep restaurant revenue and platform subscriptions in separate, traceable money flows.

## The problems it was built to solve

*stated — the seller's argument, given in full so you can judge it.*

### Every restaurant owns the ordering relationship from storefront to table.

When restaurants depend on a third-party marketplace for every digital order, the customer relationship starts outside their control. Menus drift, fees obscure the economics, and a repeat diner becomes an audience the restaurant cannot recognize or reach. The same fragmentation reaches the floor: table orders, pickup orders and delivery orders are treated as different businesses even though the same staff and kitchen must fulfill them. Over time, each channel adds another place to correct availability, explain a mistake and reconcile revenue. The restaurant needs one operating relationship with diners, not a collection of borrowed checkout surfaces.

### Every accepted order stays visible until the work is finished.

A busy service breaks down when the dining room, kitchen and counter no longer share the same sense of what is waiting. Staff call across the room, tickets are printed twice or not at all, and a shift closes with questions nobody can answer from the record. The damage is not limited to one late plate: diners lose confidence, the team starts maintaining a second system in its heads, and managers spend the quiet hours reconstructing the rush. Reliable order work means the next action remains clear even when attention is fragmented and the room is moving quickly.

### Delivery work stays accountable from acceptance through the final handoff.

Delivery becomes expensive when responsibility is ambiguous. An address may fall outside the area a restaurant can serve, two people may believe the same driver has the order, or a diner may have no useful answer after food leaves the kitchen. Each gap becomes a phone call, a remade meal or a refund that is difficult to explain. During a rush those exceptions multiply faster than a manager can resolve them, and drivers inherit disputes they did not create. A restaurant needs delivery to remain part of its operating record instead of becoming a separate chain of messages and guesses.

### Repeat business grows without treating every receipt as marketing consent.

Restaurants recognize regulars at the counter, but digital ordering often turns them back into anonymous transactions. Without a dependable history, promotions become broad discounts, reports cannot explain who is returning, and campaigns reach people who never asked to hear from the restaurant. That wastes margin and trust at the same time. The problem gets worse across locations, where the same diner can look like several unrelated records and each team invents its own outreach list. Growth depends on understanding repeat behavior while keeping the boundary between service communication and marketing permission unmistakable.

## What it takes to run it

*stated — external services the buyer supplies and pays for directly.*

- **Node.js host with Next.js 16.2.10 and React 19.2.3** (required) — The package does not declare a Node.js engine; select a runtime supported by this Next.js release.
- **Supabase** (required) — The Supabase JavaScript client is present in the product dependencies.
- **Scheduled-job runner** (required) — Wire the four schedules declared in `vercel.json`: scheduled tasks and Platea dispatch every minute, analytics maintenance daily at 02:15, and audience sync every six hours at minute 45. A non-Vercel host needs equivalent schedules.
- **Email delivery provider** (optional) — Provider adapters ship for Brevo, Mailgun, Resend, SendGrid and SMTP; configure the provider the installation will use.
- **Upstash** (optional) — The service is exposed as optional configuration in `.env.example`.
- **Sentry** (optional) — The service is exposed as optional configuration in `.env.example`.

## FAQ

**What exactly do I receive after purchase?**

The complete source repository behind the live demo — 199,116 lines across the application and its database, 88 tables defined by 110 migrations that the shipped scripts apply for you, plus the seed data, the demo accounts and the setup documentation. Not a subset and not a scaffold: the same code that runs the demo you just used.

**Is the live demo the same product whose source I receive?**

Yes. The Platea demo runs the delivered release (v1.0.0), and the build figures on this page are measured from that same source — not from a showcase build kept separately.

**Can I test every account role before buying?**

Yes — all 5 of them: Delivery driver, Kitchen staff, Restaurant owner, Shift manager, Platform operator. Each one is seeded in the live demo and reachable from the role board above, so you can inspect the product from the customer's side, the agent's side and the administrator's side before you decide.

**Is this a complete product or a starter template?**

Complete. 107 page modules and 391 HTTP operations, with authentication, roles, billing, an administration panel, background jobs and seeded demo data all wired and running. A template gives you the shape of an application; this is one you can deploy and start operating.

**Can I rebrand and modify it?**

Yes, without asking. The name, identity, copy, styling and code are yours to change. Rebranding and operating it as your own service is exactly what the licence is for.

**What does the licence allow?**

A perpetual, worldwide, non-exclusive, non-transferable licence to the product you bought and to every update released for it. The Standard licence covers one business — yours. If you deploy for clients, the Client licence covers up to five. You can modify it, rebrand it, deploy it and charge your own customers.

**Can I resell the source code?**

No. Reselling, redistributing, sublicensing or giving away the source itself is not permitted under either licence. You build and deliver products with it — the code stays with you.

**What services and ongoing costs are required?**

You bring your own accounts, so we never mark anything up and there is no ongoing cost to us beyond the purchase. Required: Node.js host with Next.js 16.2.10 and React 19.2.3, Supabase, Scheduled-job runner. Optional: Email delivery provider, Upstash, Sentry. The table above says exactly what stops working without each one; most have usable free tiers at low volume.

**How difficult is deployment?**

Two ways, and most buyers use the first. The installer in your saascode dashboard walks it: you create free accounts at Vercel and Supabase, connect them, and it provisions the database, applies 110 migrations, seeds the data, deploys and verifies the result — you watch the steps go green. Or take the source and do it yourself with the shipped scripts and docs, which is the same sequence run by hand.

**What updates and support are included?**

Updates to that product for as long as we maintain it — no renewal fee and no expiry date on your access. Support covers download problems, defects in the code as shipped, questions about what the product does and how it is structured, and licence questions. It does not cover debugging your own modifications, building features for you, or setting up your hosting and third-party accounts.

**Why does a complete codebase cost $199?**

Because it was built once and is distributed many times. SaaSCode builds each product and ships the same finished release through the catalog, so the price reflects repeatable distribution — not a reduced codebase, an unfinished template, or what the same work would cost commissioned.

**Do I need to be a developer?**

No, for the normal path. You create free accounts at Vercel and Supabase, connect them to the installer in your saascode dashboard, and it does the deployment for you — provision, migrate, seed, deploy, verify. What it asks of you is creating two accounts and copying a token, not writing code. If you would rather deploy it yourself, or host it somewhere else, the full source and the scripts are yours to do that with. Running the product day to day needs no technical skill at all: that happens through its own interface, which is what the demo shows.

## Licence

The buyer receives the complete source and may deploy, modify and operate it
as their own SaaS, charging their own customers. The source itself is not
resold or redistributed: you build and deliver **with** it, you do not sell **it**.

## What this document cannot tell you

Stated plainly because a review that misses it is not a review:

- code quality, duplication, or architectural consistency
- test coverage
- query performance under load
- security posture beyond what the stack implies
- how maintainable it will be in a year

Scope is measurable from outside; implementation quality is not. Anyone
evaluating this should say so rather than infer quality from size.

## Written about it

- [Platea: a direct-ordering and restaurant-operations SaaS](https://saascode.ai/inside/platea-direct-ordering-restaurant-operations-saas.md)
- [Best restaurant ordering platforms in 2026 | Choose by tenant model](https://saascode.ai/inside/best-restaurant-ordering-platforms-2026-tenant-model.md)
- [Platea vs Flipdish | Hosted ordering or restaurant SaaS source code](https://saascode.ai/inside/platea-vs-flipdish-hosted-ordering-restaurant-saas-source-code.md)

## Links

- Catalog page: https://saascode.ai/products/platea
- Product record: https://saascode.ai/inside/products/platea
- Live demo: https://platea.saascode.ai
- Every product: https://saascode.ai/llms.txt