Rolling Out with Confidence, Part 2: The Release Control Center

The Release Control Center, or how a feature actually reaches a customer.

This one starts with two cups of coffee in Madrid.

It was April. Yaron Lavi, our CTO, and I were both at a company offsite, so we sat down over a problem he had flagged months earlier. Our enterprise customers could no longer keep up with the speed we ship at. They wanted stability. They wanted to know what was coming, when it was coming and what it would change for their people. A big part of our customer base wanted the exact opposite: the new thing the moment it existed. And underneath both, engineering wanted to keep its cadence of more than forty deploys a day. Slowing down was never on the table.

We already had a process holding the line. Phased rollouts ran on discipline and spreadsheets. What we didn't have was a way to enforce it. The process leaned on goodwill and a sense of responsibility that not everyone carries the same way. Thirty minutes in, we were both in full brainstorm mode. Part 1 had already given us the central idea: release is not rollout. Deploying code and exposing it to a customer are two different events. We had made the deploy side fast and boring — so why not use the same split to make the exposure side calm and deliberate? Two coffees and one intense Claude design session later, the idea had a name: the Release Control Center.

The paradox we had to solve

Here is the tension in one sentence. The customers who pay us the most wanted us to ship slower and the customers who grow with us fastest wanted us to ship sooner and both of them were right.

A small business signs up for Deel because it moves fast. They want the sneak peek. A new feature the day it exists is a reason they chose us. An enterprise runs payroll for thousands of people through us. For them, a surprise change in a core flow isn't a delightful update. It's a support ticket, a retraining session, sometimes a compliance question. They don't want less product. They want predictable product.

The customers who pay the most wanted slower. The customers who grow the fastest wanted sooner. The cadence underneath was never on the table.

The classic answer is to pick a lane. Ship fast and let enterprise grumble, or slow everything down and let the market pass you. We refused the choice, for the same reason we refused it in Part 1: the problem wasn't the speed, it was that speed and exposure were welded together. Every deploy carried the full weight of customer exposure, for every customer, all at once.

So we unwelded them. Again.

What rollout looked like before

I'll be honest about the starting point, because the starting point is the reason this system exists.

Feature flags existed. Phase tracking lived in spreadsheets and Jira fields, while the go-to-market process was a document people were supposed to remember to follow.

There was a sharper problem underneath. Engineers could modify production flag targeting directly. Anyone with access could toggle a feature for a specific client, bypassing every process we had on paper. It was always done with good intentions and most of the time it worked out fine. The problem was that it was possible at all. And "most of the time" and "fine" are not words you want in the same sentence as "payroll".

The risk assessment process had a similar shortcoming. A feature touching money movement, sensitive data or a new jurisdiction shipped through exactly the same path as a button colour change. The scrutiny a feature received depended on judgement and conversation, on who happened to be in the room, rather than on a system that asks the appropriate questions.

The design argument we had to have first

The obvious first design was per-organisation targeting. Every feature flag holds a list of org IDs and you manage exposure one org at a time. It's also the wrong design and Yaron killed it in a single message: a feature flag holding thousands of values makes no sense. How can a human even manage that?

He was right. If the unit of control is the individual organisation, the system collapses under its own bookkeeping before it ever ships. The unit of control had to be the group. So customers live in cohorts: our own internal testing orgs, then a beta cohort of customers who opted in to early access, then small businesses, then mid-market and enterprise. A feature doesn't roll out to twelve thousand orgs. It rolls out to a cohort, on a schedule everyone can see.

That one decision made everything after it possible.

The machine: phases, risk and a kill switch

The Release Control Center, RCC for short, is the control plane we built on top of that idea. It lives in our internal administrative platform and it's the single authorised interface for how a feature moves from "deployed and invisible" to "every customer sees it". It works in phases.

Phase 0, dark launch. The code is in production, the flag is off for everyone. This is the default state of every deploy, which is exactly what Part 1 promised: deploys are boring because nothing is visible.

Phase 1, internal validation. Our own QA organisations see it first. We break it before anyone else can.

Phase 2, limited beta. The beta cohort gets it, for a minimum of two weeks. These are real customers who chose the sneak peek, so the SMB appetite for early access became a quality instrument. They find what internal testing can't.

Phase 3, small business. The broad SMB base, again with a minimum validation window, while mid-market and enterprise stay untouched.

Phase 4, mid-market and enterprise. On a fixed monthly calendar, the second Wednesday of the month, announced in advance. Enterprise customers stopped being the first to find our bugs and started being the last, with a date they can circle.

Enterprise customers stopped being the first to find our bugs and started being the last, with a date they can circle on a calendar.

