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.

Spent way too long this week watching devs debug Paddle billing issues that never reproduced locally.

The pattern keeps repeating: subscription.activated arriving before subscription.created in prod, about 30% of the time. Handlers look clean, pass unit tests, handle retries correctly. But they assume events arrive in order. Paddle's sandbox just doesn't reproduce that chaos.

launch yesterday (july 12th) we told you all about @FetchSandbox.

today i'd rather hear about you.

Since our last launch we've been heads-down on one thing: making "this integration works" actually mean something. Here's what changed, and why we're more confident than a month ago.

What we shipped?

Five integrations now recognize the bugs people actually hit and prove the fix with a real before/after:

How do you test a workflow that spans four services?

Been hitting the same wall for a while and curious how others handle it.

What's the failure shape?

Someone books a flight to London. Four things have to happen: confirm the booking, send a Slack message, fire a confirmation email, block the calendar. Travel is one vendor, messaging is another, email is another, calendar is another.

What happened

A few weeks ago my coding agent wrote a Stripe webhook handler. Signature check, event type check, fulfillment, clean 200. I approved it in 90 seconds because every line was correct.

And it was, until Stripe delivered the same event twice. Which it's allowed to do. Then the handler credited the customer twice.

Why it slipped through

three bugs an ai wrote for me this week. every test green. all three would've paged me in prod:

1. webhook retried charged the customer twice

2. subscription.activated arrived before subscription.created they paid, app said not entitled

3. a stale event flipped a canceled sub back to active free access, forever

none of these show up in a 200. you find them from a customer or you fire the ugly event orders on purpose and find them first.

we now throw every ordering + every duplicate at your handler and hand back the exact sequence that broke it.

The gap most auto-fix tools have

They tell you the bug is fixed. They don't show you. Our rule has always been: make the bug happen on real code, apply the fix, show it stops happening. The gap was we could only do that for bugs we'd scripted in advance. Anything unusual and the honest answer was "found it, fixed it, can't prove this one."

What we built

We taught FetchSandbox to write the reproduction itself, no pre-scripted test required.