Every RAXXO tool ships a settings page before its first customer, not after the tenth complaint
The default skeleton is four sections: appearance, notifications, account and data, and reset
Every new setting starts off, not on, unless the tool breaks without it
I test settings with a keyboard and a five year old account before I call the page done
Why the Settings Page Ships on Day One
Most solo builders treat a settings page as a nice-to-have, something you bolt on after launch once people start asking for it. I flipped that order years ago, after I watched a support thread turn into a week of one-off email replies because a tool had no way to turn off a sound effect. The fix took ten minutes. Finding out I needed to make it took a week of back-and-forth, because there was nowhere in the product for someone to just flip a switch.
Now every RAXXO tool gets a settings page before the first customer sees the product, not after the tenth complaint. It does not need to be big. Statusline Builder shipped with four settings. Git Dojo shipped with three. The point is not coverage, it is having a place. A settings page is a pressure valve. Without one, every preference becomes a support ticket, and every support ticket becomes a decision I have to make live, under time pressure, instead of one I already made calmly while building.
There is a second reason, less obvious but just as real: a settings page is where a tool tells you what it thinks matters. Open the settings for any of my five live tools and you can guess what I worried about while building it. OhNine's settings lead with menu bar behavior, because that tool lives or dies by not being annoying from the corner of a screen. Git Dojo's lead with terminal color scheme, because half its audience works in a dark terminal and half in a light one, and I refuse to guess which camp a new user is in.
I write the settings page before I write half the features it will eventually control, using an empty version of the section with placeholder toggles. It sounds backward, building the control panel for a plane before the plane exists, but it forces a useful question early: if this were live right now, what would someone need to change immediately. Answering that before I write the feature usually improves the feature itself. If a setting feels necessary from day one, the feature underneath it is probably making an assumption it shouldn't.
The Default Skeleton: Four Sections, Not Fifty
Every RAXXO settings page starts from the same four-section skeleton, whatever the tool. I did not always structure it this way. Early tools had a single flat list of toggles, and by the time there were a dozen of them, nobody, including me, could scan the page in under ten seconds. The four sections fixed that, and now a new tool inherits the skeleton on day one instead of growing into chaos and getting refactored later.
Appearance comes first, because it is the setting people reach for within their first minute in any product. Theme, density, font size where it applies. Notifications comes second: what the tool is allowed to interrupt you for, and through which channel. Account and data comes third: what is stored, how to export it, how to delete it. Reset is last and always alone at the bottom, separated by space so nobody taps it by accident while scrolling.
That order is not arbitrary. It goes from least destructive to most: changing a theme costs nothing, resetting an account costs everything. I learned that ordering the hard way, from an early version of one tool that put "clear all data" directly under a font size toggle. Someone reset their whole workspace trying to make the text bigger. The interface didn't warn them enough, and it definitely didn't protect them from a slip of the thumb on mobile.
That single incident changed more than the ordering. It also set a rule for anything destructive: a confirmation step, worded in plain language about what will actually happen, never a generic "are you sure" that a tired thumb dismisses without reading. "This clears your saved layouts and cannot be undone" tells someone something. "Are you sure?" tells them nothing, and asking it trains people to tap through it without thinking, which defeats the entire purpose of asking in the first place.
The skeleton also means every RAXXO tool feels like the same studio built it, even though the five live products solve completely different problems. Someone who has used the Statusline Builder settings already knows where to look for the equivalent screen in Git Dojo. I did not design for that consistency directly, it fell out of reusing the same four-section shape every time, which is usually how the good defaults in this studio happen. Related to that thinking is the starter template every RAXXO tool begins from, which carries this same settings skeleton into every new project before a single custom feature exists.
The Setting That Starts Off, Not On
Here is a rule I hold harder than almost any other: a new setting starts off by default unless the tool actually breaks without it turned on. Notifications start off. Sound starts off. Any kind of background activity, syncing, polling, auto-anything, starts off. The only exception is a setting whose absence would make the core feature not work at all, and even then I ask twice before shipping it that way.
This is the opposite of what most software does. Most products turn everything on by default because engagement metrics reward it, and turning things off quietly, later, after people are already annoyed, is treated as an acceptable cost. I do not have that incentive structure here and I do not want it. A one-person studio survives on trust that compounds slowly, not on short-term engagement numbers that decay the moment someone feels manipulated.
Practically, this means every new feature I add gets a five second gut check: does this need to interrupt or observe the user by default, or can it wait until they explicitly ask for it? Nine times out of ten, waiting is fine. The tenth time is usually something core to the product working at all, like Git Dojo needing terminal color detection to render correctly, and even that gets exposed as an override rather than hidden as an assumption.
The upside of defaulting to off is that anyone who turns a setting on did it on purpose, which means when I do get feedback about that feature, it comes from someone who wanted it in the first place. That is a much more useful signal than feedback from someone who never asked for the behavior and just wants it to stop. I would rather have fewer people using a feature and know that all of them chose it than have everyone using it and not know why.
How I Test a Settings Page Before I Call It Done
A settings page is not done when every toggle works. It is done when it survives four specific tests, and I run all four before I let myself call a tool finished. First: keyboard only, no mouse, tab through every control in order and confirm focus is visible at every step. This catches more bugs than anything else on the list, because a settings page built visually and never tested with a keyboard almost always has a toggle or two that a mouse can reach and a keyboard cannot.
Second: a five year old account, or as close to one as I can simulate, with every setting already changed away from its default in some combination nobody planned for. New settings pages get tested against a blank account constantly and against a messy, aged one almost never, which is exactly backward, because the messy account is what real users actually have after using a tool for months. If a setting silently resets or a page crashes because it did not expect an old value in a field, that is the moment to find it, not three months after launch when someone else finds it for me.
Third: phone width, because that is where I test every RAXXO tool first, and a settings page is one of the easiest screens to get right on desktop and wrong on a small screen. Toggle rows that wrap badly, labels that get cut off, a reset button that ends up one careless thumb tap away from a section people actually use.
Fourth: I check what happens to the empty state of the settings page itself, on a brand new account that has never touched a single toggle. Every value should read as its real default, not as a blank field that looks broken. A checkbox that renders unchecked because no value was ever saved looks identical to a checkbox someone deliberately turned off, and a new user has no way to tell the difference between "this is off by design" and "this page is broken." Every default needs to be an explicit value in the code, never an absence that happens to render as off.
All four of these checks together take maybe half an hour, and they catch problems that would otherwise surface as one confused support message at a time, weeks apart, each one looking unrelated to the others until I finally notice the pattern connecting them.
Bottom Line
A settings page is not a feature I add when people ask for it, it is infrastructure I ship with the first release, because the alternative is turning every preference into a support conversation I have to have individually. The four-section skeleton, appearance, notifications, account and data, reset, keeps five very different tools feeling like they came from the same place, and defaulting every new setting to off keeps the studio's trust intact instead of spending it for a metric I don't even track.
None of this needs to be elaborate to work. The smallest RAXXO tools ship with three or four settings and that is enough, because the goal was never coverage, it was giving people a place to make the product theirs without having to email me first. The keyboard pass, the aged-account pass, and the phone pass take less time combined than one bad support thread does, and they happen before launch instead of after someone else finds the gap for me. That trade is the entire argument for building the page early: twenty minutes now against a week of one-off replies later, every single time.
Top comments (0)