Stop shipping demos. Your users can tell.

Why I'm writing this

I've handed off six SaaS products to clients in the last 14 months. The first two embarrassed me. They worked great in the demo, then I'd watch the screen recordings and see real users hit a loading spinner that never resolved, or a form that submitted twice, or an "Untitled" appearing where their name should be. The product was technically alive. It was just not finished.

None of that showed up in the demo because I never demoed it on bad wifi. Or with the second user. Or after the database had 3,000 rows. The demo is a stage. The product is a Tuesday afternoon at 4 PM.

The boring 90-second test

Before I let anything go to a paying customer, I run this — exactly as a real user would:

1. Open the app on phone, on bad LTE. If the first paint takes longer than 2.5s, fix it before anything else. Most users decide here.
2. Sign up. Log out. Log back in. The second login is where session bugs live. Half the time the app loads in a half-authenticated state.
3. Click the primary action with bad input. Empty form. Wrong email. 0 in the amount. The app should fail with a sentence, not a stack trace and not silence.
4. Open two tabs and write to the same record. If you don't have optimistic locking, you have a data corruption bug waiting.
5. Check what the email looks like in Gmail dark mode. Half the templates I get from AI builders look broken on dark mode. Free user emotion: "this looks scammy."
6. Run a billing cycle in a sandbox. Trial expired. Card declined. Renewal succeeded. All three need a real UI, not a 500.

That's it. Six checks. Most demos fail at #1.

The demo doesn't have to be perfect. The product does. They are not the same thing and your customer can tell within ten seconds.

The states most builders skip

I keep a sticky note on my monitor with these. AI builders are bad at almost all of them by default:

• Empty state — what does the dashboard look like with zero data? Most apps look broken.
• Long state — what does it look like with 800 rows? With 3 minutes of upload? With a 4MB image?
• Error state — what does it look like when the API is down? "Network error" is not a UX.
• Slow state — what does it look like at 3G? Skeleton loaders are not optional.
• Second-user state — what does it look like for the colleague the first user invited?

The conversation that pays the rent

The reason I'm religious about this: clients don't pay you for a demo. They pay you for something a real human keeps opening on a Tuesday. If your $4k MVP gets used twice and then forgotten because the second login was broken, your client churns the whole project, not just one feature.

I learned this on a fitness app I shipped in 2025. The demo was beautiful. The first user logged in fine. The second user — the spouse — got an empty dashboard because I'd hard-coded a tenant ID. The client called me, embarrassed. I refunded a third of the invoice. Cheapest lesson I've ever paid for.

The agent helps if you ask it the right way

buildr's agent will plug a lot of these holes if you tell it to. The prompt I use, more or less:

"Add empty states, error states, and skeleton loaders for every list and form on this page. Use optimistic UI with rollback for the primary actions. Wire up an idle warning at 25 minutes and an auto-logout at 30. Show me what changed before applying."

That single prompt has saved me a full day of polish work on every project since.