Guide: Restaurant Surfaces - Stardeck Documentation

This guide builds one restaurant operations product as a single Stardeck app with four Surfaces:

Surface	Audience	Typical access
Customer ordering	Diners / takeout customers	Public
POS	Counter staff on iPads	Internal (plus staff permission check)
Kitchen display	Kitchen team	Internal (plus kitchen permission check)
Back office	Managers	Internal (plus manager permission check)

You publish the restaurant system once. Each Surface still launches with its own name, URL, and icon. Modules (Alpha) can supply reusable capabilities such as orders or payments for selected organizations, but they are optional for this example. The point is the Surface structure.

Why one app

Customer ordering, POS, kitchen display, and back office share the same menu, orders, and operational cadence. They are different experiences of one product — not independent products. See One Product, One App and When to Create a Separate App.

Ask the agent

In the project chat, start with the product, then add Surfaces:

Build a restaurant system with shared menu and orders. Add four Surfaces:
1) public customer ordering, 2) internal POS for iPads, 3) internal kitchen display,
4) internal back office for managers. Staff Surfaces should require the right roles —
internal access alone is not enough.

Useful follow-ups:

Make the POS open straight into the order screen and use a clear home-screen icon for iPads

On the kitchen display, show open tickets and let the kitchen mark items ready

Restrict back office to managers with an in-app permission check

Public vs internal, and permission checks

Keep customer ordering public if guests should reach it without signing into Stardeck.
Keep POS, kitchen display, and back office internal so only signed-in organization members can open those Surface URLs.
Remember: internal is authentication, not admin authorization. Any org member can open an internal Surface unless the Surface itself checks permissions. Ask the agent to gate restricted staff areas and their API routes.

If the whole restaurant system must stay off the public internet, set the app visibility to internal or private. Project visibility dominates Surface access — see Surfaces and App Visibility.

Publish once, launch many

Review each Surface in preview.
Commit or Sync so the Surfaces card lists them (Not deployed yet until publish).
Publish the app — one publish ships all ready Surfaces.
When a Surface shows Live, use Launch, or pin it with its own PWA name/icon for floor devices.

Non-root Surface URLs become available after production deploy. For iPad POS or kitchen tablets, turn Show app shell off on those internal Surfaces and Add to Home Screen so each station feels like its own app.

What this replaces

Older guidance treated POS and kitchen display as separate Stardeck apps talking over cross-app calls. For one restaurant operation, prefer Surfaces in a single app. Reserve cross-app communication for genuinely independent products — for example a separately owned accounting or fulfillment system.

​Why one app

​Ask the agent

​Public vs internal, and permission checks

​Publish once, launch many

​What this replaces

Why one app

Ask the agent

Public vs internal, and permission checks

Publish once, launch many

What this replaces