In 47 posts, three builders describe failure testing before launch.
Lovable builders are already testing failures by hand. I read 47 posts from r/lovable and found three that point at the same habit: break an important action on purpose before launch.
What breaks after the happy path
The posts describe a familiar gap. A webhook route looks fine, then takes days to debug when it fails. A new app's error logs make sense to the person who wrote the backend, but not to the person trying to help a customer. From the outside, a failed payment or missing email can look like a confusing screen, not a broken integration.
Generated apps usually exercise the success case while they are being built. Production adds a second webhook delivery, a payment that succeeds while the app's membership row stays free, or an email request that returns 200 but later bounces. None of those is answered by asking whether the page loaded.
Break the action that can fail quietly
Choose the action that would cost you money or trust if it failed without an obvious error—often checkout or its confirmation email. Force a failure and inspect what the customer sees and what the database stores.
Two useful first checks:
- Deliver the same webhook twice. Does the app provision twice?
- Let payment succeed, then make the follow-up write fail. Does the customer remain marked free? That mismatch has its own failure pattern.
People rebuild these checks by hand after an agent rewrites the backend. The hosted FetchSandbox MCP can start an app-level check: configure the returned twins, arm a returned probe with the session ID, exercise the reachable app, and submit the session ID, run ID, and probe. A green provider quickrun alone does not test the Lovable app.
When code moves into a repository, carry applicable deterministic checks into CI and attach the receipt to the change. A reviewer can then inspect what ran after the builder chat is gone. Anything the run did not measure should remain unmeasured.
The full 47-post write-up lists the titles and limits. This is a small sample biased toward people describing problems, not a measure of how often failures happen. One record was an unrelated game ad; I did not interview the posters. The useful signal is narrower: builders are already asking how to break the important path before users find it.
