Every RAXXO tool gets a fixed retirement checklist the day I decide to sunset it, not the day usage quietly hits zero on its own
The signal I wait for is three flat check-in cycles in a row, never one bad week, the same rhythm I already use to catch a tool that needs a redesign
Anyone who already owns a sunset tool keeps using exactly what they bought, nothing changes on their end, the wind-down only affects what I do with new signups and future updates
Retiring a live tool on purpose, before it breaks or embarrasses a customer, protects the tools still running far more than one more feature ever would
The Signal I Wait For, Not the Panic Button
I already run a regular check-in across every RAXXO tool, the same habit that tells me when something needs a redesign instead of a patch. Retirement uses the exact same rhythm, just reading for a different pattern. A redesign gets triggered by a tool that people are actively using but fighting with. A sunset gets triggered by a tool nobody is fighting with anymore because nobody is opening it.
The rule I hold myself to is three flat cycles in a row, never a single quiet week. A slow week happens for reasons that have nothing to do with the tool itself, a holiday, a platform outage somewhere upstream, a change in how I am promoting something else that quarter. Reacting to one dip would mean killing tools for the wrong reason on a regular basis, which is worse than being slow to retire the right one. Three cycles in the same direction with nothing else obviously explaining it is a pattern, not noise, and that is the bar I actually wait for before I let myself even consider the word retirement.
The harder part is honesty about which direction I am reading the data in. It is easy to see what you expect to see in a dashboard, and a founder who built something is the worst possible judge of whether people still need it. So the check-in is written down the same way every time, the same few numbers, checked against the same threshold, rather than a gut feeling I talk myself into on a slow Tuesday. That structure is what keeps a sunset decision from turning into either denial, keeping a dead tool alive out of attachment, or overreaction, killing something that just had a quiet month. Both mistakes cost more than the checklist does.
I also separate a flat tool from a seasonal one before I let the three cycle rule apply at all. Some RAXXO tools are built around a task people only need at certain points in the year, and a flat cycle for that kind of tool in its off season means nothing. The checklist only fires for a tool that should, by its own nature, see steady use and is not getting it. Skipping that distinction would mean sunsetting something useful just because I checked on it at the wrong time of year, which is a mistake the checklist exists to prevent, not cause.
What I Actually Do the Day I Decide
The first move is never public. I stop building anything new for that tool immediately, which is easy since by definition nobody is asking for new features on something usage has already left behind. The second move is checking what the tool touches. Nothing in the RAXXO catalog exists fully in isolation, most tools share a snippet, a section, or a piece of the account system with something else still very much alive, so the first real work is confirming a shutdown does not quietly break a tool I have no intention of retiring.
Once that is confirmed clean, I write the customer facing note before I write anything else. It says plainly that the tool is being sunset, what date it happens, and exactly what stays true afterward for anyone who already bought it. What stays true is the whole point: anyone who already owns it keeps using exactly what they have. Nothing about their access changes, nothing gets clawed back, nothing requires them to do anything at all. The wind-down only closes the door for new signups and stops future updates from arriving. That distinction is what separates a studio being honest about a product's lifecycle from a studio quietly abandoning the people who trusted it early.
Only after that note exists do I touch the storefront itself. The listing comes down from active discovery first, existing customers keep their access path exactly as it was, and the redirect goes up last, after I have confirmed nothing else on the site still links into the old page expecting it to be there.
The order matters more than any single step in it. Pulling the listing before the customer note exists means someone who bought the tool last month could stumble onto a dead link before ever hearing from me directly, which turns a planned wind-down into something that looks like the tool just vanished. Writing the note first and waiting for it to actually reach people before changing anything visible is the difference between a retirement and a disappearance, and only one of those keeps trust intact for the next tool I launch.
The Difference Between Killing Early and Retiring Late
I have written before about the RAXXO tool I killed before it ever shipped, and it is tempting to treat that decision and a sunset as the same instinct wearing two names. They are not. Killing an idea before launch costs nothing but the hours already spent building it, and nobody outside the studio ever knew it existed to miss it. Retiring something live means real people built a habit around it, however small that group is, and a habit deserves more care on the way out than an idea that never left my own laptop.
That is why the sunset checklist is slower on purpose everywhere the pre-launch kill decision was fast. A tool that never shipped just stops, quietly, and I move on to the next idea. A tool with actual customers gets a written note, a fixed date, a confirmed dependency check, and a storefront change sequenced in a specific order rather than pulled all at once. The speed difference is not sentimentality, it is proportional to how many people are depending on the thing being retired staying predictable right up until it changes.
The same logic explains why I would rather ship a tool that dies quietly a year later than never ship a smaller, riskier idea at all. A studio that only launches things guaranteed to run forever ends up launching very little. Building a real retirement process is what makes it safe to keep taking those smaller bets in the first place, because I know exactly what winding one down actually looks like before I ever have to do it for real.
What the Checklist Actually Protects
The obvious answer is that a sunset checklist protects the customers of the tool being retired, and it does, but that is not the main reason I keep it this strict. The bigger reason is that it protects every other tool still running. A studio with one person behind it has a hard ceiling on attention, and every tool kept alive past the point people actually use it is attention that the tools people do use are not getting instead.
I keep a running changelog for every tool that is still active, and a sunset tool coming off that list is not a failure showing up in the log, it is the log staying honest about what I am actually maintaining right now versus what I built once and left running out of inertia. A changelog full of updates to tools nobody opens anymore is worse than an empty one, because it hides where my real attention is going behind activity that does not matter to anyone reading it.
This is also why I keep shipping small tools instead of one big product. Small, separate tools are easier to retire cleanly than a single sprawling product where every feature is entangled with every other one. A clean sunset checklist is only possible because the thing being sunset was scoped small enough in the first place to close a door on without the rest of the building shaking.
That scoping decision happens long before retirement ever enters the picture, which is exactly why it has to be made on purpose at build time rather than fixed later. A tool that shares its checkout flow, its account system, and half its Liquid sections with three other products cannot be sunset cleanly no matter how good the checklist is, because pulling it out means untangling code that was never meant to travel alone. The tools I can retire in an afternoon are the ones I built to stand alone from day one, sharing only the pieces that were always meant to be shared, like a snippet or a base layout, and nothing that would make removing them a surgery instead of a switch.
Bottom Line
Retiring a tool on purpose is not the failure it feels like the first time you have to do it. The failure is the tool nobody uses that keeps sitting on the storefront collecting a small share of attention it no longer deserves, or worse, quietly breaking for the handful of people still relying on it because nobody was watching closely enough to notice it needed a decision. Three flat cycles, a written note before anything changes on the storefront, and a hard promise that existing customers keep exactly what they already have. That is the whole checklist. It is boring on purpose, and boring is exactly what a decision like this should be. The tools still getting my attention are better for it every time an old one gets a clean exit instead of a slow, unmanaged fade.
Top comments (0)