Build apps for clients

If you build apps for other people, Launchpad can show your clients the work that keeps their app running, under your name rather than ours, and hand the app over cleanly when the job ends.

On every plan, a project can name its client and has a private monthly report. Builder, Studio and the Launch pass add your studio's name on those pages, and the monthly email to the client.

Your studio name

Set it once in Account → Your studio name. Every client-facing page and email then carries it:

• the monthly client report;
• the project's public status page, which shows your name and none of Launchpad's;
• the report email, sent from your name, with replies going to your own email address.

Without a studio name, reports are signed with your GitHub username, and status pages stay Launchpad's.

Naming the client

On a project's page, Client takes the client's name and email. The name shows on the project's card in your console, so you can tell twenty client sites apart at a glance.

The monthly report

Saving a client makes a private report link for the project. The report covers one calendar month (UTC):

• Availability: the share of 5-minute checks that passed, for the website and each other part that's checked, with the time it was down.
• Outages: each one, when it started and how long it lasted.
• Maintenance: how many updates were deployed, and how many were stopped before going live (the site kept running the previous version).

It shows nothing from the app's settings: no keys, code, logs or variables. Anyone with the link can read the report, so share it only with the client. Make a new link on the project page turns off the old one.

The report opens on the current month so far, and can switch to the previous two (uptime history is kept for 90 days). Print it, or save it as a PDF from the browser, to attach it to an invoice.

Tick Email them the report on the 1st of each month and the client gets last month's summary and the link early on the 1st, once a month.

Your team, and your client

On the Studio plan, a project's Team section invites people by email, each with a role:

Role	Can
Can view	See the project, its deploys, logs, uptime and errors
Can deploy	Also deploy, re-check and roll back
Admin	Also change settings, secrets, the domain and the team (except other admins)
Owner	Also delete the project or remove it from Launchpad, and make admins

The invitation is a link, emailed to them and shown to you to copy. It works once, for a week, and the person opening it signs in with GitHub and joins, so send it only to the person it's for. Revoke stops a link that hasn't been used. Anyone can leave a project, and admins can remove people.

Deploys always run with the owner's provider accounts and count towards the owner's plan. Teammates never see those accounts or any secret values, only the names of variables. People already on a project keep their access if the owner leaves Studio; only new invitations need it. A client who should only watch the app is best as Can view.

Handing an app over

When the client is to own the app outright, move each part into their accounts. Doing it this way means the app never goes offline:

1. Domain. The client should own the domain at their own registrar from the start. If you bought it, transfer it to them first.
2. Repository. Transfer the GitHub repository to the client's account or organization, or add them as an owner.
3. Hosting and database. Vercel, Neon and Supabase can each move a project to another team or organization. The client invites you to theirs, you move the project across, and the client then removes you. The app, its data and its address stay the same.
4. Billing. Check each provider now bills the client's card, not yours.
5. Launchpad. On the project's page, under the delete section, use Remove from Launchpad, keep it running. Launchpad stops managing it and forgets the keys it held for it, and touches nothing at your providers. Don't use Delete project for a handover: that deletes the hosting, the database and its data.

The client can then connect their own accounts to their own Launchpad console and import the repository, to keep the monitoring and one-click deploys.

Keeping the work

If you look after the app instead, which is the usual arrangement for a monthly retainer, keep it in your console. The report, uptime checks and alerts go on as they are, and the report is a record of the maintenance you're billing for.