Every RAXXO tool gets automated backups wired in before its first real user, not after
Statusline Builder's saved-configs table went empty for six hours once, and the backup restored it before most users noticed
A backup nobody has tried to restore is just a hope, so I run a restore drill on a schedule, not only a backup job
The whole habit costs a few euros a month and has already saved real user data twice
Why Backups Are Part of "Shipped," Not an Afterthought
I used to treat backups the way a lot of solo builders do: as a task for later, once the tool actually had users worth protecting. That thinking is backwards, and I only understood why after nearly losing something that mattered.
Here is the problem with "later." The moment a tool goes live, someone somewhere starts trusting it with something: a saved configuration, a purchase record, a project file, a login. That trust starts on day one, not once the tool feels important enough to protect. If I wait until a product "proves itself" before I back up its data, I am gambling with the data of whoever shows up first, and that person did nothing to deserve being a test case.
So every RAXXO tool now gets the same treatment before launch, alongside the security review and the kill switch: automated, scheduled backups of anything a user can create or configure, wired in before the tool takes its first real signup. Not "I'll add it once the numbers justify it." Not "it's just local storage, it'll be fine." Before.
Concretely, that means a nightly export of any database, a versioned copy of anything a user uploads, and a plan for local-only data on tools that store settings on a person's own machine. Git Dojo backs up lesson progress the same day it ships, not the week I notice someone actually finished a module. Watch backs up saved projects before the feature that creates them is even announced publicly.
The mental shift that made this stick was simple: I stopped asking "does this tool have enough users to justify a backup system" and started asking "would I be comfortable explaining to the first user why their data is gone." Once I framed it that way, the answer was obvious, and the habit built itself into the launch checklist instead of living on a someday list.
It also removes a decision I used to make under pressure. Backups added after an incident are backups designed by someone who is scared and rushing. Backups added before launch are backups designed by someone with time to think about what actually needs protecting. The second kind is always better.
The Day It Actually Saved Something
Habits are easy to justify in theory and easy to skip in practice, so let me tell the one that made this non-negotiable for good.
Statusline Builder is a free tool, which made the incident almost funny in hindsight: I nearly lost user data on the one product that costs nothing to use. Its whole job is letting someone design a terminal statusline, save the result, and come back to tweak it later. The saved-configs table is small, unglamorous, and exactly the kind of thing that is easy to assume "probably won't break."
One afternoon it returned empty. Not slow, not erroring, just empty, as if every saved configuration had never existed. My first instinct was panic, because a table like that has no dramatic warning sign before it fails, it just stops answering correctly. I pulled the most recent automated export, checked it against a handful of configs I remembered testing with myself, confirmed the data was intact, and restored the table. Total time from "this is empty" to "this is fixed" was under six hours, and most of that was double-checking the restore before writing it back, not the mechanical part.
Here is the detail that stuck with me afterward. Because the backup ran automatically the night before, the actual data loss window was small. If the backup habit had started only after this incident, I would have had nothing to restore, and every saved statusline for every user of a free tool would have been gone with no way to recreate it, because a saved config is not something I keep a separate copy of anywhere else.
Nobody wrote in about it. No support ticket, no review, no mention anywhere. That is the honest measure of a backup system working: silence. The fix happened before it became anyone else's problem, which is the entire point of doing this before launch instead of after a headline.
The Restore Drill: Why an Untested Backup Is Just a Hope
The Statusline Builder incident taught me the harder lesson too: having a backup is not the same as having a backup you can trust. A backup file sitting in storage is a promise, and I had never actually tested whether that promise would hold under pressure until I needed it to.
So the habit grew a second half. Alongside the nightly export, I now run an actual restore on a schedule, not just when something breaks. I take a recent backup, restore it into a throwaway copy of the environment, and confirm the data comes back looking the way it should. This is tedious in a way that is easy to skip, which is exactly why it needs to be scheduled rather than left to good intentions.
The value of a restore drill is that it catches the failure modes a backup job alone never shows you. A backup can complete successfully and still be useless: a format that changed since the last restore, a partial export that silently dropped a table, a schedule that quietly stopped running weeks ago because of an unrelated change elsewhere. None of those show up as a red flag in the backup logs. They only show up when you actually try to bring the data back and it does not look right.
I learned this from the error log habit, honestly. Reading logs every morning only works because I look at them, not because they exist. A backup is the same kind of thing: it only protects anyone if I have actually confirmed, recently, that it works. An unverified backup and no backup at all carry the same real risk, they just feel different, and feeling safe is not the same as being safe.
The drill does not need to be elaborate. It needs to happen on a fixed cadence and it needs to end with an answer to one question: if I lost this table right now, could I have it back in an hour, verified and correct. If the honest answer is "probably," that is not good enough, and I go fix the gap before it becomes a real incident instead of a drill.
What This Costs, and What It Buys
The realistic objection to any of this is cost, both in money and in the time a one-person studio never has enough of. So it is worth being specific about what the habit actually takes, because the honest number is small.
The backup infrastructure itself runs a few euros a month across every RAXXO tool combined, using the export and versioning features most hosting and database providers already include rather than a bespoke system built from scratch. I did not build a custom backup pipeline, I turned on the built-in one and made sure it actually ran on a schedule I could verify. The setup time per tool is closer to an hour than a day, mostly spent deciding what counts as "data that matters" for that specific product.
The restore drill costs more in attention than money, maybe twenty minutes every few weeks per active product, which is a trade I will take every time over the alternative. Twenty minutes of tedium against the possibility of telling a real user their saved work is gone forever is not a close call.
What it buys is not visible on a good day, which is exactly why it is tempting to skip. On a good day, nothing happens, the exports run quietly, and there is nothing to show for the habit except a slightly longer checklist. The payoff only shows up on the bad day, and by definition you do not get to choose when that day arrives. Since I started treating backups as part of "shipped" rather than a follow-up task, it has already mattered twice: once with Statusline Builder, and once earlier with a smaller local-settings issue on a tool still in beta that never even reached a public incident because the fix happened before anyone outside my own testing noticed.
Two saves is not a large number, and that is exactly the argument for the habit. Rare, quiet problems are the ones people stop preparing for, right up until the moment they are the only thing standing between a user and lost work.
Bottom Line
The backup habit is not glamorous, and it will probably never be the reason someone tells a friend about a RAXXO tool. That is fine. It is not supposed to be the pitch, it is supposed to be the thing that makes the pitch honest.
Every tool I ship carries an implicit promise the moment someone saves something in it: this will still be here tomorrow. Backups, wired in before launch and tested on a real schedule rather than trusted on faith, are how I keep that promise even on the days something goes wrong underneath the surface. The sunset checklist I use when a tool's life ends leans on the exact same habit, because a tool being retired does not mean its users' data stops mattering.
None of this required a big team or a complicated system, just a decision made early: back it up before it needs backing up, and prove the backup works before pretending it does. A few euros a month and twenty quiet minutes every few weeks, against the one afternoon it actually matters. That trade has already paid for itself twice, and I expect it to again.
Top comments (0)