Back to Blog
Insights

The Expiry Date Someone Else Set: Building Against a Deadline You Don't Own

Eight days from the morning this publishes, a date we don't control arrives. Shopify's developer documentation states it plainly — re-read there today, because a deadline you quote from memory is a deadline you've already started getting wrong: “ScriptTags on the Order Status page have been deprecated and will be turned off on August 28, 2025, for Plus merchants and on August 26, 2026, for non-Plus merchants.” We ship an app, CheckoutProof, whose entire reason to exist is that second date. This essay is not the countdown, and it is not a pitch — the roundup already covers what the app does. This is about something stranger and more general: what a deadline someone else owns does to the code you build around it. Because inside this one small codebase, that date turns out to live two different ways — and eight days from now, one of them flips itself while the other starts quietly lying.

Pattern One: The Deadline as Data

The engine under the app keeps the date where numbers live — three constants in one rules file: the non-Plus shutoff (August 26, 2026), the Plus shutoff (August 28, 2025), and a third for Shopify Scripts, a separate schedule we'll come back to. Next to them sits a four-line function, days_to_deadline(shopify_plus, today=None), whose signature is the whole design: the clock is an argument. Nothing inside it ever asks the wall what time it is unless you decline to tell it. Run it this morning — we did, as part of writing this — and it returns 8 for a non-Plus store and -355 for a Plus store, and the engine's API contract documents the convention in five words: negative = already passed.

Everything user-facing that touches the date consumes that number, not the calendar. The scan page renders a three-way branch on its sign: a countdown while days remain; for Plus stores, “the legacy surface was shut off — anything still flagged below is already dead”; and for everyone else, come the morning after, “the deadline has passed — anything still flagged below is already off.” The app's home screen does the same dance with its own constant and its own daysLeft arithmetic. On August 27 nobody will edit these files. The sentence changes because the number changed sign, and the number changed sign because the world did.

Here's the detail that makes this more than a design preference, and it's the strangest receipt in the essay: one arm of that branch has never once been reachable. The Plus deadline passed in August 2025. This codebase's changelog opens at version 1.0.0, dated July 3, 2026 — the code is 46 days old. Which means the Plus branch was born already flipped: since the day this code first existed, there has never been a value of “today” for which it could render its countdown. And it doesn't need one. Write the deadline as data behind an injectable clock and the far side of the deadline is just another input — testable before it happens, correct after, no migration morning required. The branch didn't have to live through the deadline to be right about it.

Pattern Two: The Deadline as Prose

Now the honest half, because the same codebase does it the other way too, and pretending otherwise would be exactly the kind of claim we've written rots fastest. We ran the census on publication morning: a grep for the literal strings “August 26,” “Aug 26,” and “2026-08-26” across the app's editable source finds twelve occurrences, and ten more in the engine's source. Some are comments. Some are the constant itself, which is fine — that's the data pattern. But a specific handful are English sentences typed into paragraphs, with no branch anywhere near them, and on August 27 each will still be sitting there in the wrong tense:

The plan card says “Legacy checkout scripts shut off on August 26, 2026” — a bare sentence, no branch, that reads as a warning today and will read as a history lesson delivered with strange urgency next week. The scan page offers to “grade what breaks on August 26, 2026.” And both public marketing headings ask the same question — “Is your checkout ready for August 26?” — which is a genuinely good headline with a structural problem: it expires. A question that creates urgency on the 18th creates confusion on the 27th, and no function is coming to save it, because it was never wired to one.

The engine has a subtler specimen worth naming because it shows the two patterns can hybridize badly: its remediation text builds the deadline sentence through a branch — Plus stores get “was already shut off (Aug 28, 2025)”, past tense, correct forever — but the non-Plus arm is the string “shuts off Aug 26, 2026,” present tense, hard-coded, on the arm that expires. The branch picks the right sentence today and one of its two sentences has a shelf life. Branching on the audience is not the same as branching on the clock.

The Cost Ledger, Both Directions

It would be tidy to conclude “always the function, never the prose,” but the codebase itself argues for something more honest. One line on the app's home screen reads: “Shopify Scripts stopped running on June 30, 2026” — past tense, accurate, 49 days after that separate shutoff. It is correct only because a human edited it after the fact. That's the real cost model. Prose is cheap to write and free to read, and it costs you a calendar obligation: someone must return to every such sentence the morning after, forever. The function costs more up front — a signature that takes a clock, a branch for a future you can't yet see, a test for each side — and then it costs nothing again. For one date in one place, hand-editing is a fine trade; the June 30 line proves it works. For one date in twenty-two places, it's twenty-two chances to end up with a plan card explaining that something “shuts off” on a date your reader remembers as last month.

And there's a fourth date in this story that shows the census is never quite done: Shopify's changelog also gave the legacy Script Editor a read-only wind-down ending July 30, 2026 — a date this app carries nowhere, in either pattern, because it never mattered to what the app checks. Deadlines you don't own arrive in families. Part of building against them is deciding which ones your code will even know about — and writing that decision down, so the absence reads as a choice rather than a miss.

What Actually Happens on the 27th

To be precise about the stakes, because “the app is full of expiring prose” can be misread as “the app breaks”: it doesn't. Every surface wired to days_to_deadline flips on the sign change, the way the Plus arm already demonstrates. The scan still runs; the findings still stand; a flagged legacy script on August 27 is simply described as already off rather than about to be. What goes stale is exactly the unbranched set: the plan-card sentence, the “grade what breaks” line, and the marketing question with the date in it — which will need the same human pass the June 30 line already got. We know the list because we grepped for it this morning, and now it's in print, which is its own kind of pressure to go fix the tense. The rules file that holds the constants carries a version stamp too — 2026-07-03, 46 days old today — because the same discipline that applies to permissions applies to dates: state what you know and when you knew it.

What Acting on This Costs, From the Live Listing

Since this essay has spent its whole length reading the app's own surfaces, it shouldn't go coy at the one surface that asks for money — so, from the live App Store listing as of this morning: the free plan is the countdown's companion. Every store gets the full readiness score and a preview of the findings, three scans in any rolling 30 days, free forever — which, eight days out, is enough to learn whether the 26th is a deadline you have or a deadline you're already done with. Pro — $29/month or $290/year, with a 7-day trial — is the working half: the complete findings list, each finding mapped to its platform-approved replacement, and scheduled re-scans that keep reading the clock after you migrate. That last feature is this essay's argument wearing a price tag: the deadline-as-data pattern doesn't retire on the 27th. The question just changes tense — from “what breaks” to “did anything come back” — and a monitor that takes the clock as an argument keeps asking it either way.

One more disclosure in that spirit: this essay is itself Pattern Two. It's prose, stuffed with dates, and its own headline number — eight days — expires faster than anything it describes. The difference is that an essay gets to be a snapshot; it says “as of the morning of August 18” and means it. An app is a running system that claims to describe the present. Prose that ages into history is fine on a blog and corrosive in a plan card — which is, compressed to one sentence, the entire finding.

The One-Sentence Version

A deadline you don't own should enter your code exactly once, as data behind a clock you can inject — every sentence built on it will then survive the date without you — and every place you instead typed it as English is a small promissory note that comes due, in the wrong tense, the morning after.

Eight Days Left on a Free Answer

The free scan reads your store against the August 26 cutover — full readiness score, findings preview, three scans a month, free forever. Pro adds the complete findings, the mapped fixes, and the re-scans that keep watching after the date passes.

Explore CheckoutProof
BW

Brandon Wigley

Founder of Wigley Studios. Building developer tools since 2018.

Previous: Old Glory vs the FTC Standard All Articles