The framework
The CODES test: five ways any platform can fail.
Run it on any platform before you put a client’s business on it. Five tests, each answered yes or no, and a rule with no partial credit.
Why a test
A feature list is a snapshot. A test is a forecast.
Every platform can show you a feature list, and every feature list is true on the day you read it. It says nothing about the day a client asks for the thing that isn’t on it. That is the day you find out what you built on.
CODES runs five tests instead, and each one comes back yes or no. Each is about a decision you will have to make later: change the behaviour, leave, keep the records, add something new, grow. Feature lists are written by the vendor. The answers to the five are already written into the terms, the export, the settings panel, the forum thread nobody answered. You can read all four yourself.
The rule is strict on purpose. Four passes and one fail is a fail, because the one you failed is the one the client will eventually need.
There is no partial credit. Four out of five is a fail.
The CODES test
Five tests. Any platform. Pass or fail.
A feature list tells you what a platform does today. These five tests tell you what it will let you do later, when a client asks for something it wasn’t built for. Score any platform against them, including the one your clients are on now.
- Control
- You can change how the system behaves, beyond what the settings panel exposes.
- Ownership
- You can leave with the work, and nobody rewrites the deal while you stay.
- Data
- Your records live in a database you hold, not in someone else’s.
- Extensibility
- You can add what isn’t there yet, without waiting on somebody’s roadmap.
- Scalability
- The ceiling, if it has one, sits above anything your clients will ask for.
Pass all five, or don’t build on it.
A folder of static files on hosting you chose passes all five without trying. Which is why the playbook is called what it’s called.
Letter by letter
How a folder of files answers each one.
Here is how the playbook’s stack, static builds on hosting you chose, scores. Two of the five need a sentence more before the answer is honest.
Behaviour is whatever the build produces. The build is the panel, and you wrote it.
Nobody can change the deal while you stay, because there is no deal: the host is replaceable in an afternoon.
D
Data
Partial by default, full by choice. Static pages have no database, so the question moves to the form endpoint, and this site’s form posts to a route it owns.
What isn’t there yet is a file you haven’t written. The governed agent is the proof: an AI feature no platform sells.
Passes for content and marketing sites, which is what the playbook is scoped to. A store or a login is a different stack, and the playbook says so.
Whose test it is
A test you run on behalf of clients.
The test is not a private opinion about platforms. It is a professional artefact. A freelancer who can say “I run every platform through five tests before I put your business on it” has said something a client can repeat to a partner, and something a competitor has to answer.
Run it on the platform the client is on now. Write the five answers down, one line each, then show them. Nothing in the test asks the client to understand a build, only to read a yes or a no. Clients recognise a fail when they have already paid for one.
The test also runs on AI features, which every platform now sells. Whose model, whose rules, whose logs, whose bill next year: Control, Ownership, Data again, asked of a chatbot instead of a settings panel. The governed agent is the answer, and it has its own page.
Passing is the easy part
Passing is table stakes. Running it is the playbook.
A folder of static files on hosting you chose passes all five without trying. That is not the achievement. The achievement is running an owned stack for ten clients so that nothing bad ever ships: no banned phrase, no dead link, no claim nobody can source, no third-party request that arrived on a Tuesday with a plugin update. That is a discipline rather than a platform, and it has six parts.
Passing is the easy part. Running it so nothing bad ships: that’s the playbook.
The free chapter
Read the sharpest chapter first. It costs an email.
We’ll send the build-gate chapter in full: the checks and the code that runs them, with the reasoning behind every one. Read it. If it doesn’t change how you think about shipping client sites, you’ve lost ten minutes and kept a working release gate.
That did not send. Check the address and try again.