Website builder custom code limits are the roadmap, written down.
Add what isn’t there yet, without waiting on a roadmap.
Not what it has. What it will let you add.
Website builder custom code limits are documented for a reason: the box that accepts your snippet has edges, and the platform would rather you read them than hit them. That documentation is the Extensibility test with the answers filled in. Read it before the demo, and read it as a list of the things a client cannot have.
The test itself is short. When the client asks for something the platform does not do — a calculation on the page, a different form flow, a feature that exists nowhere in the marketplace — can you build it, or can you only vote for it? Extensibility is a yes when the answer is a file you write and the build picks up. It is a no when the answer is a feature request and a date.
A roadmap is not a defect. It is a sign that the platform’s priorities are the platform’s. The test only asks whether you are on it.
A text field where a build step should be.
Find the custom code feature on the platform your clients are on and read its limits page in full. Note what it may not touch: the document head, the build, the server, the response, the parts of the page the template reserves. Note which plan it needs. Note whether it runs on the platform’s own pages or only on the ones you paste it into.
Then look at the marketplace. Every plugin there is a thing somebody could not do with the code box and had to wrap in a product. Every review that says “works, but not with” is a boundary you would have found later.
Then find the feature the client asked for last month and search the forum for it. If the answer is a thread with a status, the status is the test result. Extensibility is not whether the platform will add it. It is whether you can, today, without asking.
The limits page
Read what the code box may not touch and on which plan it exists. That page is the ceiling, published.
The marketplace
Each plugin is a feature the box could not build. Count how many the client’s site already depends on.
The thread
Search for the last thing a client asked for. If it has a status, you are waiting on a roadmap.
A code box is permission. A build is capability.
What isn’t there yet is a file you haven’t written.
On the owned stack there is no box and no limits page, because there is nothing between you and the output. The site is a repository and a build command. A new feature is a new file, and the build picks it up. The head, the headers, the server route, the response: all yours to write, none of it reserved by a template. The stack shows the shape of it.
The proof is the feature no platform sells. The playbook’s agent is a schema-governed AI on infrastructure you control, with enum-only tool arguments, layered request rejection and signed transcripts. Nobody waited on a roadmap for it. It was added because the stack let it be added, and that is why the agent has a page of its own.
Extensibility on the owned stack comes with the same caution as Control: what you can add, you can add badly. The release gate is what makes an open build safe to extend. Add the feature; the build still refuses to ship a page that fails a check.
No roadmap, no marketplace, no vote. A file, and a build.
Extensibility asks what you can add. Scalability asks where it stops.
Data
Do your records live in your database or someone else’s?
Scalability
Does it have a ceiling you’ll hit?
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.