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?
@rnagulapalle honestly badly. it ends up as assertions someone remembered to write, so intent only exists where it got encoded. starting from historical behaviour at least begins from what actually happened
FetchSandbox
@rabnoor_s yeah i misspoke on that..... mathematical proofs wasn't the right word, and you'd have caught it.
The invariants are written, not derived. And they're not business calls because of how they're shaped: they're metamorphic relations, not assertions about what the right outcome is.
The one you're looking at says: delivering the same event twice should leave the state the same as delivering it once. We don't say what happens on a double charge. We just say twice equals once. Two apps might disagree on the business rule but still agree on that relation, which is the whole point. No oracle needed.
You're right though, it only exists if someone encoded it. 9 of our 84 failure patterns have one today. The corpus tells us which failures happen often enough to be worth encoding, it doesn't write the relation for us.
Your framing is better honestly.
Starting from what actually happened is where the relation comes from. The corpus is the input, not the proof.
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.
FetchSandbox
@oshylabs Yeah this is the distinction that actually matters. A pre-ship receipt can prove this code survives this failure but it can't tell you what happened in prod last Tuesday.
Both layers are needed. Before ship: replay the failure, prove the invariant holds. After ship: keep enough production evidence to answer "did this invariant break, when, and what changed around it?"
That second part is where we're heading with drift detection. The same invariant shouldn't just gate a merge, it should stay live and fire when provider behavior or prod behavior drifts from what you proved.
Your actor + timestamp example is a good one.
wondeirng..where you'd want that evidence captured though, at the app/data layer or at the integration boundary?