The system broke the moment we launched it. 🫣

We were automating refund processing — pulling data from Mollie, matching it to a payment, finding the transaction in our accounting system. Simple enough on paper.

In practice, the system started “losing” refunds in bulk.

The culprit? Speed.

Before automation, we processed refunds manually — slowly, with delays. No one was rushing. But automation wants to run immediately. And that’s exactly where it broke.

Here’s what was happening: a customer buys something and requests a refund right away. Our system races to process it — but the transaction hasn’t shown up in the accounting software yet. The payment simply hasn’t settled. The system returns “not found” and kicks it to manual review.

The very thing we built automation to eliminate.

What we did:

We built a retry queue — each refund gets 7 days, checked once a day. Then we started tracking when transactions actually appeared in the system.

Turns out: almost everything showed up by day 4.

Fix: we simply don’t process refunds younger than 5 days. Problem gone.

The lesson every founder should bake into any automation project:

You need an observation period — not to test whether the code works. The code can be perfect. You need it to understand the boundaries of the system you’re integrating with.

Those boundaries aren’t in the documentation. You can only discover them by measuring.

Skip this step and you’ll end up with a fast system, a pretty dashboard, and a pile of unhandled exceptions.

Speed without understanding behavior isn’t automation. It’s the illusion of control.