Inviting a client

You built a site for somebody and they pay you every month for it. They cannot see the thing they are paying for, so every question about it comes to you by email.

Invite them as a client. They get an account of their own and one page: the status page of that one App. Nothing else.

What they see

One page, for the App you invited them to:

• whether the site is working
• the address it answers at, and whether the custom domain is set up
• whether visits have been failing lately, in words rather than numbers
• when the site last changed
• one plain sentence about anything that is wrong

It is the same page you read yourself. There is no smaller version of your dashboard behind it.

Their list of sites

When they sign in, they land on a list of the sites they watch, in name order. Each row is one site and says:

• whether it is working, with the same dot and the same sentence as its status page
• the address it answers at
• who looks after it, which is your workspace’s name

A row opens that site’s status page. If one site cannot be read for a moment, its row says so and the other rows still show their state.

What they do not see

This is the half to read before you invite anybody.

• Your other Apps. They see the one App you invited them to and no other, in this workspace or any other.
• Your logs. Not a request body, not a response body, not an error trace. A captured log body can hold your client’s own end users’ personal data, a third-party payload and your debugging, and handing that to somebody by default is not a decision we make for you.
• Your environment variables. Not the values and not the names.
• Your plan, your usage, your invoice. They never learn what you pay or what you have spent.
• Your deploy credentials, your schedules, your uploads, your settings.
• Anything they can change. There is no button on their page. They cannot deploy, pause, rename, delete or configure anything.

What it costs

Nothing. A client is not a seat and never appears on your invoice, however many you invite.

How to invite one

Open the App in the dashboard, go to Clients, and choose Invite a client. Type their email address and send it. There is nothing else to pick: the App is the one you are on, and a client holds no standing in your workspace.

They get an email with a link. Opening it signs them in, creates their account if they do not have one, and puts the site on their page. The email names the site, not your workspace. They never join it. The link works for fourteen days. After that it stops working, and whoever opens it is told the invitation expired and who sent it. Invite them again to send a fresh link.

Until they open the link they sit on the Clients tab as Pending, with how long the link has left. Cancel invitation takes the offer back.

Inviting somebody needs the write:members capability, which owner and admin carry. Without it the Clients tab is not on the App at all. A deploy credential cannot send an invitation, whatever it carries. Inviting a person is not something a pipeline does.

Revoking their access

The work stops, so the access stops. Open the App, go to Clients, and revoke their access there. That page lists everybody who can see the App, so you are not doing it blind.

Their next visit to the page is refused. Nothing is left over: no link that still works, no half-open page.

Two acts sit on that page and they are not the same one:

• Revoke access is for somebody who accepted and is watching the site now.
• Cancel invitation is for somebody who was invited and never opened the link. It kills the link. Nobody was watching, so nothing they can see changes.

Revoking somebody’s access does not touch their account. It is theirs, and a site another developer built for them keeps working exactly as it did. If the work starts up again, invite them again.

Revoking access needs write:members, the same capability inviting does. Deciding who may look at a site is the other half of asking them to.

The account is theirs, not yours

A client’s account belongs to them, not to your workspace. If they also pay somebody else to run a second site and that person invites them too, they see both sites on one page, and neither of you sees the other’s work.

It is a real account rather than a link you sent. A link gets forwarded, pasted into a group chat and outlives the work; an account is one person, and it is the same account that can one day be handed the App itself. It is theirs to erase, too: Account, at the top of their page, is where they do it.

It is also an account that can build. A client who decides they want a site of their own has a link on their page to name a workspace, and they get one on the same account. That is their decision, not yours, and it takes nothing from you: the access you gave them is still yours alone to revoke.

Naming one takes nothing from them either. The sites they watch stay theirs, and once they have a workspace they reach them from the account menu rather than from the page they used to land on. It works the same way from the other side: somebody who already runs a workspace here can accept your invitation and watch your site from the account they already have.

Handing the App over

The work ends and the site stays up. You hand the App to your client’s own workspace, and it answers at the same address the whole way through. Nothing goes dark, nothing is rebuilt, and nobody edits a DNS record.

Before you offer it

The App needs a custom domain that is already serving, on a name your client owns. The address this platform gives an App carries your workspace name, so an App handed over without a name of the client’s own would change address the moment it changed hands. That is the one thing this exists to prevent, so the offer is refused rather than allowed to break it.

Handing an App over is the owner’s act. An admin cannot make the offer, and neither can a deploy credential, whatever it carries. A pipeline does not give a client away.

Making the offer

Offer the App to an email address:

curl -X POST https://api.wawesome.io/v1/apps/{app}/transfer \
  -H "authorization: Bearer $TOKEN" \
  -d '{"email":"them@example.com"}'

The answer states what will move, and it names every environment variable the App holds. Read that list. If one of them is your own provider key rather than the client’s, rotate it before they accept: the values go with the App.

Nothing has moved yet. The App is still yours, still serving, still counted against your App slots, and you can still deploy into it. The offer stands for fourteen days, and taking it back costs nothing.

What happens when they accept

They open the link, agree to the terms and choose what the App is called in their workspace. Somebody who is not on a paid plan gets thirty days free, on a plan that carries the custom domain and the schedules the App arrives with — in a workspace made for them if they have none, or in the one they already have. Somebody who already pays keeps the plan they pay for. The site keeps answering after those days at its own address. If they end with no plan chosen, the custom domain stops 30 days after we email them, as custom domains describes.

From that moment your deploys into that App are refused. Nothing else stops: the site answers, its schedules fire, its invocations run and its custom domain keeps serving. Every file the App needs is copied into their workspace meanwhile, which takes as long as the site is large.

When the last file has landed, the App moves in one step. Before it the App is entirely yours, after it entirely theirs, and there is no moment in between that a visitor or either of you can see.

If the copy cannot finish inside a day the transfer is called off. Nothing moved, nothing was deleted, your deploys work again, and both of you are told.

What arrives

• every Function and every version, so a rollback still works
• the files it serves, and the private files its handlers read
• the environment, secrets included, with nothing to re-enter and nothing to re-encrypt
• the schedules
• the custom domain, and a domain still coming up
• the egress allowlist
• what the App has run, without the log bodies

What stays with you

• The log bodies. They can hold your client’s own end users’ personal data, and they were captured while you were running the site. An invocation from before the handover reads on their side as a run with no body kept, which is what an old one already reads as.
• The usage you were billed on. An invoice already sent does not change hands.

What ends

• Every client watching that App, your client included. They own it now, and owner and client of one App at once is not a standing anybody holds.
• Any deploy credential of yours restricted to that App. One restricted to it and nothing else is revoked outright: a credential naming no App reaches every App, and we will not widen one on the way out.
• Your pipeline. Deploys to that App from your workspace are refused from acceptance onwards. A build that starts failing at three in the morning is this, not an outage.

Both workspaces get an email when the App lands.

Afterwards

The name goes free. You can create a new App at the slug you gave up straight away.

There is no undo. If the two of you decide the App should come back, they hand it to you the same way.