Progressive Delivery

Shipping used to be a one-day event. A date was picked, a new version went onto the servers, and from that moment every user saw the new screens. If it worked it was a good day and if it didn't it was a bad one — and the size of the bad day was the problem. Thirty thousand users meant thirty thousand people looking at a broken screen at once.

Pagedeck shipped that way too. Theo pushed a new editor on a Thursday night, created a few documents under his own account, and decided it was fine. Support tickets started Friday morning: in one browser, characters vanished mid-typing. The symptom appeared neither on Theo's laptop nor in staging, so reproducing it ate half a day, and for that whole time every team using Pagedeck was on that editor. Rolling back to the previous version then broke documents that had already been saved by the new one.

What bites here isn't the size of the mistake but the size of its blast radius. No amount of pre-release checking catches everything. A specific browser, a slow connection, an account with 500 documents piled up, an outside guest who arrived through an invite link — conditions that are hard to assemble in advance always live on the user's side. Doubling the test suite doesn't make that gap disappear. The gap also widens as the user count grows: a symptom that never surfaced with 100 users turns up several times a day at 30,000, and those few cases never reproduce in a prepared environment.

Progressive delivery accepts that and changes direction. Instead of trying to catch everything, it shrinks the number of people the uncaught thing reaches first. Let 300 people see it instead of 30,000 and the same defect affects a hundredth as many users, and it's noticed far sooner, because the team is reading numbers rather than waiting for tickets to accumulate.

On the product axis, the release group covers putting finished work in front of users. The act of shipping once is a release; opening that release in widening slices instead of all at once is progressive delivery. Who to tell, through which channels, and how to sell it belongs to a different term, go-to-market. Progressive delivery only covers the mechanics of how the door opens. At the far end of the same group sits sunset, ending a feature or product that's no longer used, which tends to run the same shape in reverse: narrow the audience in steps rather than closing the door in one move.

Six terms sit under progressive delivery, all in the mechanisms group. They aren't six alternatives to pick from — they are tools used in order within a single rollout, and the order below is the procedure itself.

1. Feature flag — a switch that turns a feature on and off while the code already sits on the server. The other five steps all run on top of it, so it goes in first. Building a new editor means putting a branch in the code ("new editor if the flag is on, old one if not"), deploying it, and starting with the switch off.
2. Dark launch — nothing shows on the user's screen while the new code runs behind it. The new save path writes alongside the old one, but what's displayed is still the old result. Because this stage measures load and errors against real traffic and real data, a wrong answer costs nothing. It earns its keep when the visible product stays the same and only the internals are being swapped, since the two paths can be compared request by request.
3. Canary release — the first stage that reaches real users. The switch goes on for a very small group, a percent of traffic or internal accounts, and only that group's error rate and response time are compared against everyone else's. The name comes from the canaries that detected gas in coal mines before the miners did: a few go first so the rest are protected. Who belongs in that group is decided in advance — internal accounts that will report problems immediately go early, and large or outage-sensitive customers are usually held back until the last step.
4. Percentage rollout — once the canary looks clean, the share goes up in stages: 1, 5, 25, 50, 100, with at least a few hours and often a day between steps. Jumping straight to 100 hides defects that only appear past a certain volume, like the point where a server stops keeping up or an error that fires only for one kind of account. Moving 300 users at 1 percent to 7,500 at 25 percent is where load problems usually surface for the first time.
5. Kill switch — if the numbers turn bad mid-rollout, the feature alone gets switched off. It's a flag flip, so it takes seconds and requires no new deploy. Because the cause can be found afterward, the old order of diagnose-then-act is inverted here. Teams that haven't agreed in advance on who may flip it spend the 3 a.m. outage looking for whoever has authority.
6. Rollback — the last resort when flipping the switch doesn't help. Reverting to the previous version because the deployed code itself is at fault is heavier than turning a flag off, and it drags along the question of what to do with data already written the new way. Done well, progressive delivery makes rollbacks rare, because most problems get caught while the switch is still the cheaper lever.

The part teams skip is what gets watched between steps. The decision to raise the share is made on numbers, not on elapsed time. The group with the feature on and the group with it off are put side by side and compared on items chosen beforehand: error rate, response time, save success rate. How much you can tell from outside about what a system is doing internally is called observability, and a team without it can sit at 1 percent and never notice things got worse. The stages then stop meaning anything and the team is back to waiting for tickets. Picking those items before the rollout starts matters as much as having them: a team that decides mid-incident which number counts will always find one that looks acceptable.

The final step isn't reaching 100 percent — it's cleanup. Once everyone is on it, the branch and the flag come out of the code and the old path is deleted. Put that off and the next rollout is that much harder. In practice the flag gets a removal date written down when it goes in, with a reminder that fires at the owner when the date passes.

"I'll leave it at 1 percent and raise it tomorrow morning after I look at the error rate."

The deploy already happened; only the exposure share is moving now. Whether the next step happens depends on a day's worth of numbers.

"Turn that feature flag off. We're seeing errors on the payment side."

A request to drop the switch rather than revert the deploy. It takes seconds, so it comes before any diagnosis.

"I'll dark launch this one first. It won't be visible on screen."

The user keeps seeing the old result while the new code runs behind it, so load and errors can be measured before anything is exposed.

Pagedeck changes how documents are saved. Theo puts the flag in, deploys, and dark launches for three days. Comparing the new path against the old, 4 out of every 10,000 writes disagreed, and the cause was documents containing tables. He fixes it, runs another three days until the difference is zero, then turns it on for internal accounts.

The following week Mia raises it to 1 percent. Within half a day save failures run at three times normal and Theo drops the kill switch. It was on for five hours and touched 12 accounts, all of which had been on the list of people the team could call directly. Sofia calls those 12 teams before they call her, which at that size is a dozen phone calls. The cause turned out to be old-format documents in long-lived accounts. After the fix, the rollout restarted at 1 percent and climbed to 5, 25, 50 and 100 over four days. The week after full rollout, Theo deletes the flag and the old save path.

Shipped the old way, that Thursday night deploy would have handed the same save failure to 30,000 people. The difference between the two approaches isn't that one prevented the defect. Both had the defect. What differed was whether 12 people or 30,000 lived through it, and whether the team found out in five hours from a dashboard or in half a day from a queue of angry tickets.

The most common mistake is assuming progressive delivery lets you test less before shipping. It only goes to 1 percent, the thinking runs, so anything wrong gets caught there — and dividing the rollout into stages does create a feeling of safety. The two mechanisms catch different things, though. Automated checks confirm the code behaves correctly under conditions the author anticipated; progressive delivery limits the damage when the unanticipated condition lives on the user's side. Skip the first and the 300 people in that 1 percent absorb defects the test suite should have caught. Repeat that a few times and the group stops being early adopters and becomes the people who always see broken things — and at a company like Pagedeck, where internal accounts are the canary, colleagues burn out on it first.

The second mistake is treating the flag itself as the whole practice. A switch you can flip any time feels like enough. What's missing is the basis for flipping it. Without deciding the step sizes, the wait between steps, and which number has to move how far before the switch goes down, raising the share becomes a gut call and the degradation is noticed only when tickets arrive. On top of that, uncleaned flags pile up. Each flag splits a path in two, so ten leftover flags mean 1,024 combinations in theory and a handful that anyone has actually exercised. A bug that shows up months later then belongs to a combination nobody can identify, and a new hire has no way to be told why the code forks the way it does. Treat installing a switch and removing it as two halves of one task, or what's left after a few months isn't a safety device but a thicket nobody wants to touch.