How to Make a Softr App Review Walkthrough

What should a softr walkthrough prove?

It should prove the exact acceptance path running from setup through confirmation. Treat the walkthrough as an acceptance artifact. Every included action should help the implementation owner decide whether the request was met. The proof is stronger when the starting state contains believable fictional data and the acceptance outcome changes in a way that can be recognized without explanation.

Avoid beginning by listing screens. Begin with a sentence a viewer could test: a person selects a record, changes an approved field, and sees the confirmed result. The exact action depends on the reviewed build, but the editorial shape stays narrow. One coherent outcome is easier to judge than several disconnected clicks.

How should you prepare the reviewed build before rendering?

Prepare the reviewed build like a repeatable test fixture. Open the route named in the request, create only the fictional records needed for that case, and return every toggle or status to its starting value. Run the path once, then restore the initial state so the recorded attempt does not begin after the result has already occurred.

If the reviewed build sits behind a login, create a dedicated demo account with only the access the acceptance path needs. GogoScreen credentials are encrypted, used for a single render, then deleted. When a storyboard is planned first, the credentials are kept encrypted for that session and deleted at most two hours after their last use. Do not use a customer account, customer URL, or unreleased customer data for public material.

Write the hint in the language of the acceptance test. “Change the booking to confirmed and show the confirmed status” gives the run an observable finish. A phrase such as “review the new booking feature” leaves the action and evidence undecided. Keep implementation history in the issue, not in the browser instruction.

How should you review the first render?

Review the first render against the original request, not against your memory of the implementation. Put the request, the expected result, and the MP4 side by side. A passing video makes the relevant role, starting record, action, and final condition visible without requiring the reviewer to infer missing state.

Record a verdict for each acceptance element:

• Role: the account shown has the access named in the request.
• Fixture: the fictional record begins in the required state.
• Action: the requested control and resulting change are visible.
• Evidence: the final screen proves the expected condition.
• Fidelity: narration and captions describe the event that occurred.

If a run fails or the review evidence needs correction, retry after fixing the source state or narrowing the hint. Roughly one render in five fails or needs a retry. Time is held when you submit and used only when a render succeeds. Failure, refusal, or abandonment returns the time it held automatically, without a support request.

What should you disclose and avoid claiming?

The footage is a recording of the real app, not a mockup, while the narration is generated. If the published cut includes generated voiceover, follow the project's disclosure and media marking requirements. A muted cut with the audio track removed does not contain that synthetic voice component.

Do not promise that every Softr app will render successfully. Reachability, account state, interface behavior, and the chosen flow all matter. Do not say the system understands or watches the reviewed build. It records the real app, not a mockup, as it works through the flow. That plain description gives the implementation owner a more accurate expectation.

Every new account gets 60 seconds of video once, watermarked, with email verification required to download. After that, videos use time from a plan or a top up, and top up time never expires. Check the current plans and top ups before planning repeated review preparation, but keep the editorial decision separate from buying time.