Five live products, OhNine, Git Dojo, Statusline Builder, Blueprint, and RAXXO Studio, share one dark UI system
Only two accent colors carry every tool, a cyan and a lime, unchanged since the first product shipped
The one CSS rule that matters most is a shared class prefix that keeps custom code from colliding with the store theme
The payoff is recognition without a logo, and a lot less time spent per launch deciding what a new tool should look like
Why I Wrote Design Rules Before I Wrote Any Second Product
The first tool I shipped, I designed the way most people design a first thing: by feel. Pick a background, pick a color that looks good against it, ship it, move on. That works fine when there is one product. It stops working the moment there is a second one, because “by feel” on a different day produces a different palette, a different spacing rhythm, a different voice. String five of those together and a visitor moving between them reads it as five different freelance jobs wearing the same store name, not one studio.
So before I built the second product, I wrote down the rules I had been applying by instinct to the first. Not a brand book, nothing that precious, just a short list I could check a new section against: one background color, two accent colors, one heading font, one monospace font for anything that looks like code or a label, and text that is off white, never pure white. That last one sounds small until you put it next to a dark background. Pure white on charcoal reads harsh, almost clinical, and slightly cheap in a way that is hard to name until you see the softer version next to it. An off white, closer to F5F5F7 than FFFFFF, reads calmer and more considered. Once I noticed that difference I never wrote pure white into a stylesheet again.
The other rule that mattered immediately was a naming prefix. Every custom class in every section file starts with rx-. It looks like a small thing, and it is, until a theme update or a base template introduces a class name that happens to collide with something a custom section is using, and suddenly a homepage element is borrowing padding it was never meant to have. A consistent prefix is a five-second habit that prevents an afternoon of debugging which rule actually won. I did not know that the first week. I know it because it happened once, and the fix was writing the rule down so it could not happen twice.
None of this was a plan drawn up in advance. It was reverse-engineered from a first product that already worked, then applied forward so every product after it started from the same baseline instead of a blank page.
The Two Colors and One Font Pairing That Carry Every Tool
Every RAXXO product sits on the same charcoal background, roughly #1F1F21, with the same two accents doing all the signaling. A cyan, #00FCED, carries links, active states, and anything that needs to say “this is interactive.” A lime, #E3FC02, carries the punchier moments, primary buttons, highlighted numbers, the one thing on a page that should pull the eye first. That is the whole palette. No third accent color has been added since the first tool shipped, and that is deliberate, not an accident of laziness.
With one product, adding a third color for one special section is harmless. With five products built over time, in different moods, on different days, an open palette turns into a slow drift where every new tool ends up looking slightly different from the one before it, and nobody notices until they are side by side. Two accents is a constraint that removes a decision. When I start a new section file, I am not choosing a color, I am choosing which of the two existing colors fits the moment, which is a much smaller and much faster question.
Typography follows the same logic. Headings and body copy run on Outfit, a rounded, slightly heavy sans-serif that reads as friendly rather than corporate. Anything that represents code, a terminal, a label, or a piece of data runs on JetBrains Mono, which signals “this is technical” the instant your eye lands on it, no explanation needed. Mixing those two typefaces on purpose, sans for the human voice, mono for the technical one, does more to tell a visitor what kind of content they are looking at than any amount of copy could.
The reason this holds together across five different codebases is that the values live as shared variables, not repeated hex codes. A new section references the same cyan, the same charcoal, the same border color that every other section already uses, instead of a fresh developer, in this case also me, guessing a similar-but-not-quite shade from memory. I wrote more about the psychology of getting a dark palette to feel intentional rather than default in Dark Mode Design That Doesn’t Look AI, and the short version is that consistency, not cleverness, is what makes a dark theme feel designed.
The Small Interaction Patterns That Repeat On Purpose
Colors and fonts are the part people notice first, but the patterns underneath them are what actually save time on every new build. A handful of small interaction rules repeat across every product, and I treat them as fixed the same way I treat the palette.
Scroll-reveal animation is one. Elements fade and rise into place as a visitor scrolls, the same easing curve, the same short delay stagger, on every page across every product. And every single instance of it respects prefers-reduced-motion: if a visitor’s system says reduce motion, the animation is skipped entirely and the content simply appears. That fallback is not optional or added later, it is part of the pattern itself, because a motion effect that ignores an accessibility setting is not a polish detail, it is a bug.
Video and embeds follow a click-to-load rule. Nothing from a third party, no YouTube player, no external script, loads before a visitor actually asks for it by clicking play. The visible element is a static preview with a play button; the real embed only gets created on that click. It is a pattern I built once, for one product, and now reuse anywhere video shows up, because it means every page stays fast by default instead of fast only after someone remembers to optimize it.
Cards get a border, never a hard drop shadow. Badges are rounded pills in mono type. Terminal mockups, used to show what a command or a script output looks like, share one visual structure: three dots for window controls, a monospace body, syntax-style coloring inside. I wrote about some of the CSS techniques behind these kinds of details in 5 CSS Animations That Needed JavaScript Until 2026, and the throughline is the same one as the palette: build the pattern once, reuse it everywhere, and a new product spends its build time on what makes it different, not on reinventing what should already be settled.
File naming carries the same discipline. Every section follows section-[page]-[name].liquid, so any file’s purpose is legible from its name alone, whether I am looking at it six months later or asking Claude to find the right one. Consistency at the file-system level is the same idea as consistency at the pixel level, just one layer down.
What Consistency Actually Buys a One-Person Studio
The clearest proof this works is not a metric, it is a moment. Someone posts a screenshot from one product in a chat, no logo visible, no URL in frame, and someone else immediately says “that’s a RAXXO thing.” That recognition is running entirely on color, type, and layout rhythm. No name attached, and it still reads.
The second benefit is speed, and it compounds every time a new product starts. When the palette, the type pairing, and the interaction rules are already decided, a new section file inherits all of it by referencing the same variables and the same patterns. The open questions left for a new build are the ones that actually matter: what does this tool do, what does the layout need to explain, where does a visitor’s attention need to go first. None of the time goes into re-litigating a color choice that was already made two products ago.
The third benefit is trust, and it is the one that matters most because it is the one a visitor actually feels even if they never articulate it. Someone who spent time on one RAXXO product and found it well made arrives at a different one expecting the same care, because the visual language told them, correctly, that the same person built both. I wrote about the broader version of that discipline, keeping several small, focused tools coherent instead of one sprawling product, in How to Structure a Monorepo for Multiple Products. The design system is the visual half of that same idea: small, separate things that still read as one studio.
None of these rules are complicated. A charcoal background, two accent colors, two typefaces, a short list of interaction patterns, and a prefix that keeps everything from colliding. What makes them work is that they are treated as fixed, checked against every time, rather than reconsidered from scratch on every new page.
Bottom Line
A one-person studio cannot out-produce a team, there is only one person and one set of hours. What it can do is out-consistency one, because every decision, every color, every animation, every naming choice, routes through the same person every time. That is not a talent, it is a habit, and habits are the part of a design system that actually holds it together once the excitement of a new product has worn off and it is just another Tuesday build.
The rules I follow are small enough to hold in my head: one background, two accents, two typefaces, a handful of interaction patterns, one prefix. None of them are clever on their own. What they add up to is a studio where five different tools, built for five different problems, still look like they came from the same place, because they did. If you want to see it for yourself, open any two RAXXO pages side by side. The proof is not in anything I can claim here, it is in whether they feel like the same place before you have read a single word.
답글 남기기