Website vendor lock-in starts at the settings panel.
Can you change how the system behaves, or only what the settings panel exposes?
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, and here is the range. The panel is honest about what it offers. It is silent about everything else, and everything else is where website vendor lock-in lives.
Control asks one thing. When a client wants the site to behave differently — a redirect rule, a response header, a form that does something the template never anticipated — can you make it so, or can you only make it so if a toggle exists? 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 question is whether the ceiling is the menu or your ability.
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
Ask support to change 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.
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 deliberately boring 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.
Control is the first test. It is not the strictest.
Scalability
Does it have a ceiling you’ll hit?
Ownership
Not just “can you leave,” but can someone change 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.
Read the sharpest chapter first. It costs an email.
We’ll send the build-gate chapter in full: the checks, the code, and the reasoning. 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.