> ## 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.

# When to Create a Separate App

> Decide whether a second experience belongs in this app or needs its own Stardeck app

Start from the product boundary, not from the communication mechanism.

Most of the time, one product should be [one Stardeck app](/app-structure/overview) with [Surfaces](/app-structure/surfaces) for distinct audiences and devices. A second app is the exception.

## Surfaces first

Different audience or device alone usually means a Surface, not another app:

| Need                                     | Prefer                                  |
| ---------------------------------------- | --------------------------------------- |
| Customer site + staff admin              | Surfaces in one app                     |
| POS on an iPad + kitchen display         | Surfaces in one restaurant system       |
| Marketing site + customer portal         | Surfaces in one booking product         |
| Public storefront + internal ops console | Surfaces with different access postures |

Those experiences share product ownership, data, and release cadence. Keeping them together avoids duplicate deploys, duplicated validation, and unnecessary cross-app wiring.

## When a second app earns independence

Create a separate Stardeck app when at least one of these is true:

| Boundary                         | Example                                                                   |
| -------------------------------- | ------------------------------------------------------------------------- |
| **Separate product**             | An independently owned accounting product next to your storefront         |
| **Tenant or ownership boundary** | A partner-operated fulfillment system your team does not own              |
| **Different data model**         | Systems that would only share occasional events, not the same core tables |
| **Different release cadence**    | A product that must ship and roll back independently of the first         |

If none of those apply, keep the work in the current app and add a Surface or (with Alpha access) a [Module](/app-structure/modules).

## Decision table

| Question                                            | Same app | Separate app                              |
| --------------------------------------------------- | -------- | ----------------------------------------- |
| Same product ownership?                             | Yes      | No                                        |
| Same core data model and day-to-day release train?  | Yes      | No                                        |
| Mainly a different audience or device?              | Surface  | —                                         |
| Needs its own launch URL / icon / access posture?   | Surface  | Only if the product itself is independent |
| Would you want to ship or pause them independently? | Rarely   | Yes                                       |

## After you decide they are separate

Only once the systems are genuinely independent, choose how they share work:

* **Shared Data Store** — when separate apps truly need the same underlying tables. See [Data Stores](/data-stores/overview).
* **Cross-app communication** — when independent apps need to call each other's APIs or trigger actions. See [Cross-App Communication](/cross-app/overview) and [Cross-App Calls vs Shared Data Stores](/cross-app/when-to-use).

Do not start at those mechanism pages for tightly coupled experiences. Decide the product boundary here first.