Score a Platform Before Adopting It
July 2026
The rule: before committing real work to a platform, find out which parts of the loop a program can reach — create, read back, update, delete. Do it first, while switching is still free.
Why
Platforms get chosen for what they can display. Reach, audience, formatting, how the finished thing looks. Those are the visible properties, and they’re all about publishing day.
Every cost after publishing day comes from a different set of properties — the ones I did not think to check: whether a script can read the piece back, revise it, or remove it. Those determine what the next year of maintenance feels like, and they’re usually discoverable in about ten minutes of reading documentation — but only if you think to look.
For everyday publishing, the one that matters most is update. Create is what you check when you’re excited; update is what you live with. If what you publish carries personal data, financial figures, or anything you might be legally required to take down, delete outranks it — the question there isn’t how you fix a page, it’s whether you can remove one at all.
What it cost us
Two weeks spent climbing a wall that had a gate. Posting to X was done entirely by hand for about two weeks — real effort, real workarounds, real formatting frustration. The effort was aimed at working around the limitation rather than at finding out whether the limitation was real. Once the question “is there a developer API for this?” finally got asked, building the answer took roughly two hours.
That’s the shape of this failure. It isn’t laziness and it isn’t lack of skill. It’s not knowing that a standard move exists to ask about — which is exactly why the question has to be a habit rather than an insight.
A quota discovered by hitting it. A hard ceiling of ten article-draft uploads per rolling 24 hours turned out to exist, and to return a generic “service unavailable” when exhausted — indistinguishable from a real outage without inspecting the response headers. It was found by burning through a day’s worth of quota, eight of the ten calls being automatic retries and diagnostics chasing what looked like a platform failure. All of it was documented in advance, in headers we hadn’t thought to read.
No update call, found after publishing. The subject of this whole series. Adopted first, discovered second.
How to apply it
The same four questions, applied to two real platforms. The two “none” answers are the whole cost.
Four questions, asked before the first real piece goes out:
- Create — can a program publish here, or does it need a human at a keyboard?
- Read back — can a program retrieve exactly what’s live, so it can be compared to your source?
- Update — can a program fix a published mistake? This is the expensive one.
- Delete — can a program remove something that shouldn’t be there?
Then check the limits: rate ceilings, quotas, and what failure actually looks like when you hit them. Read the response headers of a successful call once, deliberately, before you ever need them in an emergency.
A “no” to any of these isn’t a reason to walk away. It’s a cost to price in with your eyes open, which is a completely different thing from a surprise.
The general form
Evaluate a tool by the whole lifecycle, not the first use. Anything you can’t script, you will eventually do by hand — at the worst possible moment, from the wrong device.
Try this now
Take one thing you currently do by hand on some platform — posting, filing, exporting, renaming. Search that platform’s developer documentation for it, once, right now. Ten minutes either finds you a gate or confirms the wall is real. Both answers are worth more than the assumption you’re carrying.
This entry came out of The Bottleneck Is Also the Inspector. What to do once you have the answers: Treat a Graphical-Only Surface as Terminal.
If this helps you, check out my adblob to support the work.