'It Works in the Demo' Isn't an Acceptance Test
A demo that goes smoothly proves the software works under ideal conditions, with a prepared presenter, on a clean test account — it doesn't prove the software works the way your actual team and customers will use it, which is why "the demo looked great" is not the same thing as a real acceptance test, and treating it as one is how businesses end up finding critical bugs after go-live instead of before.
Why Does a Good Demo Give False Confidence?
Demos are, reasonably, run on clean data, by someone who knows exactly which buttons to click in exactly the right order, showing exactly the features meant to be shown. Real usage involves messy data, unexpected input, employees clicking things in a different order than expected, and edge cases nobody thought to demo. None of that shows up in a polished walkthrough.
What Are the Ten Owner-Run Checks Before Sign-Off?
| # | Check |
|---|---|
| 1 | Log in as your lowest-permission user role and confirm they can't see or do things they shouldn't |
| 2 | Deliberately submit a payment that will fail (expired test card) and confirm the error handling is clear, not confusing |
| 3 | Use the system on an actual phone, not just a desktop browser resized smaller |
| 4 | Export your data (customer list, reports) and open the exported file to confirm it's actually usable |
| 5 | Enter unusual real data — a very long name, a special character, a duplicate entry — and confirm nothing breaks |
| 6 | Have someone unfamiliar with the system try a core task with zero guidance |
| 7 | Test what happens when your internet connection is slow or briefly drops |
| 8 | Confirm what a recovery process looks like if a record is accidentally deleted |
| 9 | Check that notifications/emails the system sends actually arrive and look correct |
| 10 | Confirm who has admin access and whether that list is actually correct today |
Why Does the Permissions Check Matter So Much?
A common and quietly serious issue: a system demo'd as "admins see everything, staff see only their own jobs" but never actually tested from a real staff login, where it turns out staff can see customer payment details they shouldn't. This is a real risk that a demo, run from the admin account, will never surface.
Why Test on an Actual Phone Instead of Just Resizing a Browser Window?
Resizing a desktop browser window approximates mobile layout but misses real mobile issues — touch targets too small to tap accurately, a keyboard covering an input field, a feature that quietly doesn't work at all on mobile Safari specifically. If your team or customers will genuinely use this on their phones, that has to be tested on a real phone, not simulated.
What Happens If You Skip This and Something Breaks Post-Launch?
Bugs found after go-live, especially with real customer data involved, are more expensive to fix — both in direct cost and in the trust cost of a customer-facing failure. A day spent running these ten checks before sign-off is consistently cheaper than the same bug discovered a week after real customers are using the system. This is a required step in every custom platform engagement we run, not an optional extra.
Who Should Actually Run This Checklist?
The business owner or a designated non-technical staff member, not just the developer who built it — a builder testing their own work tends to test the paths they already know work. A fresh set of eyes running through real scenarios catches what a builder's own walkthrough won't.