Platea
Platea is a multi-tenant direct-ordering and restaurant-operations SaaS with full source code included.
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.
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.
- Direct ordering
- Table QR
- Tenant branding
- Online payments
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.
- Kitchen display
- Managed printing
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.
- Delivery operations
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.
- Diner CRM
- Promotions (Percentage, fixed-amount and free-delivery promotions with time windows and immutable order snapshots)
- Email campaigns (Email campaigns from the restaurant support email, with consent checks, suppression controls and send tracking)
- Basic reports
Printing works in three modes behind one adapter:
Delivery zones are drawn as polygons or set as a radius around a location, each with its own delivery fee and minimum order value. An address outside every active zone cannot place a delivery order.
Address checking. Delivery addresses are resolved through a geocoding provider, which is configuration rather than a fixed part of the product — Google, Mapbox or an OpenStreetMap-based service can be the primary, with a fallback behind it. A result below the configured confidence threshold blocks the delivery instead of guessing a location. If diners report addresses being rejected, that threshold and the choice of provider are what to look at; it is working as designed, not failing.
Drivers are staff members with the driver role, assigned to specific locations. A delivery is assigned to a driver with version control: if two managers assign the same delivery at the same moment, exactly one wins and the other is told to re-read rather than silently overwriting. Deliveries move through unassigned, assigned, accepted, picked_up, en_route, delivered, and can end failed or cancelled.
Drivers see only the deliveries assigned to them and can only make the travel steps their role permits.
Diner tracking. Every order gets a private tracking link scoped by token — no account, no login, and it only shows that one order. Delivery completion records a proof timestamp.
Delivery operations (zones, drivers, tracking) are available on the Operacion and Grupo plans.
The platform underneath the product — counted in this product's own source, not claimed from a template. Where a row carries a list, open it to read the names behind the number.
Coinbase
dLocal
Flutterwave
Komoju
Mollie
NOWPayments
Opn
Paystack
ActiveCampaign
Customer.io
Segment
Canny
Amplitude
Custom Head Scripts
Pushover
Twilio SMS
Crisp
Tawk.to
Monday.com
fal.ai
Axiom
hCaptcha
Freshsales
Pipedrive
Pabbly Connect
AWS S3
MuxHover a table to isolate what it touches; click one to read its relationships. The big nodes are what everything else hangs off. organizations is referenced by 75 tables because every single record in this product belongs to an organization, and that is what makes tenant isolation a property of the database rather than something the application has to remember on every query.
all 88 tables, as text
active_boosts · admin_notifications · analytics_daily · analytics_events · analytics_funnels · announcement_dismissals · announcements · api_key_logs · api_keys · assistant_actions · assistant_conversations · assistant_messages · assistant_usage · audit_logs · automation_log · automation_templates · campaign_recipients · campaigns · cart_items · carts · closure_exceptions · credit_balances · credit_transactions · currencies · data_exports · data_imports · deliveries · delivery_status_events · delivery_zones · diner_consents · diners · faq_categories · faq_items · feature_flags · inbound_webhook_events · inbound_webhooks · languages · locations · marketing_audience_members · marketing_audiences · menu_categories · menu_item_modifier_groups · menu_items · menus · modifier_groups · modifier_options · notification_log · notification_rules · notifications · order_item_modifiers · order_items · order_status_events · orders · organization_limit_overrides · organizations · payment_events · plans · platform_secrets · platform_settings · print_jobs · printer_workstations · product_purchases · products · promotion_redemptions · promotions · provider_prices · push_devices · report_templates · restaurant_brands · restaurant_payment_accounts · restaurant_profiles · restaurant_tables · roles · scheduled_tasks · seo_meta · service_hours · shift_reconciliations · staff_location_assignments · subscriptions · table_tokens · theme_page_sections · theme_section_library · theme_sections · translations · user_sessions · users · webhook_logs · webhooks
The chassis, and anything particular to this product. 3 required, 3 optional.
The package does not declare a Node.js engine; select a runtime supported by this Next.js release.
The Supabase JavaScript client is present in the product dependencies.
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.
Provider adapters ship for Brevo, Mailgun, Resend, SendGrid and SMTP; configure the provider the installation will use.
The service is exposed as optional configuration in `.env.example`.
The service is exposed as optional configuration in `.env.example`.
Already built — plug and play
Every provider integration in this list ships wired into the product. You bring your own keys, connect them in the admin, and go live — there is no integration code to write. Nothing is resold through us: the ongoing cost is whatever these providers charge you. Capabilities marked plan-gated elsewhere on this page unlock by plan, not by extra code.
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.