Skip to main content
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.
You’ve used the app yourself as both an internal user and a test client
Empty states look intentional (no blank screens or placeholder text)
The notifications fire when you expect them to, and don’t fire when you don’t
Admin and staff users see what they should — and don’t see what they shouldn’t
Client view only shows the client’s own data, not other clients’ data
Any external integrations (Stripe, third-party APIs) are connected and tested
The app’s name and icon match what your team and clients will recognize

​
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. When you’re ready to bring the rest of the team in:
1

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

Open it in the visibility settings

Set the app to be visible to all internal users (or the relevant group).
3

Watch the first day

Be available for questions. The first day is when you’ll catch the issues your testing didn’t.

​
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.
1

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

Set the visibility

From the app’s settings, open the client visibility section and choose who sees it.
3

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 for what works after the first week.

​
Common pre-launch gotchas

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.
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.
Client visibility is off. Check the app’s visibility settings; client-facing apps default to hidden from clients until you turn them on.
The secret you provided during the build might be a test-mode credential. Swap it for the production credential and re-test.

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