One shared Liquid snippet feeds the header, the pricing block, and the download email across every RAXXO product
A single one-line edit meant for one tool silently changed behavior in two others before I caught it
The fix was not more caution, it was a three-question test I now run before touching anything shared
Every shared file now ships through one product first, watched for a full day, before the other four ever see it
Why One File Can Touch Five Products at Once
Running five live products alone means reusing code on purpose. I am not writing a header from scratch for OhNine, then a slightly different one for Git Dojo, then another for Statusline Builder. I wrote about the visual side of this in the design system that makes five RAXXO tools feel like one studio, the shared colors, the shared type pairing. What I did not write about at the time is that the same logic applies underneath the visuals, to actual working code, and that layer is far less forgiving of a mistake.
A handful of snippets sit underneath everything. One renders the site header and footer. One builds the digital download email every customer gets after checkout. One handles the pricing block that shows up on every product page, formatted the same way everywhere, 5EUR not EUR5, because that consistency matters as much as the visual one does. Reusing these files is the only way one person keeps five products from drifting apart in small, annoying ways, a stray formatting difference here, a broken link there. Shared code is what makes a one-person studio behave like a team that actually talks to itself.
The tradeoff is blast radius. A bug in a page unique to one product stays contained to that product. A bug in a shared snippet ships everywhere that snippet is included, the moment it is included, with no natural boundary to stop it. I understood that as a fact before I understood it as a felt consequence. Those are different kinds of knowing, and only one of them changes how carefully you work.
Most days that gap between knowing and feeling never gets tested, because most edits to shared files are genuinely small and genuinely safe, a spacing tweak, a label rewording, a link that needed updating. Doing that dozens of times without incident is exactly what builds the false confidence that the next edit will be just as harmless. Nothing about the process changes between the edit that is fine and the edit that is not, until you go looking for the difference on purpose, which is not something a single person working alone naturally does under normal conditions.
The Edit That Looked Safe and Wasn't
The change that taught me the difference was small enough that I almost did not think twice about it. I was adjusting how the pricing snippet displayed a discounted price for one specific product listing, a formatting tweak, nothing structural. The snippet took a product handle as a condition, and I added a check for the new handle alongside the existing one. It read correctly. It rendered correctly on the page I was testing. I pushed it.
What I had not accounted for was that the same conditional block, further down in the same snippet, controlled a related layout choice for a different product entirely, one that happened to share a naming pattern with the handle I had just added. The condition I wrote to catch one product also matched part of another product's handle, because I had used a partial string match instead of an exact one, a habit that had never caused a problem before because no two handles had ever overlapped that way. Two products I had not touched changed layout, quietly, on pages I was not watching.
I found it by accident, checking a page for something unrelated, not because a warning went off. Nothing crashed. Nothing errored. It just looked wrong in a way that took a second to place, and once I saw it I understood exactly why: three products sharing one file, and I had tested the change against a single one of them before deciding it was safe for all three. Nothing about the code was clever or unusual. The mistake was entirely in believing that one clean test on one product told me anything about the other two.
What made it worse in hindsight is how quiet the failure was. A crashed page announces itself. A layout that is subtly wrong does not, it just sits there looking slightly off, easy to walk past without registering exactly what changed. If a customer had landed on either of those two pages during that window, nothing would have stopped them from checking out, nothing would have thrown an error, the page simply would have looked a little less finished than it should have. That kind of failure is the one I trust myself least to catch on my own, because there is no signal telling me to go look.
The Three-Question Test I Added Afterward
I did not respond to this by writing more tests, or by being more careful in the vague way that resolution usually means in practice, which is to say not really changing anything. I wrote three questions I now have to answer, in writing to myself, before any edit to a shared file goes live.
First: which products include this file, by name, not by memory. I keep a short running list next to each shared snippet now, because "I'm pretty sure it's just these two" is exactly the confidence that caused the problem in the first place. Second: does this change use an exact match or a pattern match against anything that varies by product, a handle, a tag, a title. Partial matches are precisely how one product's fix leaks into another's layout, and after finding that out once, I do not trust myself to eyeball a regex or a contains check and know it is safe. Third: what does this look like on every product on the list, not the one I was thinking about when I wrote the change, checked one at a time, deliberately, after the edit and before it goes anywhere near a live push.
None of these three questions are sophisticated. That is sort of the point. The failure was never a lack of skill, it was a shortcut, testing the product I had in mind and assuming the rest would follow along fine because they usually do. A written checklist does not care whether I am confident that day. It asks the same three questions whether the change feels trivial or not, which is exactly the situation where a shortcut is most tempting and most dangerous, the same lesson I landed on from a completely different angle when I wrote about the four-pass check every RAXXO tool goes through before I call it shipped.
Writing the questions down did more than close the specific gap that caused the bug. It changed how long an edit to a shared file takes, on purpose. A change that used to take five minutes now takes closer to fifteen, because three of those minutes are spent answering questions instead of typing code. That extra time is not friction I am trying to remove later. It is the entire point of the checklist, a deliberate speed bump placed exactly where speed previously caused the problem.
What Changed About How Shared Code Ships Now
The bigger change was not the checklist, it was the order of operations. A shared file used to go live everywhere at once, because it lives in one place and every product simply reads from it. Now it goes live in one product first, always the one least likely to have customers actively using it at that hour, and I watch that single product for a full day before the same file is allowed to reach the other four. That delay costs nothing but a day, and a day is nothing next to the cost of a formatting bug sitting quietly on three product pages until someone happens to notice.
This connects directly to a habit I already had for anything genuinely risky, the instant off switch I wrote about in the kill switch every RAXXO tool ships with. Shared snippets did not have an equivalent for a long time, because a formatting change never felt like the kind of risky feature that needed one. It is now the same principle applied one layer down: assume the change you are about to make can reach further than you expect, and build in a way to catch that before it spreads, not after.
The staged rollout also changed how I write the shared files themselves. Conditions that vary by product now use exact matches by default, never partial ones, unless there is a specific and documented reason a partial match is actually what is needed. That single rule alone would have caught the original bug before it shipped. It is a small rule. It came from one afternoon of confusion that was entirely avoidable, and now it is not optional.
None of this turns a one-person studio into something it is not. I am still the only person reviewing every shared change, still the only person deciding when a day of watching one product is enough to trust the rest. What changed is that the process no longer depends on me remembering to be careful in the moment. The order itself, one product first, exact matches by default, three questions answered in writing, does the remembering for me, which is the only kind of discipline that actually survives a day when I am moving fast and would otherwise skip straight past it.
Bottom Line
The bug itself was minor, a layout that looked slightly wrong on two pages for less than a day. What stuck with me was how little it took to cause it, one string match that was a little too loose, tested against the one product I happened to be thinking about. Shared code across five products is not a nice-to-have, it is the only way one person keeps a studio this size from drifting apart in small ways nobody would notice until a visitor compared two pages side by side. But shared code means a mistake in one place is a mistake everywhere that file is read, instantly, with no wall between products unless I build one on purpose. The fix was not trying harder. It was writing down three questions I now have to answer every time, and giving every shared change one product and one day to prove itself before the rest of the studio ever sees it.
Top comments (0)