Every RAXXO tool ships one favicon built from a shared shape, tested at 16 pixels before launch
Same silhouette, different accent color per tool, so five open browser tabs still read as one studio
One icon file has to survive three jobs: browser tab, apple touch icon, and phone home screen
A four-point checklist runs before any icon ships, and one tool failed it twice before I let it out the door
Why a Favicon Is Never an Afterthought
I used to treat the favicon as the very last file I touched before a launch, something I dragged into the theme folder five minutes before publishing a product page. That habit broke the day I had three RAXXO tools open in three tabs at once and could not tell them apart without hovering over each one. They were all a plain letter on a plain background, different colors chosen on different days for different reasons, and none of them looked like they belonged to the same studio.
That is the actual job of a favicon. Nobody stares at a 16 pixel square on purpose. They glance at it while switching tabs, while scanning a crowded bookmarks bar, while deciding which of ten open windows to click back into. If the icon does not do its job in that half second, it has failed, no matter how good it looks blown up in a design file.
I now treat the favicon as part of the launch checklist for every RAXXO tool, not a decoration. Git Dojo, OhNine, the Blueprint installer, Statusline Builder, and the main storefront all needed one before I called any of them done, and I write the icon brief before I write a single line of the product page. That brief has one question at the top: will this still be recognizable at the size a browser actually renders it, next to four siblings that need to look related but not identical.
The mistake is designing an icon the way you would design a logo, big, detailed, meant to be admired up close. A favicon has one job at one size. Anything that only works large is not a favicon yet, it is a logo waiting to fail its first real test. I learned this the hard way with an early OhNine icon that looked sharp at 512 pixels and turned into a gray smudge at 16, because the detail that made it readable disappeared the moment it shrank.
So the rule now runs backwards from how most icon work gets done. I do not start big and shrink down. I start at 16 pixels, get it legible there first, and only then check that it still holds up scaled to the sizes phones and app icons actually need. Small first, big second, is the opposite of instinct and it is the only order that has ever worked for me.
One Shape, Five Colors
The fix was not five unrelated icons designed to be individually pretty. It was one shared shape, drawn once, and one rule for how each tool gets to differ from the others. Every RAXXO icon starts from the same base geometry, a simple mark that reads clean at tiny sizes without fine detail, hairline strokes, or gradients that turn to mud when compressed.
What changes per tool is the accent color, and only the accent color. Git Dojo gets one hue, OhNine another, Statusline Builder a third, each pulled from the same constrained palette I use across the design system so nothing clashes when they sit side by side in a tab strip. The shape stays fixed. The studio mark underneath never moves. Only the color shifts, the same way the tone guide keeps every tool sounding like one voice even though each one solves a different problem for a different kind of buyer.
This is the same logic behind the shared design system that every RAXXO section pulls from: one shared system, small deliberate variation on top, never five tools that each reinvented their own conventions from scratch. A shared favicon shape does for the browser tab what the shared system does for every product page. It tells you, before you read a single word, that this thing came from the same place as the other four.
The test I run is embarrassingly simple. I open all five products in adjacent tabs and look at the row of icons without reading any of the titles. If I cannot tell at a glance which is which, the color difference is not doing enough work. If they do not look like a family, the shape has drifted too far from itself. Both failures are real, and I have hit both. The first Statusline Builder icon draft picked a color close enough to the Blueprint accent that side by side they were nearly the same square, and it went back for a second pass before anyone outside my own browser ever saw it.
Where the Icon Actually Shows Up
A favicon file does more jobs than its name suggests, and I did not plan for all of them the first time around. There is the actual browser tab, the smallest and least forgiving size. There is the apple touch icon, the version that appears when someone adds a product page to their phone's home screen, which needs more presence because it sits on a screen full of app icons competing for attention. There is the thumbnail some browsers show in bookmark grids and recently closed tab lists, and there is the small badge that can appear next to a link preview when a page gets shared.
Each of those contexts renders the same source image at a different size against a different background, sometimes light, sometimes dark, sometimes with rounded corners forced onto a square file by the operating system. An icon that only gets tested in one context, usually the browser tab because that is the one you see constantly while working, can quietly fail in every other context and nobody notices until a customer sends a screenshot of a broken-looking home screen icon.
So the actual deliverable is not one file, it is one shape exported at the handful of sizes each surface expects, checked in each context before the tool ships. That means opening a page on an actual phone and using the browser's own add-to-home-screen action, not trusting a mockup of what it should look like. It means checking the icon against both a light and dark browser chrome, since every RAXXO tool ships in dark mode first but customers do not all browse in dark mode, and an icon designed only against a dark tab bar can wash out completely against a light one.
This is the part that is easy to skip because none of it is visible during normal development. You build the product page, you preview it in your own browser with your own settings, and the icon looks fine because your setup happens to match the one context you tested. The failure only shows up on someone else's phone, in someone else's browser theme, which is exactly the customer you cannot afford to lose in the first five seconds of touching your product.
The Checklist Before Any Icon Ships
I run four checks before a new RAXXO favicon goes live, and I added the fourth one only after the Statusline Builder near-miss. First, render it at actual favicon size, 16 pixels, and confirm it reads without knowing what it is supposed to be in advance. If you have to be told what the shape is, it is not passing.
Second, check it against both light and dark browser chrome. A shape that only works on a dark tab bar is only half tested, and RAXXO customers use whatever browser theme they already had before they ever found the store.
Third, and this is the one most icon guides skip entirely, place it next to the other four RAXXO icons in one tab strip. An icon that passes alone can still fail here if its color sits too close to a sibling's, and this is the only check that catches that specific problem, because nothing about testing an icon in isolation reveals a clash with the tool ten tabs away.
Fourth, add the actual page to a phone home screen and look at the result next to the other apps already sitting there. This is the check that catches apple touch icon problems, corner rounding surprises, and the general gap between how confident an icon feels on a monitor and how small and easy to overlook it becomes surrounded by a home screen full of competitors for the same square inch of attention.
Four checks, in that order, small to large, isolated to crowded. Skipping any one of them is exactly how the near-miss happened, since the failing version passed the first check fine and only broke on the third. A favicon that clears all four before launch is one less thing that quietly tells a returning customer this tool feels different from the last one they bought, in a bad way, before they have read a single word of the actual page.
Bottom Line
A favicon is one of the smallest assets attached to any RAXXO tool and one of the easiest to treat as an afterthought, which is exactly why it used to get treated that way. The fix was not more design effort, it was a fixed order of operations: one shared shape, one accent color per tool, tested small before it is ever tested big, and checked in every context it will actually appear in rather than just the one you happen to be looking at while you build it.
None of this is complicated on its own. What makes it work is doing it the same way every single time, for every tool, before launch rather than after a customer notices first. Five tools that each got their icon treated as a real design decision, instead of a five minute afterthought, end up looking like one studio without anyone having to say so. That is the actual payoff, not a prettier tab, just one more small signal that everything under the RAXXO name was built with the same care, whether you are looking at the product page or the sixteen pixel square sitting quietly in the tab above it.
Top comments (0)