I sat there 30 seconds before pushing prices to 175 countries from a script. Here's what "safe automation" actually means.

The first time I pushed prices to 175 countries from a script, I sat there for thirty seconds with my hand off the trackpad before clicking.

Not because the math was wrong. Because I had no idea what would happen if it went wrong.

That feeling, between "I trust my code" and "I'm about to commit to production for the entire planet," is what I think most pricing automation skips over. It treats every push as a one-way commit. No preview, no diff, no history, no undo.

I run 8 apps across iOS and Android. Manually setting prices for 175 countries every time FX rates shifted was a multi-day spreadsheet exercise. So I built PricePush to automate it. But the moment I had it working, I realized speed wasn't the problem. The problem was I'd just made the consequences of a wrong push faster.

Push wrong prices to 175 countries, and you can't fix it in five minutes. Under-price to 20% of intended in Brazil for 24 hours, and anyone who subscribes during that window is locked in at the wrong rate (Apple grandfathers existing subs). On annual subs, that's a year of revenue you can't recoup. Over-price India by 3x for a week, and you see flat conversions three months later, then higher churn six months later. Detection is slow. By the time the data tells you something is wrong, it's wrong for thousands of users.

So I went back and built the rest of it:

• A diff preview that shows every old/new price, per country, per store, before any push. Manual overrides flagged separately.
• A push ID with timestamp, attempts counter, and lifecycle status (queued, running, done, error, cancelled). Strategy snapshotted at push time.
• A history page that shows per-country diff back 90 days or 500 events.
• Atomic push within a product on a store, with retries and Apple's rate-limit gate respected.
• One-click rollback that re-pushes the old prices and writes a "Restored from <date>" row to history.

Engineers solved this for code 20 years ago. Git, PRs, atomic commits, git revert. The right tools for app pricing are the same tools we use for code: diffs, versions, history, atomic application, rollback.

The headline isn't rollback. It's the diff. If preview were flawless and the push were truly atomic, you wouldn't need rollback. Rollback is the safety net that exists so the preview step earns the trust it needs.

I also put together an 8-question checklist for evaluating any pricing automation tool. It works against PricePush too, that's the point. If a tool doesn't pass it, you're trusting it on the failure modes you can't see.

Wrote the whole thing up here: https://pricepush.app/blog/app-prices-safely-versioning-history-rollback

Has anyone here been burned by an automated pricing change without rollback?
Or if you've built your own internal tooling for this, what does your audit trail look like?