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

# Launching apps

A custom-built app is installed in your workspace as soon as the build finishes. Launching is the separate decision of who can see it and use it. By default, new apps start hidden from clients while you test — you control when they become visible.

## Pre-launch checklist

Before you flip an app on for your team or your clients, run through this list. Most launch problems are caught here.

<Check>
  You've used the app yourself as both an internal user and a test client
</Check>

<Check>
  Empty states look intentional (no blank screens or placeholder text)
</Check>

<Check>
  The notifications fire when you expect them to, and don't fire when you don't
</Check>

<Check>
  Admin and staff users see what they should — and don't see what they shouldn't
</Check>

<Check>
  Client view only shows the client's own data, not other clients' data
</Check>

<Check>
  Any external integrations (Stripe, third-party APIs) are connected and tested
</Check>

<Check>
  The app's name and icon match what your team and clients will recognize
</Check>

## Going live for your team

Internal apps are typically visible to your team as soon as they install. If you want to test with a smaller group first, scope the visibility to specific internal users before the build finishes. See [Controlling app visibility](/docs/building-new-apps/controlling-app-visibility).

When you're ready to bring the rest of the team in:

<Steps>
  <Step title="Announce the app to your team">
    A Slack message or email with what the app does, who's using it, and where to send feedback. People use apps they know exist.
  </Step>

  <Step title="Open it in the visibility settings">
    Set the app to be visible to all internal users (or the relevant group).
  </Step>

  <Step title="Watch the first day">
    Be available for questions. The first day is when you'll catch the issues your testing didn't.
  </Step>
</Steps>

## Going live for clients

Client-facing apps need an extra step. Even after the app is installed, the client view stays hidden until you make it visible to clients.

<Steps>
  <Step title="Decide which clients see it">
    All clients? A subset? A single pilot client? Visibility supports all three. Start small if you can — the apps that succeed at scale usually launched to a few clients first.
  </Step>

  <Step title="Set the visibility">
    From the app's settings, open the client visibility section and choose who sees it.
  </Step>

  <Step title="Let clients know it's there">
    Even with the app visible in their Portal, clients may not notice until you tell them. A short email — "we built a new tool for X, log in to use it" — tends to drive the first session better than relying on discovery.

    See [Driving adoption](/docs/rolling-out-to-clients/driving-adoption) for what works after the first week.
  </Step>
</Steps>

## Common pre-launch gotchas

<AccordionGroup>
  <Accordion title="The app works but the empty state is broken">
    You tested with data; your first real client has no data. The empty state matters more than you think. If it's a blank page, go back to the build chat and ask for a useful empty state.
  </Accordion>

  <Accordion title="Notifications work for you but not for staff">
    Your test client was set up under your own account. The notification firing rules might assume the assigned internal user receives them — which is you. Real clients assigned to real staff will surface this. Test with a colleague before launch.
  </Accordion>

  <Accordion title="The app shows up in the Dashboard but not the Portal">
    Client visibility is off. Check the app's visibility settings; client-facing apps default to hidden from clients until you turn them on.
  </Accordion>

  <Accordion title="An external API works in the test environment but fails in production">
    The secret you provided during the build might be a test-mode credential. Swap it for the production credential and re-test.
  </Accordion>
</AccordionGroup>

## After launch

Custom-built apps aren't done at launch. Most apps need a round or two of iteration once real clients start using them. Plan for that — block a half hour the week after launch to address the small things that surface.