A release train leaves on schedule whether your code is on it or not. Every two weeks, say, whatever's merged and green goes out, and whatever missed the cutoff waits for the next one. Release-when-ready works the opposite way: a change ships the moment it passes its checks, could be ten minutes after merge, could be three times before lunch. Both are legitimate ways to run engineering. They just solve different problems, and picking the wrong one for your situation costs more than most teams realize.
What the train actually buys you
Release trains exist because coordination gets expensive past a certain team size. If forty engineers across six teams are all touching the same product, someone needs to know what's shipping and when, QA needs a fixed window to run a full regression pass, and support needs advance notice before behavior changes under their feet. A schedule gives all of that a shared clock. Mobile apps have an extra reason: app store review isn't instant, so "ship whenever" was never fully on the table to begin with — the train is partly forced by the platform.
The cost shows up in the gaps. A bug fix that's done on Tuesday but the train left Monday sits idle for two weeks, still causing the exact problem it already fixed. Worse, "almost done" work gets rushed to make the cutoff, because missing it feels expensive even when it isn't — that's how features ship half-tested, not because anyone wanted to cut corners, but because the calendar was the actual pressure, not the code.
What release-when-ready actually requires
Ship the moment something's ready and the wait time for a fix drops to nothing — which sounds obviously better until you look at what has to be true for it to be safe. Every change needs to be small enough to reason about in isolation. The test suite has to be trusted enough that "green" actually means safe, not "green, but someone should probably also click around for twenty minutes first." And feature flags need to exist, so half-finished work can merge and deploy without being visible to users yet. Skip any of those three and "release when ready" quietly turns into "release when someone's nerve holds," which is worse than a train, not better.
This is why continuous deployment tends to show up in small, fast-moving teams and struggle in large regulated ones — not because big companies are slow for no reason, but because the coordination cost that release trains solve doesn't disappear just because you decided to ignore it. It moves somewhere else, usually onto whoever gets paged when two teams' "ready" changes collide in production on the same afternoon.
The actual decision
Team size and blast radius are the real inputs here, not a philosophy about which approach is more modern. A five-person team building one product, with a test suite people actually trust, has very little to gain from an artificial two-week wait and a lot to lose from it — every fix sits idle for no reason that helps anyone. A forty-engineer org shipping into a regulated industry, or through an app store, has real coordination costs that a fixed cadence genuinely solves, and pretending otherwise just relocates the chaos instead of removing it.
Most teams don't consciously choose. They inherit whatever the last person set up, or copy what a blog post said a "mature" engineering org does, without checking whether the underlying constraints — team size, review cost, how much trust the test suite has earned — actually match. That mismatch is usually where the complaints come from: not that trains or continuous deploys are wrong in general, but that the team is running one on a problem shaped for the other.