A public roadmap is a promise with a date on it, and I would rather ship the right thing late than the promised thing on time
I changed direction on a tool mid-build more than once, and a published roadmap would have made that change look like a broken promise instead of a good call
The changelog does the job a roadmap claims to do, except it only ever describes what is actually true
What I do share in the open is direction, not dates, and that difference is the whole point
A Roadmap Is a Promise With a Date Stapled to It
People ask me fairly often whether Git Dojo, OhNine, Statusline Builder, or Claude Blueprint has a public roadmap. The honest answer is no, and it is not because I have not gotten around to building one. I have thought about it and decided against it on purpose, more than once.
A roadmap looks like a list of features. It is actually a list of promises, and every promise on it comes with an implied date even when there is no date written down. The moment something sits in a "coming soon" column, a reader mentally files it as owed to them. If it slips, and solo work slips constantly for reasons that have nothing to do with effort, that slip reads as a broken promise rather than what it actually was: a plan that met reality and changed.
I run five tools by myself. Git Dojo teaches git from the terminal instead of a GUI. OhNine watches Claude usage limits from the menu bar. Statusline Builder generates a live status line for Claude Code. Claude Blueprint packages a full Claude Code setup into one install. RAXXO Studio turns a single video or image into content shaped for different platforms. Each one competes for the same evenings and weekends, and priorities between them shift for reasons a public list can never capture in advance: a bug that turns out to be bigger than it looked, a feature request that reveals the real problem was somewhere else entirely, a change in Claude Code itself that makes an old plan pointless overnight.
A roadmap assumes the future is knowable enough to schedule. Mine is not, not because I am disorganized, but because the tools I build sit on top of a fast-moving platform I do not control. Anthropic ships changes to Claude Code on its own timeline, not mine, and a chunk of what I build exists specifically to make those changes easier to live with. Planning six weeks out and publishing it as a commitment would mean either ignoring what Claude Code actually does in the meantime or quietly abandoning a public promise, and neither option is honest. I wrote before about the one-sentence test that decides whether an idea is even worth a build slot, and that same process runs continuously, not on a quarterly schedule a roadmap would imply.
The Time a Published Plan Would Have Looked Like a Broken Promise
The clearest argument against a public roadmap is not theoretical, it is a pattern that has repeated across more than one tool. I start building toward a specific feature, get partway through, and discover the real problem was one layer away from where I was looking.
With Statusline Builder, the early plan in my own head was to add more preset variety first, on the theory that more choice was the obvious next win. Partway into that work, the actual feedback I was hearing was not "I want more presets," it was "I cannot tell which preset I am looking at without clicking through each one." The presets were never the bottleneck. Preview clarity was. If I had published "more presets, next release" on a roadmap page, shipping a preview overhaul instead would have looked like I skipped what I promised, even though skipping it was the right call for anyone using the tool.
The same shape happened with OhNine. The plan was to expand it outward, more integrations, more surfaces. What people actually needed was for the one thing it already did, watching a Claude usage limit from the menu bar, to be more trustworthy and less noisy. Chasing outward growth first would have been building the wrong thing confidently. A roadmap rewards confidence about the future. Real building rewards being willing to admit the plan from three weeks ago was wrong.
This is not indecision. It is closer to the opposite: a small studio's actual advantage over a bigger team is the ability to change direction in a day instead of a quarter, because there is no roadmap review, no stakeholder sign-off, no public commitment to walk back. A published roadmap would trade away the exact flexibility that makes shipping alone, and shipping well, possible at all. It is the same instinct behind the feature requests I turn down outright, just pointed at my own plans instead of someone else's suggestion.
What I Publish Instead, and Why It Only Describes What Already Happened
If a roadmap is a promise about the future, a changelog is a record of the past, and the past is the only thing I can describe with full honesty. That is why every tool ships with a changelog file that gets a line written the moment a change is finished, not a list of what I intend to do next.
The changelog does almost everything a roadmap claims to do, minus the part that causes problems. It tells someone what is different since they last checked. It shows the tool is actively maintained, which is the real question behind "is there a roadmap" most of the time anyway, people are usually asking "is this thing still alive," not actually asking for a Gantt chart. It builds a track record you can scroll through and verify yourself instead of a set of claims you have to trust in advance.
The difference in direction matters more than it sounds like it should. A roadmap point is a claim about tomorrow that asks for trust today. A changelog line is a claim about yesterday that you can check against the tool sitting in front of you right now. One is a promise, the other is a receipt, and a receipt cannot be broken the way a promise can. I have written before about the specific rule that keeps the changelog honest, the line gets written before the change counts as done, never after, and that ordering is what makes it worth reading at all.
There is also a quieter benefit for me directly. Not maintaining a roadmap means I never have to spend an evening updating a plan instead of building something. The changelog line takes under a minute because I write it while the change is still fresh. A roadmap update takes longer, because it means re-litigating priorities that were never fixed in the first place, and doing that on a schedule instead of when it actually matters is a tax I have decided not to pay.
Where the Line Actually Sits: Direction Yes, Dates No
None of this means I stay quiet about where things are headed. Refusing a roadmap is not the same as refusing to say anything. The line I draw is specific: I will talk openly about direction, never about dates.
Direction means I am comfortable saying, in general terms, that I care more about making five focused tools solid than folding them into one bloated product, and I have explained the reasoning behind that choice before. It means I will tell someone honestly that a particular kind of request, the ones that try to turn a small tool into a different tool entirely, gets declined on principle rather than lack of time. It means the changelog itself is a kind of direction signal, because a steady stream of small, real entries says more about where a tool is going than a list of unshipped features ever could.
Dates are where I stop. I will not say "next month" about anything, because I do not actually know, and saying it anyway just moves the dishonesty from the plan to the timeline instead of removing it. I will not commit a specific feature to a specific release, because the whole point of staying small is keeping the freedom to reorder that the moment a better use of the time shows up. Anyone who has watched the changelog for more than a few weeks already has a better read on my actual pace than any roadmap page could give them, because they are watching what happened, not what someone hoped would happen.
This split, open about direction, closed about dates, is not a policy I picked because it sounds humble. It is the only version of "here is where this is going" that I can say without eventually having to walk something back in public. A roadmap I do not fully control the timeline for is a roadmap I would eventually have to apologize for. A changelog only ever has to describe what is true.
People sometimes push back on this, reasonably, by pointing out that a roadmap gives them something to plan around too. If someone is deciding whether to build a workflow on top of one of these tools, "no idea what is coming" is a genuinely worse answer than a rough plan would be. I take that seriously, which is why direction is not a throwaway line for me, it is the actual substitute. Saying plainly that Git Dojo will keep teaching git through real terminal exercises instead of turning into a general course platform, or that Statusline Builder will stay free and focused rather than growing a paid tier bolted onto the same interface, gives someone a real answer to plan around. It just refuses to attach a week number to it, because the week number is the part I cannot actually promise.
Bottom Line
I do not publish a roadmap for any RAXXO tool, and it is not an oversight, it is a decision I would make again. A roadmap turns a plan into a promise, and plans for a one-person studio change too often, for good reasons, to survive being promised in public. What replaces it is a changelog that records what actually shipped, written the moment it is true, plus honesty about the direction I am building in without ever pinning that direction to a date I cannot guarantee. If you want to know where a tool is headed, the changelog already shows you better than a roadmap page would, because it only ever tells you what really happened. That is a smaller claim than a roadmap makes, and it is the only kind of claim about the future I am willing to stand behind.
Top comments (0)