The Export Button Every RAXXO Tool Ships With

The Button Nobody Asks About Until They Need It

If you use a RAXXO tool for long enough, you will eventually find an export button somewhere in its settings. Statusline Builder exports your configuration as JSON. Git Dojo exports your practice history as a plain log. OhNine exports your usage history as a CSV you can open in any spreadsheet app without RAXXO involved at all. None of these exports are flashy. Nobody has ever written in to tell me how much they love the export button. That is exactly the point of it.

An export button is a feature you build for the day someone needs to leave, or the day something breaks, or the day they simply want their own data somewhere else for a reason that is none of my business. It is insurance, not a selling point, and insurance only works if it was there before the thing it protects against actually happened. I did not add export functionality after a customer asked for it during an outage. I added it before any tool had users at all, as part of the first version, because retrofitting a promise after something has already gone wrong is not the same promise.

The habit started small, with Statusline Builder, the first tool where someone's configuration represented real, non-trivial effort, dozens of elements arranged and tuned over time. Losing that configuration to a bug, a browser cache clear, or a decision to stop using the tool felt like exactly the kind of loss that should never require my permission or my server staying online to avoid. So the export button went in during the same week as the core builder itself, not as a follow-up task on a list I might or might not get to.

Why the Format Choice Matters More Than the Button Itself

A button that exports your data into a format only the exporting tool can read back in is not really an export button, it is a backup button, and those are different promises. A backup implies you will restore it into the same system later. An export implies you can take it somewhere else entirely, read it with a text editor, load it into a spreadsheet, or hand it to a different tool that has never heard of RAXXO. That distinction is why every export from every RAXXO tool lands in a format that predates the tool itself, JSON, CSV, or plain text, nothing proprietary, nothing that requires my software to make sense of again.

This constraint occasionally makes the export less convenient for me to build. A custom binary format could pack more information more efficiently, or preserve structure a generic format loses. I have never taken that trade. The moment an export format requires my own tool to interpret it, the export stops being a genuine escape hatch and becomes a second lock-in mechanism wearing an escape hatch's name. I would rather ship a slightly less elegant JSON file than ship a format that quietly ties someone back to me even after they have decided to leave.

I also apply this rule to naming, not just structure. Every exported field uses a name that describes what the value actually is, not an internal shorthand that only makes sense next to the tool's own source code. It is a small discipline, but I have opened plenty of other tools' exports over the years and hit a field called something like `cfg2` or `d_flag` with no explanation anywhere, and had to guess. A field named clearly costs nothing extra to write and saves whoever opens that file later from reverse-engineering a decision I made and then forgot to explain. Readable field names are a small kindness to a future version of the person exporting, who may not remember the tool's internals any better than a stranger would.

There is a craft argument here too, not just a principle one. A plain format is easier to inspect, which means it is easier to trust. Anyone can open a JSON export in a text editor and see exactly what left the system, no hidden fields, nothing encoded in a way that obscures what is actually there. I wrote before about how every RAXXO product page names the specific AI tools behind it instead of hiding them behind vague marketing language, and the export format follows the same instinct: say plainly what is happening rather than making someone trust a black box. An export you cannot read is not meaningfully different from no export at all.

What Export Actually Protects Against

The honest case for an export button is not really about switching to a competitor, most of these tools do not have a direct competitor with an import path waiting on the other end. The real cases are quieter. Someone wants a local copy before trying a fresh install. Someone is auditing what a tool actually stores about them. Someone just wants peace of mind that closing a browser tab does not equal losing a year of Git Dojo practice history. None of those reasons require the tool to be failing or the relationship to be ending. Export is a everyday feature, not a breakup feature, even though breakup is the scenario people imagine first.

It also protects against a failure mode that has nothing to do with trust and everything to do with reality: things break. A browser update wipes local storage. A device gets replaced. I ship a bug that corrupts a saved state before I catch it in testing. In every one of those scenarios, someone with a recent export loses nothing but a few minutes reimporting. Someone without one loses the actual work. This is the same instinct behind the backup habit I hold myself to before any RAXXO tool ships, except this version of the habit is not mine to run on a schedule, it is a button I hand directly to whoever is using the tool, so they never have to depend on me remembering to run it for them.

I think about the kill switch every RAXXO tool ships with in a related way, the guarantee that a tool can be turned off cleanly with nothing left running in the background. Export and kill switch are two halves of the same commitment. One says you can stop the tool cleanly. The other says stopping the tool does not mean losing what you built inside it. Neither promise is worth much without the other sitting next to it.

The Cost of Keeping This Promise Honest

Maintaining an honest export button is not free, even though it looks like a small feature on a settings page. Every time I change how a tool stores data internally, the export format either has to follow that change or stay stable on purpose even as the internals shift underneath it. I lean toward the second option almost every time, keeping the exported shape stable even when the internal storage gets refactored, because a format that changes without warning breaks the actual promise of export being a reliable, boring, always-the-same escape hatch.

That stability requirement means I sometimes carry a slightly awkward internal structure for longer than I would otherwise, translating between a cleaner internal shape and an older exported shape rather than just letting both evolve together. It is a small tax, paid quietly, in exchange for never being the reason someone's old export file stops making sense. I would rather carry that translation layer indefinitely than ever have to write a changelog entry explaining that last month's export format no longer imports cleanly.

The other cost is that I have to test the export path itself as carefully as any feature someone actually asks for, even though almost nobody exercises it in a given week. An export button that silently produces an empty or malformed file is worse than no export button at all, because it creates false confidence right up until the moment someone actually needs the file and discovers it is broken. I treat that path with the same seriousness as the core feature of each tool, not as an afterthought bolted onto a settings menu.

A low-traffic feature is also an easy feature to break without noticing, which is its own separate risk from breaking it on purpose. A refactor somewhere else in the codebase can quietly leave the export function pointing at an old field name, and because almost nobody clicks the button in a given week, that kind of regression can sit unnoticed for a long time before anyone hits it. I have started treating export as one of the paths I check by hand whenever I touch the surrounding code, specifically because it is the kind of feature that fails silently rather than loudly. A crashed button gets reported fast. A button that quietly writes a slightly wrong file might not get reported at all, just quietly not trusted the next time.

Bottom Line

The export button is the least visible feature in every RAXXO tool and the one I would defend most stubbornly if asked to cut it for time. It exists for a day that, for most people, never comes, and that is exactly why it has to work correctly the one time it matters. A plain format, stable over time, built in from the first version rather than added after a request, is the whole design.

Nobody chooses a tool because of its export button, and I do not expect that to change. But the promise it represents, that using a RAXXO tool never means your own data becomes something you can only access on my terms, is one I would rather keep quietly correct than turn into a marketing line. Some features earn their place by being used constantly. This one earns its place by being trustworthy the one time it is not optional.