Once we defined these phases, the quality guardrails were the next concern. If you read Part 1, you'll recognise the philosophy: guardrails over trust.

Flags became read-only. GTM-managed flags can't be edited in the flag system's own interface anymore. RCC holds the only authorised write path and every change is audited. The "quietly toggle it for one client" era ended not with a policy but with a permission model.

Risk became a questionnaire, not a vibe. Registering a feature means answering thirteen structured questions. Does it touch money movement, sensitive data, new jurisdictions, AI, third parties? The answers auto-score into a risk tier. Low risk sails through with no friction. Moderate risk proceeds with a tracked risk event. Critical risk stops in its tracks until a senior reviewer, who cannot be the requesting PM or their manager, makes the call. Blast radius counts too. Anything reaching more than ten thousand users triggers review regardless of score.

The kill switch needs no approval. One click turns a feature off for a cohort, immediately, no sign-off required. Asking permission to stop the bleeding is how small incidents become big ones, so we made rollback the one action in the whole system that requires none.

And yes, the veto came along. Part 1 readers will remember approve-by-exception. Same idea here. Phase 4 doesn't wait for a parade of sign-offs from customer-facing leadership. Approval is assumed unless someone places a veto before the cutoff. The safety net stays, the dead time goes.

Exceptions exist and they cost something. Some launches genuinely need to reach everyone at once. A pricing change, a legal requirement, a coordinated market launch. For those we have a formal path, the big bang release, which bypasses the phases with executive approval, gets logged and shows up in our compliance reporting. The fast lane isn't forbidden. It's a decision a senior leader signs, not a shortcut a team takes quietly. And even exceptions are maturing, teams with a strong track record earn pre-approval instead of queueing for a signature every time.

The "quietly toggle it for one client" era ended not with a policy but with a permission model.

One system, four seats

RCC only works because everyone who touches a rollout sees it from their own seat, in their own language.

The engineer creates the flag and wires it into the code, with a Claude Code skill doing most of the wiring from a single command. From that point on they read production targeting, they don't write it. Their job ends at "deployed and dark", exactly where Part 1 left off.

The product manager registers the feature, answers the risk questionnaire and owns the journey through the phases. The registration mirrors the go-to-market epic in our ticket tracking system, so there is one source of truth and no duplicate bookkeeping. When a phase has a date, the system moves the flag on that date. No midnight toggling.

The customer success manager gets the view that used to require asking three engineers. Open any organisation and see exactly which features are live for it and in which phase. Look across an entire book of accounts in one aggregated view. Manage a per-org exception through a form instead of a favour.

The customer gets the newest seat of all, a release view inside the product itself. More on that in a moment, because it deserves its own section.

Everyone who touches a rollout sees the same system from their own seat, in their own language.

The gates that stop a rollout

A phase isn't a waiting room where a feature sits until a date passes. Moving forward has to be earned and the system checks the homework. Two principles sit underneath everything. A feature must not break production when its flag is off and it must not break production when its flag is on. No gate, workaround or exception overrides those two.

Coverage grows with exposure. We don't demand full test coverage upfront, we scale it with risk. Entering dark launch requires automated happy paths. Reaching the beta cohort requires every main user journey covered. Reaching the broad base requires full flows, edge cases and integrations, passing at a rate very close to perfect. A feature with no automated happy path doesn't enter production, dark or not.

Flag isolation is proven, not assumed. Before dark launch we verify zero bleed between flag states. Off means genuinely off. No interface leakage, no API side effects, no data quietly mutating for customers who were never supposed to see anything.

Open bugs block progression. A feature with unresolved bugs from an earlier phase doesn't move to a bigger audience, however nice the calendar looks.

The kill switch is rehearsed. Turning a feature off must be tested explicitly before broad exposure, with rollback completing in minutes. An untested kill switch is a decoration.

Misconfigured flags get caught by machines. With a flag service, RCC and a ticket tracker all holding a piece of the state, disagreement is inevitable, so we detect it instead of discovering it. A validator checks that a flag exists and matches its registration before a feature can progress. It also catches values left undefined in lower environments before they surprise production. A daily reconciliation job compares the actual value of every flag against the value its phase says it should be, and posts every mismatch it finds. Drift still happens. It just doesn't get to be invisible.

And the principle that ties all the gates together: if you cannot monitor it, you cannot release it.

Rolling out the rollout system

Here's the part I find funniest in hindsight. We had to roll out the rollout system and we used the rollout system to do it.

RCC was registered in RCC. It went through its own phases, its own risk assessment, its own beta. There is a go-to-market ticket for the go-to-market platform. Call it having our cake and eating it too. We shipped the governance tool through the governance it prescribes and found its bugs in the early phases, the same way we find everyone else's.

