Send customers a working prototype, not a deck

The workflow

1. Translate the sales or discovery notes into one decision the customer needs to make. Separate confirmed requirements from assumptions, and choose a workflow small enough that someone can complete it in a few minutes without instruction.
2. Give the agent this kind of prompt: Build a working onboarding prototype for Acme's operations lead. Create a three-step intake flow, a review screen and a confirmation state. Use clearly labeled sample data, add an assumptions panel, require no login, and collect no real customer information. Prepare a short task list for the reviewer.
3. Ask for a static page when interaction can be simulated in the browser. Use a full app with Postgres only when the customer must create and revisit records. Add login only for identity-specific behavior. Do not add a scheduled job unless timing is part of the concept being tested.
4. Review the result for accidental promises. Mark every mocked integration, sample record and nonfunctional control. Remove confidential notes from the source folder. A prototype should make uncertainty visible rather than presenting unbuilt behavior as complete.
5. Push and checkpoint the files, then choose password-protected or invited-person sharing for a named customer. Use a public link only when the content is safe for anyone holding the address. A Pro CNAME custom domain is optional when a branded address materially helps the review.
6. Send the URL with three tasks, not a narrated tour. Ask the customer to comment where wording, order or behavior is wrong. Let the agent read those comments, revise the same workspace and publish another checkpoint without changing the place the customer opens.

Setup

grain login
mkdir customer-onboarding-prototype
cd customer-onboarding-prototype
grain init
# Give the agent the scoped prototype prompt.
grain push
grain checkpoint -m "customer review one"
grain share --password <pw>

Download the Mac app before running the sequence. For the sample onboarding flow, the pieces are a page with interactive states and a password-protected link. It uses no Postgres, login, scheduled job or custom domain because the prompt forbids real records and identity-specific behavior. If the customer must return to saved entries, promote the prototype to a full app and use Postgres. If each reviewer needs an identity, add login and invite them. If branding matters enough to pay for it, Pro supports a CNAME custom domain. Make each addition answer a testable need instead of treating infrastructure as polish.

What you get

• A customer can complete the proposed interaction instead of interpreting arrows, screenshots and presenter notes in a deck.
• A stable address that remains available after the agent session and laptop close, so the customer can review on their own schedule.
• Public, password-protected or invited-person sharing selected to match the sensitivity and audience of the prototype.
• Visible assumptions, sample data and missing integrations placed beside the interaction they qualify.
• Comments on the artifact that the coding agent can read and turn into a focused revision request.
• A path from static page to a full app with Postgres, login and scheduled jobs when the next review genuinely needs them.
• Exportable files and named checkpoints, while the same workspace keeps the revisions connected.

Proof

Prove the prototype by testing the customer's task, not by counting generated screens. Open the link in a signed-out browser, enter the password, follow all three steps and verify that no real data is stored. Leave a comment on a confusing control and confirm that the agent can read it. Close the authoring session and reopen the same URL later. Grain's allowed product claims are that published artifacts stay published, readers can comment, and full apps may use Postgres, logins and scheduled jobs. Whether the concept is valuable remains a customer finding. Record what the customer could complete and where they stopped rather than inventing a conversion claim.

Limits

• A prototype is not a commitment that every path, integration, security control or edge case exists. Label the boundary in the artifact and in the message that carries its URL.
• Do not load real customer information merely to make the sample look credible. Use clearly marked fictional data unless the full data handling review has occurred.
• Password access is a shared secret, not individual identity. Use invited-person sharing and app login when the distinction between users matters.
• Comments improve the revision loop but do not replace a decision record. Summarize accepted and rejected feedback in the system where the project is tracked.
• Custom domains require Pro. The default share address is sufficient to test the workflow and should be the starting point.
• Grain is not a general production deployment platform. Move a customer-facing production service to the appropriate operational path when its requirements exceed an artifact workspace.

Frequently asked questions