Why I Batch Every RAXXO Release Instead Of Shipping One At A Time

The Release-Whenever-It's-Ready Habit That Wore Me Down

For a long time, my rule was simple: the moment something worked, it went out. A fix felt done, I pushed it. A small feature felt done, I pushed it. There was a real appeal to that rule, because it meant nothing ever sat around finished but unreleased, and it meant every improvement reached someone using the tool as fast as it possibly could.

The problem was not the releases themselves. The problem was what releasing on impulse did to everything around the release. Every push meant stopping whatever else I was doing, writing a changelog entry, checking the tool one more time, and mentally resetting before starting the next thing. Multiply that by five tools and a habit of shipping the instant something felt ready, and I was spending more evenings context-switching between "build mode" and "release mode" than I was spending in either one for long.

I noticed it first as fatigue I could not explain. I was shipping constantly and still felt behind, which made no sense until I actually counted what a typical week looked like. I was releasing something small three or four times across the five products, and each of those releases carried the full weight of a release, the same checklist, the same changelog discipline, the same final look before it went live. The size of the change had nothing to do with the size of the interruption.

The tell, once I actually looked for it, was how often I opened a text editor to fix one small thing and closed it forty minutes later having also written a changelog entry, pushed the theme, and checked three unrelated pages just to be safe. None of that extra time went into the fix itself. All of it went into the ceremony around releasing, repeated from scratch every single time, because a habit of shipping the instant something felt ready meant there was never a moment where two or three small things were waiting together, ready to travel as one trip instead of four separate ones.

What A Batch Window Actually Looks Like

The fix was not to ship less. It was to ship on a schedule instead of on impulse. I now hold a two-week window open for each product. Fixes and small features finished inside that window do not go out the moment they are done. They wait, together, until the window closes, and then they go out as one release with one changelog entry that actually describes a coherent set of changes instead of a single isolated tweak.

This sounds like a small operational change and it is, but it rearranged how the whole week feels. Instead of five separate mental gear-shifts between building and releasing, I get one release day per product per window, and that day is entirely dedicated to the release process: the four-pass check I run on everything, the changelog write-up, the final look at the tool as a stranger would see it. Building days stay building days. Release days stay release days. The two stopped fighting each other for the same evening.

The batch window is not a rigid two weeks for every product either. Git Dojo, which teaches lessons in a fixed sequence, batches tighter because a broken lesson mid-sequence is a worse experience than a slightly delayed fix. A quieter product with fewer active users can hold a longer window without anyone noticing the wait. The number is a default, not a law, and I adjust it per product based on how much a delay there actually costs the person using it.

There is one exception I keep, on purpose: anything that is actually broken for someone, not just improvable, ships immediately regardless of where the window sits. Batching is a discipline for planned improvements, not an excuse to let a real problem sit for up to two weeks because the calendar says so. The rule only works if I am honest with myself about which category a given fix falls into, and I have gotten stricter about that honesty over time, not looser.

Statusline Builder sits at the other end from Git Dojo. It is a free tool with a simple job, and almost nothing about it is time-sensitive for the person using it, so it comfortably holds a longer window than the two-week default. Watching how differently the same idea applies across products was its own small lesson: a rule that works everywhere usually only works because nobody has actually pushed on where it should bend, and batching only earned its place once I let each product set its own honest window instead of forcing one number onto all five.

The Real Cost of Making Something Wait

I want to be straight about what batching actually costs, because it is a genuine cost, not a free win dressed up as discipline. A fix that is finished on day two of a two-week window sits finished for up to twelve days before anyone benefits from it. That is twelve days where the old, slightly worse version of the tool is still what people are actually using, and I know exactly what I fixed and exactly how much better the new version is, and I have to sit with that gap on purpose.

Early on, that gap bothered me more than I expected. Watching a finished improvement wait felt like a small failure every single day it sat there, even though I knew the batching was the right call. What eventually settled it for me was noticing that the old impulse-release habit had its own hidden cost, one I had never actually measured: releases so frequent and so small that almost nobody reading a changelog could tell what mattered. A changelog entry for one tiny CSS fix looks identical in weight to a changelog entry for a real feature, and when every entry looks the same size, none of them read as important. The changelog habit only works if the entries are worth reading, and a dozen one-line entries a month were quietly training people to skim past all of them, including the ones that mattered.

So the twelve-day wait is real, and I do not pretend otherwise. What I decided is that a slightly slower, clearly explained improvement beats an instant, easily ignored one, for a product where the person reading the changelog is trying to understand what actually changed, not just confirm that something did.

I also had to accept a smaller, quieter cost: I lose the little hit of satisfaction that comes from pushing a fix the moment it works. That feeling was never really about the person using the tool, it was about me wanting to close the loop immediately. Naming that honestly made it easier to let go of, because a habit built around my own impatience was never a good enough reason to keep interrupting a build day to run a full release process for one line of changed code.

What Batching Buys Back That Speed Never Did

The biggest shift was not in how fast fixes reach people. It was in how much attention each release gets from me. Under the old system, I reviewed each change in isolation, right after building it, still deep in the same mental context I had while writing it. That is close to the worst possible time to review something, because I am the person least likely to spot my own mistake in the minutes right after making it.

Under the batch system, the four-pass check happens on release day, days or sometimes weeks after the actual building, which means real distance sits between writing the code and reviewing it. That distance is not wasted time, it is the entire point. A cold-open test only works if the person running it is genuinely a little cold on the details, and impulse-releasing right after building never gave me that.

Batching also forces a kind of honesty that shipping-on-impulse quietly let me avoid. When five small fixes land in one window, I have to look at them together and ask whether they actually belong in the same release, whether one of them is really a bigger change wearing a small change's clothes, whether two of them touch the same part of the tool in a way that needs extra care together. Reviewing five things separately never surfaced that. Reviewing five things as a set does, almost every time.

None of this replaces the thinking that goes into deciding what to build next in the first place. Batching only governs when a finished thing goes out the door, not whether it should exist. But the two decisions turned out to reinforce each other more than I expected. Knowing a release window is coming makes it easier to say no to a half-formed idea mid-week, because there is a real deadline where "is this actually ready" gets asked out loud, instead of a vague someday when I might get around to reviewing it properly.

Bottom Line

Shipping the instant something feels done sounds like the responsible choice, and for a while I believed it was. It took counting an actual week of releases to see the real cost: constant context-switching between building and releasing, and a changelog so frequent that nothing in it read as important. A two-week batch window per product, with a standing exception for anything genuinely broken, cost me twelve days of waiting on a finished fix in exchange for one focused release day where the review is real instead of rushed.

I still notice the wait sometimes. A fix sits finished and I know it, and the old instinct to push it immediately has not fully gone away. But the releases that come out of a batch window read as coherent, deliberate updates instead of a scattered trail of tiny pushes, and that has done more for how the five tools feel maintained than shipping faster ever did.

Keep reading

BusinessThe RAXXO Tool I Killed Before It Ever Shipped 9 min read

BusinessThe Docs Page I Write Before I Touch The Code 9 min read

BusinessWhy I Don't Run Discounts on RAXXO Tools 9 min read