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.

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.