Boring releases are a feature

There's a genre of engineer who loves release night. The checklist, the war-room channel, someone narrating the graphs like a sports commentator. I used to think that energy meant a team was serious about shipping.

Now I think it means the release is big enough to hurt.

At Inkitt we ship multiple times a week — a Next.js web platform and React Native apps with millions of readers on the other end — with zero downtime. I usually can't tell you when the last release went out. That's not neglect. That's the goal.

What boring means, operationally

Boring is not a temperament. It's a stack of small decisions that each remove a reason to be nervous:

• Small PRs. A reviewer can actually hold a small diff in their head. Reviews of big diffs converge to "looks good" — which is a signature, not a review.
• Branches that stay close to trunk. Long-lived branches are just merge conflicts on a payment plan.
• Feature flags. Merging and releasing become separate decisions. Code goes to production dark, and turning it on is a config change, not a deploy.
• Staged rollouts. New code meets a slice of traffic before it meets all of it. Most bad surprises show up in the first small slice, where they cost almost nothing.
• An E2E suite that runs on everything. I built our Cypress suite and still maintain it. It's what lets everything else be casual — nobody has to remember to check the signup flow, because the machine checks it every time.
• A/B tests instead of debates. When "will this hurt conversion?" can be answered with an experiment, releases stop being arguments and start being data collection.

None of these is clever. Together they mean any single release carries almost no risk, so nobody has to perform bravery about it.

Batching is where outages come from

Here's the cultural part, and it's the part that actually matters.

When deploys are scary, people batch. Why go through the ceremony twice? Wait for a few more branches, ship it all on Thursday. Perfectly rational, individually.

But batching is how you get a release with dozens of changes in it, where the one that broke production hides behind all the others. Debugging a big release is archaeology. Debugging a small one is reading the diff.

So fear causes batching, batching causes outages, outages cause more fear. Teams don't escape that spiral by being more careful. They escape it by making releases so cheap that batching stops making sense.

Releases should feel like brushing your teeth. Daily, quick, mildly tedious. Skip it for a few months and you don't get one big satisfying brushing session — you get a root canal.

What AI changed

Cost. The honest reason teams skip the boring stuff is that it's toil. Writing E2E specs, updating tests, doing the first careful pass on a PR — real work that never demos well.

Since I went all-in on agentic tooling in 2025, most of that toil got cheap. Claude Code and Cursor write first drafts. An AI review pass runs before any human looks at the code, so humans review for design instead of typos. Cypress and unit tests get drafted straight from acceptance criteria, and LLMs summarize A/B results so nobody spends a morning squinting at dashboards. The safety net used to be the expensive part of shipping fast. Now it's close to free.

Limits, so this doesn't read like a brochure. Flaky tests will spend your credibility one retry at a time, and a suite people ignore is worse than no suite — quarantine flakes fast or lose the whole thing. And there's a discipline tax: flags have to get deleted, small PRs have to stay small, staged rollouts have to actually be watched. AI lowered the price of discipline. It didn't remove the need for it.

If you lead a team, here's the metric I'd watch: how people feel in the hour before a deploy. If the answer is "nothing in particular," you've built something good.

Save the adrenaline for the product.