This is an illustration of the format, not a real client. "Slotly" is a made-up booking app built in Lovable with Supabase and Stripe. The failures below are the ones that most often break in apps built this way. A real report covers your live URL and comes with a screenshot for every item.
| Flow | Result |
|---|---|
| Sign-up and email confirmation | Broken (item 1) |
| Password reset | Broken (item 1) |
| Log in / log out | Works |
| Data privacy between users | Broken (item 2) |
| Checkout (Stripe, live mode) | Broken (item 3) |
| Booking limits | Broken (item 4) |
| Emails reaching the inbox | Spam in Gmail (item 5) |
| Secrets in the browser | None found |
Fix estimate: fits the $249 fix. Five items, all config or small server changes.
What happens: A new user signs up, gets the email, clicks the link and lands on http://localhost:3000, which doesn't load. They can't finish signing up. Password reset does the same thing.
To reproduce: Sign up in a private window with a fresh Gmail address and click the link in the email.
Cause and fix: Supabase Authentication → URL Configuration still has the dev Site URL. Set it to the production domain and add that domain to the redirect list.
What happens: Logged in as test user B, changing the booking ID in the request returns user A's name, email and booking time.
To reproduce: Two accounts. As B, open a booking, then swap the ID in the URL for one of A's.
Cause and fix: Row-level security is enabled on bookings, but the select policy is true for every authenticated user. Limit it to rows where the user is the owner or the business.
What happens: Checkout completes and the card is charged, but the account still says "Free" after a refresh and after logging out and back in.
To reproduce: Buy the cheapest plan in live mode, then reload the account page.
Cause and fix: The webhook endpoint exists only in Stripe test mode. Add it in live mode, use the live signing secret, and make the handler ignore events it has already processed.
What happens: With one slot left, booking it from two browsers at the same moment succeeds both times.
To reproduce: Open the same slot in two windows and press Book in both within a second.
Cause and fix: The "slots left" check runs in the browser. Move it into the database: a unique constraint or a single insert that checks capacity in one transaction.
What happens: The confirmation reaches Outlook's inbox but lands in spam at Gmail.
Cause and fix: The sending domain has no DKIM record and SPF doesn't include the email provider. Add both DNS records.
We used the live app as a customer would, with test accounts we made. We didn't touch your code, your keys or your accounts. If we see a secret key in the browser bundle, the report tells you to rotate it first.
Get a report like this on your app, free
Usually within 2 business days. Fixing what's in it is $249, with a full refund if we can't make those flows work.