Own the Code

The CODES test · C for Control

Website vendor lock-in starts at the settings panel.

You can change how the system behaves, beyond what the settings panel exposes.

What the test asks

A panel is a list of decisions somebody else made.

Every setting in a panel is a choice a product team made on your behalf. This can change. That cannot. This one moves, but only this far. The panel is honest about what it offers. It says nothing about everything else, and everything else is where website vendor lock-in lives.

Control asks one thing. A client wants the site to behave differently, say a redirect with a pattern in it, or a form that does something the template never anticipated. A platform that passes lets you write the behaviour. A platform that fails sends you looking for a toggle, and the toggle either exists or the client does without. A yes means the system’s behaviour is yours to define. A no means it is yours to request.

The test is not about effort. A platform can make a hard thing easy and still fail Control, because the moment the client asks for the thing outside the menu, easy stops being the point. The ceiling is either the menu or your own ability, and only one of those you can raise.

What failing looks like

The menu is the ceiling, and the ceiling has a roadmap.

You do not need a contract to check this. Open the settings panel of the platform your clients are on and write down what it cannot do. Not what is hard, what is absent: a custom response header, a redirect with a pattern in it, a form that posts somewhere you chose, a change to what the page sends the browser before the template gets to it.

Then find the forum thread where someone asked for it. Note the date. The gap between that date and today is the roadmap, and the roadmap is the vendor’s to set. It is the honest measure of how much of the site’s behaviour is theirs and how much is yours. The same boundary appears at the exit, where each platform documents what leaves with you: no site export from Wix, one .xml file from Squarespace, and a ZIP without the CMS from Webflow.

  • The custom code box

    Find it, then read what it may not touch. A box that accepts a snippet but not a build step is a menu item with a text field on it.

  • The forum thread

    Search for the feature the client wants and open the oldest request for it. The age of that thread is the answer to Control.

  • The support reply

    Put in a ticket asking for one behaviour the panel does not expose. The reply is the test result, in writing.

Lock-in is not a clause. It is a menu with no “other” option.

What passing looks like

Nothing to ask permission for. The build is the panel.

On the owned stack there is no panel between you and the output. The site is a repository and a build command, and the build produces whatever you tell it to: the redirects, the headers, the content-security policy, the form that posts to a route you wrote. If the client wants the site to behave differently, you change a file and the build produces a different site. The stack is boring on purpose, for exactly this reason.

Control cuts both ways, and the playbook says so. A system that lets you change anything will let you ship anything, including a page with a dead link or a phrase you would not want quoted. So the stack carries a release gate: the build refuses to complete when a page fails a check. Control over behaviour, plus a gate that refuses bad output, is what owning the panel looks like in practice.

The list of checks, with the code, is the free chapter. It is the sharpest part of the playbook because it is the part you can run tomorrow.

On a builder you request behaviour. On files you own, you define it.

C for Control. Four to go.

Before and after

Control is the first test. It is not the strictest.

The last letter · S

Scalability

The ceiling, if it has one, sits above anything your clients will ask for.

Next · O

Ownership

You can leave with the work, and nobody rewrites the deal while you stay.

The full test runs all five, with the assembling word and the rule: pass all five, or don’t build on it.

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.