> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stardeck.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Guide: Restaurant Surfaces

> Build customer ordering, POS, kitchen display, and back office as Surfaces of one restaurant system

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](/app-structure/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](/app-structure/overview) and [When to Create a Separate App](/app-structure/separate-apps).

## 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](/app-structure/surfaces) and [App Visibility](/app-visibility).

## Publish once, launch many

1. Review each Surface in preview.
2. Commit or **Sync** so the Surfaces card lists them (**Not deployed yet** until publish).
3. **Publish** the app — one publish ships all ready Surfaces.
4. 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](/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](/cross-app/overview) for genuinely independent products — for example a separately owned accounting or fulfillment system.