Treat a Graphical-Only Surface as Terminal

July 2026

The rule: if a platform has no programmatic way to edit or remove what you’ve already published, treat it as a one-way destination. Send it finished work. Never plan to iterate there.

Why

There’s an assumption built into modern publishing that everything is editable. Most of the web is. When a platform isn’t, the cost doesn’t show up at publish time — it shows up at the first typo, weeks later, when the correction turns out to require a specific machine in a specific room.

The trap is that a graphical editor feels like the cheapest place to make a change. It’s right there, the text is loaded, the change takes ten seconds. What it actually does is create a second copy of your work that no script can read, compare, or fix.

What it cost us

The X Articles interface offers exactly two programmatic operations: create a draft, and publish a draft. Nothing edits an article once it’s live, and nothing deletes one either.

Two ways in, no way back. Read off the tool’s own implemented endpoints.

Both halves have already cost real time. Two stale drafts of one article had to be cleared by hand in the web interface on 2026-07-30, because there is no delete call to do it with — a few minutes of clicking that no script was allowed to save us. And a missing affiliate disclosure on a published article, found on a phone in the morning, sat open for hours purely because the fix required a desktop.

Neither of those is a hard problem. Both are cheap fixes gated behind physical presence, which is the worst kind of cost: it doesn’t scale with the size of the mistake.

How to apply it

• Decide before you publish, not after: is this text final? If the honest answer is “mostly,” it isn’t ready for a terminal surface.
• Do every editing pass upstream, on a copy you control. This is the companion rule to Finish the Text Before It Forks and they’re strongest together.
• Budget the correction cost when choosing where to publish. A platform with no edit path isn’t disqualified — it just means mistakes there cost a trip, and you should price that in rather than discover it.
• If you must publish something you know will need revision, publish it where revision is cheap and link to it from the terminal surface. A link you can update behind a URL you can’t is a way around the whole problem.
• “Never iterate there” is a planning rule, not a prohibition. It means don’t design a workflow that depends on editing a surface that can’t be edited cheaply. It does not mean leaving something wrong in public because fixing it is inconvenient. When a live page carries a compliance gap or a factual error, you go make the trip — this rule’s job is to make that trip rare, not to talk you out of it.

The general form

Match the permanence of the surface to the finality of the work. Anything you’d want to revise belongs somewhere revisable; a one-way door should only ever receive things you’re done with.

Try this now

Pick the platform you publish to most. Find its API documentation and search the page for “update,” “patch,” or “delete.” That search takes about a minute, and its result tells you what every future typo on that platform is going to cost you.

This entry came out of The Bottleneck Is Also the Inspector, and pairs with Score a Platform Before Adopting It — that one is how you find this out before it’s too late to choose differently.

If this helps you, check out my adblob to support the work.