Test a prototype before you call it finished

Make a tiny fixture set

Create three clearly fictional examples: a normal request, an incomplete request and a request with a long name or description. Write the expected outcome for each before running it. Keep the examples recognizable so you can distinguish old test records from new ones. Use an isolated test environment wherever the platform supports one and avoid triggering real customer notifications.

Inspect saved state, not just a toast

After a successful submission, reload and find the record through the normal interface. Check the fields and identity, not just the count. Then edit one field and verify that unrelated values remain intact. A green confirmation message is useful feedback but cannot establish persistence by itself. Capture the observed result when it differs from the brief instead of repeatedly clicking submit.

Interrupt the workflow deliberately

Try navigating away before a slow action finishes, returning to the page and checking the original result. Do not send a second paid or destructive action to find out whether the first worked. For a local harmless prototype, record the sequence and whether the interface distinguishes pending, failed and unknown outcomes. Those are different states and deserve different recovery instructions.

Keep a release evidence sheet

For every essential task, record the input, expected outcome, observed outcome, version and date. Separate a pass you personally observed from an assumption based on generated code. A failed task needs a repair and a focused retest; it does not require an unrelated redesign. When sharing the prototype, name its remaining limitations so another person does not mistake a demonstration for production readiness.

• Use a simple acceptance ledger with one row per task. Record whether the result was observed directly, inferred from code or left untested; those three labels must never be interchangeable.