Your app works while you are sitting beside the person using it. The next question is whether they can do their part when you step away.
Before sending an editor link, name the task. Someone correcting a heading needs a different working surface from someone updating a request, checking their own reply or commenting on the wording. Giving everyone builder access can hide a missing app workflow instead of solving it.
This is Part 5, Launch and show what works. The output is one maintenance handoff card: the recipient's task, the surface they need, the result to look for and the evidence still missing. Use it with an existing Overskill app. You do not need to start another build to make this decision.
Download the app-maintenance handoff card for four filled preparation examples and a blank card to reuse.
Choose the surface from the task
Overskill's workspace collaboration and the users of an app you build are separate. The current invitation help explains that an editor link does not grant editing access. It also describes app-specific sharing as conditional: check the actual account's scope before an authorized invitation. The team roles guide owns the role definitions and controls.
Use that distinction to choose a task entrance:
Scroll horizontally to compare all columns.
| Recipient's job | Working surface to assess | Evidence that matters |
|---|---|---|
| Maintain the app's heading | Overskill workspace/editor, with authorized scope | The recipient makes the agreed preview change and identifies the live version |
| Operate a request | Generated app with the required operator behavior | The permitted sample update survives reload |
| Try the customer journey | Generated app's customer account or permitted route | The recipient finds their own sample request and reply |
| Review wording | Checked harmless preview/demo or static presentation | The recipient identifies the revision and gives the requested observation |
These are four decisions, not four built-in Overskill roles. The two app-user tasks share an app entrance, but need different records and actions. “Operator” in your plan does not mean the generated app already implements that permission.
Prepare one small task the recipient can finish
Consider a fictional app called Service Desk Practice. Its owner, Mina, is preparing four handoffs. Nothing in this example has been executed: the app, people and records are invented, and every observed result on the card is Not tested.
Rae maintains the app. The task is to change “Request a visit” to “Request a service visit,” show the change in preview and stop before publishing. Mina first needs an authorized administrator to establish the available access scope. If the task requires one-app access, a whole-workspace invitation is not an acceptable assumption. Rae's eventual evidence should show the intended app and preview revision, with the live version identified separately.
Noor operates the service desk. The task is to change sample request DEMO-17 from New to In review, then reload. Those status choices and the operator workflow must exist in this app before the test. If Noor can only do the work by opening the builder, the intended app workflow has not been demonstrated. Record the missing behavior rather than replacing it with a broader invitation.
Alex tests the customer journey. The task is to open sample request DEMO-18 and find “Please choose a morning or afternoon visit.” Alex then explains where a later reply would appear. This checks whether the customer can find useful information. It does not prove that another customer's records are protected; use the separate private-record access checks for that.
Sam reviews the copy. The task is to read the new heading and write one sentence about the kind of visit expected. A checked static presentation may be sufficient. Do not share a functioning preview simply because it is convenient: the preview and live help warns that they share data by default. A preview link is not inherently read-only. Check what it exposes; if technically view-only access is required and unverified, stop or choose a safer presentation.
Let the recipient attempt it
Put the expected result on the card before the attempt. Use a harmless sample setup and the recipient's own authorized account where an account is needed. Label editor, live and preview addresses separately so the person does not have to infer which is which.
Then give them the task and let them work. If you point to every button, record that assistance. If you take over the mouse and finish, record that too. You have learned something useful about the handoff, but you have not yet shown that the recipient can do it independently.
For a saved update, record the result after reload. For a copy review, record the revision and the actual observation. For a builder task, record the agreed change and whether it stayed in preview. “Opened the link” is too little evidence for any of those outcomes.
Keep expected and observed results in separate fields. Unknown access scope, missing app behavior and a blocked attempt each need a next action and an owner. None should silently become a passed result because the plan sounds reasonable.
Turn the gap into the next useful action
Start with the existing app and the downloaded card. Pick the handoff that matters now; you do not need to rehearse all four examples. If access scope is unresolved, consult the authorized administrator and current help. If app-user behavior is missing, give the existing app's chat the exact task, permitted actor, sample input and expected saved result, then test the result.
For example: “Assigned service-desk staff need to move a sample request from New to In review and see that status after reload. Customers can read only their own permitted requests. Define and test those rules before using real records.” This is a build requirement, not a claim that naming roles enforces them.
If a separate build is appropriate, use the brief builder, edit its input fields and review the generated brief before choosing Start build. Copy brief is a secondary way to carry the requirement elsewhere. The link imports no card or records and does not change your existing app.
For the broader client handoff, keep the MCP build and handoff guide as the owner of the runbook. For launch readiness, return to the launch checklist. This rehearsal answers a narrower question: can this recipient complete this maintenance task through the appropriate surface, with evidence you can inspect?