Vibe coding
Run a customer-journey demo that tests the app's real work
Demonstrate creation, owner action and return visits using one record that can be followed throughout.
Zocri · 2 min read · Sources checked
Give the demonstration a single thread
Cucumber's reference emphasizes observable outcomes when describing a scenario's expected result. Build the demo around one identifiable business item, such as an equipment request. A visitor submits it, a coordinator reviews it and the visitor returns to see the decision. Following the same record makes missing handoffs easier to notice.
Prepare a short script with a starting state and expected result for each role. Use invented information and a distinctive request name. Keep the script visible to observers so they can tell whether a polished screen is part of the requested journey or an unrelated feature.
Include the owner's work
After submission, switch to the coordinator's view. Find the request without using a hidden shortcut, inspect the details and approve or reject it according to the stated rule. Show how the coordinator corrects an ordinary mistake, such as assigning the wrong pickup time.
Ask the owner to perform at least one action themselves. Their hesitation may reveal a missing label, unclear state or awkward search flow. Record those observations as findings rather than narrating over them. The person operating the app often notices work that a guided presentation skips.
Return as the original customer
Refresh the customer view or sign in again and confirm that the decision appears on the correct request. Check the message the customer receives if messaging is part of the scope. State clearly whether a real delivery, a test service or a visual stand-in was used.
Then show one ordinary exception, such as unavailable equipment or a request missing required information. Demonstrate the next useful action instead of ending at an error. A customer should understand whether to edit, wait or contact someone, and the owner should know whether work remains pending.
Turn the demo into a decision
End with a record of observed outcomes and open questions. Separate a confusing layout from a failed business rule, because their urgency may differ. Mark any skipped role, device or external connection as untested rather than assuming it behaves like the demonstrated path.
Use the findings to choose a small next change or approve a limited pilot. Preserve the script and sample data for later reviews. A good demonstration helps people understand both what works and what still needs evidence, while leaving room for a more complete technical review where appropriate.