Review a prototype with your team
Turn a working screen into a testable decision.
Start with one real workflow
For example: a customer-success manager needs to identify overdue onboarding tasks and assign the next action. Build that flow with fictional customers. Write down what success looks like before asking for feedback.
Publish, then capture
- Open your app in the builder and publish its static version. Check the published address first.
- Open Reviews for the same workspace. Choose the app and enter a review title, the question you want answered, and concrete tasks.
- Choose Vibeforce or Openbook as the review destination. For Openbook, select the organization, space and a Proofing room available to your account.
- Click Capture published version. The capture freezes the published files and creates a private reviewer link.
- Open that link in a separate session and complete the tasks before sharing it.
Publishing changes the public app. Capturing makes a fixed review version. Rebuilding alone does not update an earlier capture.
Give reviewers a useful task
Ask: “Find the overdue customer, assign the next action, and explain why the progress percentage changed.” Avoid asking only whether the screen looks good.
Reviewers try the prototype, choose completed, blocked or unclear, and describe what they expected and what happened. Use fictional data. The private link grants access to whoever holds it until expiry or revocation.
Close the loop
Read feedback in the selected destination, make the change in the builder, publish again, and capture a new version. Re-test the same task. Record the decision and remaining issues; use Openbook's proofing workflow when that is the selected destination.
Version 1 and version 2 are separate snapshots. They are not proof that AI developed or tested the change. Source history, reviewer feedback and a human approval answer different questions.
What a frozen review cannot test
Snapshots are static and block network requests and form submissions. They cannot validate real sign-in, payments, email delivery or database permissions. Client-side interactions must be implemented in the prototype to produce visible results. A button that does nothing is a defect to fix, not a successful test.
Test backend behavior in a running environment with separate test accounts. See feature availability.