The Starter Template Every RAXXO Tool Begins From

Why I Stopped Starting From a Blank Folder

The first RAXXO tool I ever shipped started from nothing. An empty folder, a fresh `git init`, and a blinking cursor deciding everything from the file structure to the color of the loading state. It felt like the right way to work at the time, a clean slate for every idea. It was also how I ended up rebuilding the same handful of decisions, slightly differently, five separate times, and shipping five slightly different bugs because of it.

The pattern was always the same. I would get deep into the actual feature, the part of the tool that made it worth building, and only remember the boring foundational pieces once something broke. One tool shipped without a proper 404 state and a customer found it before I did. Another launched in light mode by accident because dark mode was supposed to be "added later" and later never came before launch day. None of these were hard problems. They were the same easy problem, solved from scratch, under time pressure, every single time.

The fix was not more discipline. Discipline is not something I can reliably apply to a decision I am making for the fifth time while also trying to finish the feature that actually matters. The fix was removing the decision entirely. Now every new RAXXO tool starts from the same starter repository, cloned and renamed, not built up from an empty directory. The first commit on any new tool already looks like a RAXXO tool before I have written a single line of the feature that makes it unique.

What Actually Lives Inside the Starter

The starter is intentionally boring. It is not a framework of its own, and it does not try to guess what the tool will do. It carries the parts that are true of every RAXXO tool regardless of what it sells: the shared design tokens, the `rx-` CSS prefix so nothing collides with a host page or a Shopify theme, a dark-mode-first stylesheet with the light variant defined but never the default, and a 404 and empty state that already look intentional instead of like a placeholder nobody got back to.

It also carries the smaller things that are easy to forget precisely because they rarely break anything visible. An accessible focus ring that survives a CSS reset. A favicon slot with the shared shape and a place to drop the tool's accent color, the same rule I follow for every RAXXO favicon before it ships. A basic error boundary so a thrown exception shows a message instead of a blank white screen. None of these are interesting to build. That is exactly why they belong in a template instead of in my short-term memory on launch week.

What the starter does not include is anything specific to a single tool's purpose. No sample business logic, no placeholder feature that has to be torn out later. I write the plan for what a tool actually does in a docs page before I touch any code, and the starter stays deliberately silent about that part. It is scaffolding for the parts every tool shares, not a guess at the parts that make each one different. Mixing those two concerns is how templates rot, and I have seen that happen to other tooling I inherited early on, which is part of why I keep the boundary strict now.

How the Template Grows Without Turning Into a Mess

Five tools built from the same starting point is also five chances to notice something the template was missing, and that is where most of its real value comes from. When Git Dojo needed a keyboard shortcut layer that the earlier tools did not have, I did not just bolt it onto Git Dojo. I asked whether every future tool would eventually want it too, and when the answer was yes, it went into the shared starter rather than living as one tool's private addition. The same happened with the loading state. I ended up removing the spinner entirely rather than making it better, and once that decision proved out across two tools, it became the starter's default rather than a habit I had to remember to repeat.

That growth only stays healthy because of one rule I hold myself to: nothing goes into the starter until it has proven itself in at least one real, shipped tool first. A template built from guesses about what future tools might need turns into speculative scaffolding nobody uses, carried forward out of inertia. A template built from patterns that already worked twice is a template I trust, because every line in it earned its place by surviving contact with an actual launch. The design system that makes five RAXXO tools feel like one studio grew the same way, one proven decision at a time, and the starter is really just that same discipline applied one layer lower, at the level of files and folders instead of colors and type.

There is a version control habit tied to this that took me longer to get right than I expected. When a proven pattern moves from a single tool into the shared starter, I try to record why, not just what, in the commit that makes the change. A shortcut key layer added because one tool's power users kept asking for it reads very differently a year later than a shortcut key layer with no context attached. Future me, opening the starter to build tool number six, needs to know whether a piece is there because it is load-bearing or because it seemed like a good idea in the moment and nobody removed it since. That small habit of writing the reason down is cheap now and expensive to reconstruct later.

The other half of keeping it clean is subtraction. Every so often I open the starter and ask what has not been used by a new tool in a while, and whether it is still worth carrying forward. A shared component that only ever got used once is not a pattern, it is a leftover, and leftovers make the next clone confusing instead of helpful. The starter is small on purpose. Growing it is easy. Keeping it honest takes actually looking at it instead of just adding to it.

What the Template Still Can't Do For Me

None of this means starting a new tool is a solved problem the moment I clone the repository. The starter gets the boring, universal decisions out of the way, which is a real gift on day one, but it has no opinion on the part that actually matters: whether the tool is worth building at all, and what it is supposed to feel like to the person using it. I still write the plan and name the tool before any of that scaffolding gets touched, because a good foundation under a bad idea is still a bad idea, just one that looks more finished than it should for longer.

The starter also cannot catch every mistake specific to a new tool's own logic. It gives me an accessible focus ring, not an accessible flow through a feature nobody has used yet. It gives me an error boundary, not a guarantee that the errors underneath it are the right ones to show a stranger. Every tool still needs its own attention on the parts that are actually new, and the template's whole purpose is to buy back the time that used to go into the parts that were never new in the first place. It narrows the problem down to the interesting part. It does not solve the interesting part for me, and I would not want it to.

There is a smaller trap worth naming too. A shared starting point can quietly encourage sameness past the point where sameness is a virtue. Two RAXXO tools solving genuinely different problems should still feel like they came from the same studio, but they should not end up structurally identical just because the clone was convenient. I check for that on purpose now, the same way I check whether a tool actually needs a redesign instead of another patch. The starter is meant to remove busywork, not creative judgment, and it is worth watching for the moment those two things start to blur.

The template also does nothing to protect me from picking the wrong feature to build inside a good foundation. A tool can inherit every good habit the starter enforces, ship with a clean empty state and a working focus ring, and still fail because the actual problem it solves was never as common as I assumed going in. I have killed a tool before it ever shipped for exactly this reason, after the scaffolding was already in place and looking convincing. A confident-looking first commit is not the same thing as a validated idea, and the starter, by making that first commit look so finished so quickly, is precisely the thing that makes it easy to mistake one for the other if I am not paying attention.

Bottom Line

Starting every RAXXO tool from the same template instead of an empty folder was never about building faster, even though it does that too. It was about refusing to solve the same boring problem five separate times and getting a slightly different answer, and therefore a slightly different bug, each time. Dark mode, the shared prefix, an honest empty state, an accessible focus ring: none of these are hard to build once. They are only hard to remember to build the fifth time, under deadline, while thinking about something more interesting.

The template earns its keep by staying boring and by only growing when a real, shipped tool proves a pattern is worth keeping. It has no opinion on what makes any single RAXXO tool worth building, and it should not. That part still starts from a blank page every time, the way it should. The starter just makes sure the blank page is about the idea, not about whether I remembered the favicon this time.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)