How to read a deprecation notice

Shopify is deprecating checkout.liquid. For most people in this ecosystem that's a migration project. For Vigilance it's the end, because that file isn't a component of our product — it's the mechanism.

Everything we do, the detection and the blocking, runs through the one hook that's being removed. There is no version of this product that survives on the other side without being a different product built by a different team.

I want to write about the reading, not the outcome. Because the notice wasn't a surprise attack. Shopify had been publishing where checkout was going for a long time, and I read all of it, and I read it wrong.

How I was reading it#

As industry news. Something happening in the ecosystem, relevant to my sense of where the platform is headed, useful context for strategy conversations.

What it actually was: a document about whether my company gets to exist, published in advance, for free, by the party who decides.

The difference between those two readings is not sophistication. I understood every technical detail. The difference is which question I brought to it. I was asking "what does this mean for the ecosystem." The question was "what does this mean for us, specifically, on what timeline."

Why the right reading is hard#

Deprecation notices are written to be reassuring. They come with migration paths, timelines, and a tone of continuity. That tone is accurate for 95% of the affected parties and catastrophically misleading for the rest. The document does not distinguish between "you will need to refactor" and "you will need to not exist," because from the platform's side those are the same announcement.

The timeline invites deferral. A deadline far enough out reads as hypothetical. It gets pushed back, which teaches you it isn't real, and the lesson you learn from a postponement is exactly the wrong one.

Everyone around you is calm. The ecosystem consensus on any given platform change is that it's manageable, because for the ecosystem it is. Your specific exposure is a minority position and there's no chorus for it.

You've said the words already. I told my investors last year that this product depended on a specific platform behavior. Having named the risk out loud, I had the feeling of having dealt with it. Naming a risk and pricing a risk are unrelated activities, and I did the first one well enough to stop doing the second.

What the correct practice looks like#

I'm writing this as a checklist because I want it to be mechanical rather than wise.

Identify the single mechanism your product cannot survive losing. Not a list of dependencies. The one. If you can't name it, you haven't looked.

Set a standing task to read that mechanism's roadmap with your own company as the subject. Monthly. The question is not "what's changing," it's "does this change end us, cost us a quarter, or cost us nothing."

Treat a postponement as a reprieve, not a reversal. The direction of a platform roadmap almost never reverses. Only the date moves.

Discount the revenue that depends on it. Same revenue, different quality. Take money off the table earlier. Don't hire against it. Don't let anyone value it as permanent.

Where that leaves us#

The deadline has room in it. We could run this for a while longer and take the revenue.

I don't think we will, and I'll write about why once the decision is actually made rather than while I'm making it. The short version is that revenue with a known expiration date is a job, not a company, and I'd spend every one of those months either in denial or in a panic rewrite.

There's also the question of the money people gave us, which is the part I've been thinking about most and the part I have the least figured out.