Jonas sells workwear — eleven years, eight hundred products, descriptions he wrote himself in a voice his customers recognize. Last spring an optimization app offered to "fix" his catalog copy for search, and the preview looked reasonable, so he clicked the button every app wants you to click.
Overnight it rewrote all eight hundred.
The new descriptions weren't even terrible. They were generic — his eleven years of product knowledge flattened into the same interchangeable paste coating every other catalog. He asked support how to restore the originals. The answer, verbatim energy if not verbatim words: we don't keep previous versions.
Eight hundred writes, executed in ninety seconds. Recovery: three weeks of spelunking through an old CSV export he was lucky to have, a spreadsheet, and his own memory of what he'd written. The app's changelog described the incident's feature as "one-click catalog enhancement." Nobody had built the second click.
This file is about that missing click. The last one established what "fixable" and "fixed" must mean — a capability provable in code, a diff at the wire. This one adds the standard that makes granting write access rational at all: no destructive write without versioned rollback. Not as a nice-to-have. As the price of admission to your catalog.
Write access is surgery on live revenue
Get the framing right and the standard follows.
When an app writes to your store, it is operating on the asset that pays you — the records that render your pages, feed your markup, fill your feeds, and get quoted by machines. And write operations have a brutal asymmetry: damage is fast and recovery is slow. A bulk write takes seconds; reconstructing what eight hundred records used to say — without versions — takes weeks, if it's possible at all.
"Our fixes are well-tested" doesn't answer this, and it's important to see why. The standard isn't about whether the vendor is usually right. Every tool that writes at scale will eventually write something wrong — a bad transformation on an edge-case product, a correct fix applied to the wrong subset, a fix that was right until your supplier changed the facts. Being wrong sometimes is a when. The question that separates serious tools from Jonas's app is entirely about what happens next: is being wrong a revert, or an incident?
What "versioned rollback" actually means
The phrase gets diluted, so here's the standard with its load-bearing parts explicit. Five requirements:
1 — A before-image, per record, per write. Before the tool changes anything, it captures what the record said. Not a log line — the restorable prior state. No before-image, no legitimate write; the capture isn't a feature of the fix, it's a precondition of it.
2 — Versioned, not "undo last." Writes stack. Tuesday's fix lands on top of Monday's, and a single undo buffer that only reverses the latest action is a toy. Versioned means you can restore any record to any point in its write history — including all the way back to before the tool ever touched it.
3 — Scoped restore: one record, one category, or everything. You need all three grains. This product only. Every write of this kind. And the nuclear option — revert everything this tool has ever written — because the day you need that one is the day you find out whether it exists. A tool confident in its fixes should be the first to hand you the button that erases all of them.
4 — Honest about what changed since. The hard engineering, and the tell of a serious implementation. If you edited a record after the tool wrote it, a naive rollback destroys your work to restore the past. Real rollback detects subsequent merchant edits, refuses to silently clobber them, and tells you about the conflict instead. Ask a vendor about this case specifically; the quality of the answer is the quality of the engineering.
5 — The restore proves itself at the wire. Same standard as the fix: a rollback isn't done when a dashboard says so — it's done when the delivered response matches the before-image on re-check. Reversal is a write too. It gets verified like one.
Anything less than these five is a marketing word wearing an engineering word's clothes.
FIG.02 — What "versioned rollback" means. Five load-bearing requirements; anything less is a marketing word in engineering clothes.
Consent without undo is liability transfer
Here's the piece that connects to the four honest answers: a whole class of fixes is legitimately "engine plus merchant confirmation" — computable, but consequential enough that the tool shouldn't act unilaterally. Confirmation is right. But look closely at what a confirmation dialog is when no rollback exists behind it.
"Are you sure?" — with no way back — isn't asking permission. It's transferring liability. The vendor gets your click as cover; you get the irreversibility. The dialog's real sentence is: whatever happens next is now your fault. That's not consent, it's a waiver.
Reversibility is what turns the same dialog back into a real question. "Apply this fix — and here's the button that unmakes it, per record, forever" is a proposition a busy merchant can rationally accept in four seconds, because the downside is bounded. This is why rollback isn't a power-user feature bolted onto write access: it's the thing that makes confirmation itself meaningful. No undo, no informed consent — just documented blame.
FIG.03 — The same dialog, two very different sentences underneath it. Reversibility is what turns a waiver back into a question.
Why vendors skip it — and why that's your signal
Rollback is expensive in exactly the ways sales pages can't show. Before-image storage for every write. Version schemas that survive product deletions, variant restructures, and platform API changes. Conflict detection for the edited-since case. Restore paths tested as hard as apply paths. It's weeks of engineering for a button most users will never press — invisible right up until the day it's the only thing that matters.
Which is precisely why its presence is the strongest trust signal an app with write access can send. A vendor who built real rollback has sat with the question "what happens when we're wrong?" long enough to spend serious money on the answer. A vendor who didn't has thought hard about the sale and not at all about the incident. You can't audit their test suite from the outside — but you can audit this, in one support email.
The fifteen-minute interrogation, before you grant write access
Five questions to any vendor whose app requests write scopes — in writing, before the OAuth screen:
- Show me a restore of one record to its state before your last write — and the wire diff proving it.
- Show me "revert everything you've ever written to my store." Not described. Shown.
- What happens if I edited a record after your write? (The only right answer involves detecting the conflict, not silently overwriting your edit.)
- How long are before-images kept, and does uninstalling your app destroy them?
- What exactly do your write scopes let you touch — and why each one?
FIG.04 — Five questions before the OAuth screen. Ask them in writing; silence is also an answer.
That fifth question is its own iceberg, and it's where this series goes next: the OAuth screen everyone clicks through is a complete list of what an app can do to you, written in a vocabulary nobody reads.
And one unconditional habit regardless of vendor answers: export your products CSV before granting any write scope. Shopify gives you a free, dated before-image of your entire catalog in two clicks. It's the poor-man's version of requirement one, it costs nothing, and it's the difference between Jonas's three weeks and an afternoon.
We publish this standard because we're bound by it: in our own engineering rules, no destructive write ships without versioned rollback — the revert path is built and tested before the apply path is allowed to exist. That ordering isn't caution for its own sake. It's what "fixed it for you" has to mean for the sentence to deserve your click.
Sources & further reading
- Shopify — API access scopes (what write permissions actually grant): https://shopify.dev/docs/api/usage/access-scopes
- Shopify — Exporting products to CSV (your free before-image): https://help.shopify.com/en/manual/products/import-export/export-products
- Shopify — App requirements and data protection: https://shopify.dev/docs/apps/launch/protected-customer-data
- Rank Sniper Field Notes — FILE 02 declared vs delivered: /blog/ai-agent-declared-vs-delivered-product-page · FILE 04 the legibility layer: /blog/product-attributes-ai-systems-refuse-to-guess · FILE 07 fixable means fixable: /blog/fixable-should-mean-fixable-store-audits
Rank Sniper — Field Notes. Catalog legibility and AI-visibility verification for Shopify. We verify what AI agents actually receive from your store; we don't generate content and hope. Verifier, not generator.
