Make this Lovable app survive in prod
Most Lovable apps I've seen ship with integrations that were never actually run end to end.
What's usually happening?
The Stripe webhook is wired, the retry logic is there, but nobody ran a confirm → capture → webhook fire sequence before going live. Testing is either skipped or scripted in isolation against mocked responses that don't reflect real API behavior.
What does prod surface?
The edge cases. Rate limits, flaky webhooks, card declines mid-flow, double-charges on retry. The stuff that only shows up when real money or real users are involved.
What we're building toward:
connect FetchSandbox MCP, prompt "make this app survive in prod," and the runtime reads your app config, infers the invariants that matter, probes against failure scenarios, then returns a public receipt with the full trace. Agent finds the bug, proposes the fix, re-runs to prove it held.
Who this is for:
builders on Lovable (or similar) who shipped something real and need to know if it actually works before a real user hits it.
Genuinely curious how you're handling this today. Is there a verification step most are running, or is it mostly ship and find out?
Replies
the infers the invariants part is where this lives or dies. what should happen on a double charge retry is a business call rather than an api fact, and two correctly built apps will disagree about it.
FetchSandbox
@rabnoor_s 100% agree on the business call vs api fact point. That's exactly why we don't infer on the fly, we derive invariants from historical corpus using mathematical proofs, so by the time it runs the spec is already grounded in proven past behavior, not guessed. How are you thinking about expressing the business intent side today?
The verification step most people skip is not before ship, it is after. Running the failure scenarios once and getting a green receipt tells you the code handles that specific sequence today. It does not tell you whether the same webhook fired twice in production last Tuesday, because most apps do not keep an actor and a timestamp on the row that would let anyone answer that later. I would rather have a slower answer to did this double charge actually happen than a faster one before ship, because the after the fact question is the one that shows up in a support ticket or a chargeback, and by then a testing receipt is not what anyone is asking for.