The discipline came before the platform. For the first few months, phased rollout ran as pure process, training across R&D, compliance checks bolted onto the release pipeline, humans holding the line. Then the platform arrived and over the following months every product and engineering team moved onto it. One system, one source of truth. To ensure adoption, we blocked the creation of new flags in the legacy system entirely. Old habits don't retire voluntarily.

Adoption was not a montage of applause. The support channel filled with legacy flags that couldn't be renamed and features stranded in a phase because a date was set one day wrong. There was also honest confusion from engineers who could no longer flip a toggle they used to own. One message from those weeks stuck with me: "First time trying to use the system, maybe I have already broken it." They hadn't. And most of what people asked for made the product better.

AI carried part of the adoption load too. Akai, our internal platform for AI agents, runs the daily flag reconciliation I mentioned above and chases the mismatches so no human has to. The same pattern as Part 1. The machine does the chase-y work, the humans keep the decisions.

What the numbers have shown us

The point of all this was never process for its own sake. It was to catch problems in small rooms instead of big ones. So, did it?

A few months in, the weekly quality report answered with numbers I still enjoy re-reading. 339 bugs were stopped in the internal and beta phases and never reached the broad customer base at all. The main customer population was receiving 24.9 percent fewer bugs per week than the baseline from before phasing. Customer-detected bugs dropped 27.4 percent quarter over quarter. Every one of those numbers is a bug that got found by someone whose job is finding bugs, or by a beta customer who signed up to find them, instead of by an enterprise payroll manager mid-cycle.

Bugs get found by people whose job is finding them, or by beta customers who signed up to find them, instead of by an enterprise payroll manager mid-cycle.

And then something happened that I didn't fully expect. Some enterprise customers started emailing to ask if they could join the beta cohort. The same audience that triggered this whole journey by asking for stability was now asking for early access, because early access had become a choice instead of a surprise. That's the moment I knew the model was right. Predictability isn't the opposite of speed. It's what makes speed acceptable.

The customer side of the glass

The last mile of a rollout isn't a flag flipping in a database. It's a payroll manager or an HR admin logging in on a Monday morning and noticing their product has changed. Everything that happens before that moment exists so the change is never a surprise.

So the newest layer of the system faces the customer directly. A release view sits inside the product. An organisation sees what's coming to them, what's already live for them and what's further out. The view is filtered to the products they actually use and fed live from RCC. So nobody maintains it by hand and it can't drift out of date.

The release view also proved its worth sooner than we expected. An enterprise account wanted more visibility into our changes, and the ask reached us: could this customer have the release view now? It was one toggle in RCC. Turned on, verified, visible within minutes, for exactly one organisation. Not long ago that sentence would have described a two-week engineering project. That support thread is the entire idea in miniature. Exposure became a product surface we control per customer, at the speed of a click.

Today the release view is a window, read-only by design. The next steps make it a door. Enterprise admins will be able to raise a formal request to delay a feature for their organisation, with a reason, a review by the owning product team and a full audit trail. Rollout delays for a specific account will become a standard offer a customer success manager can make, instead of a favour they beg engineering for. And AI takes over more of the manual layer as we go. Release labels generated by AI, so a customer instantly knows a cosmetic change from an action they must take. Automated risk controls replacing questionnaire steps. An AI eligibility checker that scans code and catches unregistered features before they ever deploy. Each manual version retires as its automated replacement proves itself.

The two machines together

Put the two halves of this story side by side and the picture is simple. A release machine moves code from an engineer's laptop to production many times a day, without ceremony. A rollout machine moves features from production to customers with exactly as much ceremony as each customer needs.

The release machine ships code without ceremony. The rollout machine exposes features with exactly as much ceremony as each customer needs. The feature flag is the hinge between them.

Fast for the customers who want fast. Calm for the customers who need calm. The same forty-plus deploys a day underneath both.

If you're building your own version, the ideas travel just like last time. Group customers into cohorts, because per-org targeting doesn't scale past a spreadsheet. Make phases the default and exceptions expensive. Score risk with questions, not instincts. Give the kill switch to everyone and require approval from no one. Make flags writable by exactly one system. And let agents do the reconciliation, the integration and the chasing, so your people spend their judgement where it matters.

One more thing. This system didn't build itself either. It took product, engineering, QA, risk, enablement and customer teams pulling in the same direction. It also took a CTO who spent half a day at an offsite setting the direction for how an entire company ships. Massive credit to every one of them. Rolling out with confidence was the goal from the first cup of coffee in Madrid. Now, it's just how we work.