Every structured website platform makes the same trade: give up total control in exchange for speed, consistency, and not having to think about breakpoints ever again. For most clients, most of the time, that trade is a good one.
Then a client asks for something specific. A conversion-tracking pixel their ad agency insists on. A hover animation on the hero button that matches their old Squarespace site. A cookie-consent script their lawyer sent over as a fait accompli. None of it is in the visual editor, because none of it is common enough to deserve a toggle.
This is the moment an agency either says "we can't do that on this platform" β and starts quietly planning the client's exit to a fully custom build β or reaches for code injection and just does it.
The Trade-Off Every Agency Platform Makes
Most no-code builders solve the "one weird request" problem by not solving it. You either live inside the constraints of the visual editor, or you leave the platform entirely for a custom WordPress or hand-coded build β at which point you've traded a fast, structured workflow for an open-ended maintenance commitment, forever, on every future update.
Pro Studio exists because that's a false choice. An agency shouldn't have to abandon a platform's structure just because one client needs one thing outside it.
Two Places to Reach the Metal
Code injection in Pro Studio works at two levels, depending on how wide the change needs to be. Global CSS and JS β set from a dedicated Code Injection page β apply across every page of a site: the tracking pixel, the consent script, a sitewide font override. Per-section CSS β set from the Dev tab inside the same design editor you already use for everything else β scopes a change to one section only, so a hover effect on the hero doesn't leak into the pricing table three sections down.
Both are inline text fields, not a file upload, not a build step, not a deploy pipeline. Type it, save it, it's live on the next publish.
The point isn't that agencies want a terminal. It's that they want the last 3% without losing the other 97%.
Guardrails, Not a Blank Terminal
Handing raw script access to anyone with dashboard access is a real risk, not a hypothetical one β a copy-pasted snippet from a forum post can be a lot more than a hover animation. So every save runs through an automated scan before it's accepted: known-malicious patterns (credential theft, obfuscated payloads, legacy code-execution vectors in old CSS) are rejected outright with a plain-English reason, while anything ambiguous is flagged for review rather than silently blocked. It's a seatbelt, not a lecture β it doesn't get in the way of the 99% of injected code that's a legitimate integration snippet.
Code injection is also gated to Pro Studio's Scale tier specifically, and it's scoped to the actual live site β not to shareable preview links, which strangers could open without ever logging in. The capability is powerful enough that it should only ever run where the business owner actually controls what's being shown.
How Pro Studio Handles This
Global CSS and global JS are merged from wherever an agency sets them β the dedicated Code Injection page or the live design editor's own Dev tab β so nothing gets silently dropped depending on which screen was used to save it. Per-section CSS is automatically scoped to just that section, using the same targeting the rest of the design engine already relies on, so a client-requested override behaves predictably instead of cascading somewhere unexpected.
None of it requires a developer to touch a deploy pipeline, and none of it requires the agency to explain to a client why "just add this one script" means migrating platforms. It's the same dashboard, the same publish button, with a door left open for the requests that don't fit a dropdown.