Pay the Toll: Why Your Deployment Pipeline Needs More Gates, Not Fewer
In 1706, a consortium of Hertfordshire landowners and merchants obtained an Act of Parliament to establish one of Britain's earliest turnpike trusts. Their problem was straightforward: the roads connecting their towns were in a state of chronic disrepair, churned to mud by the very commercial traffic that depended on them, with no reliable mechanism for funding maintenance. Their solution was equally straightforward—charge the users.
Toll gates appeared at intervals along the road. Traffic slowed. Coins changed hands. The roads were repaired, widened, and maintained. Within decades, journey times between major British cities had dropped dramatically. The turnpike network became the infrastructure backbone of the Industrial Revolution.
The toll gate was not an obstacle to progress. It was the mechanism that made progress sustainable.
Three centuries later, DevOps practitioners are making a mistake the turnpike trustees would have found baffling: they are removing the toll gates and wondering why the roads keep breaking.
The Friction Fallacy
The case against deployment friction is not without merit. Poorly designed approval workflows genuinely do impede delivery. Bureaucratic sign-off processes that require three managers to approve a one-line configuration change are not quality gates—they are organisational dysfunction dressed in the language of governance. The frustration that drove the 'automate everything, approve nothing' school of DevOps thinking was a rational response to genuinely dysfunctional processes.
But the response overcorrected. In eliminating bad friction, many teams eliminated the concept of friction itself. Continuous deployment pipelines now exist in which code travels from a developer's laptop to production with no human checkpoint whatsoever. Every gate has been automated away. Every pause has been eliminated. The pipeline moves at the speed of the commit.
This is not engineering maturity. It is the software equivalent of removing all the toll gates and then being surprised when the road surface deteriorates.
The turnpike trusts understood something that modern DevOps culture has partially forgotten: not all friction is equal. There is friction that impedes without protecting—the redundant approval, the manual step that could be automated, the review that adds delay without adding insight. And there is friction that earns its cost—the checkpoint that catches a misconfiguration before it reaches production, the staged rollout that limits blast radius, the approval gate that ensures a deployment has been reviewed by someone who understands its downstream consequences.
The discipline lies in distinguishing between the two.
What the Toll Gate Actually Did
Turnpike toll gates served several functions simultaneously, and understanding all of them is necessary before drawing useful parallels.
They funded maintenance. Revenue collected at the gate was reinvested in the road itself. The gate was not extracting value—it was recycling it. Without the toll, there was no mechanism for the road to sustain itself against the damage caused by its own use.
They metered access. Heavy wagons paid more than light carriages. The pricing structure was an imperfect but genuine attempt to align cost with impact. Those who imposed greater wear on the infrastructure contributed proportionally more to its upkeep.
They created accountability. The gate was a record-keeping point. Traffic was logged. Revenue was tracked. The trust could observe, at a granular level, what was moving through its network and when.
They prevented overuse. By introducing a cost to access, toll gates modulated demand. They were not intended to prevent traffic—they were intended to ensure that traffic remained at a level the infrastructure could absorb.
Now consider your deployment pipeline. Does it fund its own maintenance? Does it meter access in proportion to risk? Does it create accountability? Does it prevent overuse?
If the answer to most of these questions is 'no', your pipeline has removed the toll gates without replacing the functions they served.
Designing Gates That Earn Their Cost
The turnpike trusts did not place toll gates at random. Gates were positioned at the entry points to maintained sections of road, at bridges, at junctions where traffic converged. The placement was deliberate and functional.
Deployment gates should be designed with the same intentionality. The question for each gate is not 'does this slow us down?' but 'does this protect something worth protecting, and is it the most efficient mechanism for doing so?'
Consider the following categories:
Environment promotion gates. The boundary between a staging environment and production is the single most consequential transition in your deployment pipeline. A gate at this boundary—requiring confirmation that automated test suites have passed, that observability tooling is in place, and that a rollback procedure has been verified—is not bureaucracy. It is the toll gate at the entrance to the maintained road. Removing it does not make the journey faster. It makes the road less reliable.
Change volume gates. Large changesets carry disproportionate risk. A gate that flags pull requests above a defined size—not to reject them, but to require additional review—mirrors the turnpike's heavier tariff for heavy wagons. The gate does not prohibit large changes; it ensures they receive proportional scrutiny.
Dependency update gates. Automated dependency updates are a genuine productivity gain, but they benefit from a gate that reviews security advisories and breaking changes before promotion. The gate here is not a human reviewer approving every update—it is an automated check that surfaces the subset of updates requiring human attention.
Off-hours deployment gates. Many organisations deploy at any hour, then wonder why incidents cluster outside business hours when support capacity is reduced. A gate that requires explicit justification for deployments outside a defined window is not a restriction on engineering autonomy. It is a recognition that the blast radius of a failed deployment is not constant across time.
The Maintenance Funding Problem
The most underappreciated function of the turnpike toll was its role in funding maintenance. Roads that were not maintained deteriorated. Deteriorated roads caused accidents, delays, and damage to vehicles. The cost of non-maintenance was borne not by the trust but by its users.
This dynamic plays out identically in deployment pipelines. Teams that remove quality gates in the name of velocity typically find that the time saved in deployment is spent—with interest—in incident response, hotfix cycles, and the slow degradation of production reliability. The friction was not wasted time. It was maintenance funding.
This is, ultimately, the strongest argument for deliberate gates in your pipeline. Not that friction is intrinsically valuable. Not that slowness is a virtue. But that the functions served by well-designed gates—maintenance funding, risk metering, accountability, demand modulation—do not disappear when the gates are removed. They simply become someone else's emergency.
The Road Worth Maintaining
Britain's turnpike network was eventually superseded—by railways, then by publicly funded roads. The trusts did not last forever, and nor should any particular pipeline architecture. The lesson is not that toll gates are permanent fixtures but that the functions they serve are permanent requirements.
The engineering teams at Knight-Ware Labs that operate the most reliable deployment pipelines are not those with the fewest gates. They are those who have thought carefully about which gates to keep, why those gates exist, and what each one is protecting. They have, in the language of the turnpike trustees, matched the toll to the road.
The next time someone proposes removing a deployment gate to improve velocity, the right question is not 'does this gate slow us down?' It is 'what was this gate maintaining, and who will pay for that maintenance now that the gate is gone?'
The trustees of the Hertfordshire Turnpike Trust knew the answer. It was the users. It was always the users.