Ship Your Sandboxes

I have a /artifacts section on this site that’s hidden from search engines. It’s where I put the stuff that doesn’t belong anywhere else: test pages, visual demos, component sandboxes. The kind of thing most developers keep in a local branch and delete when it works.

I don’t delete mine. Here’s why.

The testing problem#

Every feature I build for this site needs a sandbox before it earns a spot in real content. The mermaid diagram renderer needed a gallery page to stress-test every diagram type against both light and dark themes. Code blocks needed a page with every language, every edge case, every copy-button interaction. Image galleries needed frames, lightboxes, zoom behaviors.

You can’t test any of that in the actual blog posts. The content is the content. You don’t want to litter a post about distribution strategy with “TEST: nested code block with 200-line Python snippet” just to see if the scroll container behaves.

So I made artifacts a first-class content type. They live in the CMS alongside everything else, render through the same build pipeline, use the same components. The only difference is noindex: true and a separate route.

Living references#

Static screenshots lie. They show what something looked like at a specific moment, not what it does now. Artifacts stay current because they’re rendered by the same code that powers the rest of the site.

When I refactored the code block component to add line highlighting, I didn’t need to go verify it worked. The code blocks test page already had every variant. I just opened it and saw the results.

This is the opposite of documentation that rots. The artifact can’t fall out of sync with the implementation because it IS the implementation.

Archaeology of your own decisions#

Iteration is invisible by default. You change a component, push it, move on. The old version evaporates from git history where nobody will ever look at it.

Artifacts capture the decision points. Why does the mermaid renderer use CSS variables for theming instead of baked-in colors? Because the mermaid gallery made it obvious that hardcoded colors broke when you toggled themes. That page is the evidence. The reasoning is embedded in the artifact itself.

Six months from now, when I’m wondering why something works the way it does, the artifact is faster than git blame.

The portfolio angle#

When a client asks “can you build X?” the worst answer is “yes, probably.” The best answer is a link. Artifacts aren’t case studies. They’re proof. Concrete, clickable, current.

They’re also honest in a way that polished portfolio pieces aren’t. A demo page with rough edges says “I’m actively building this” more convincingly than a perfect screenshot that could be from two years ago.

Beyond visual components#

Artifacts aren’t just for testing how things look. They’re for testing how things feel.

When I added haptic feedback to this site, I needed somewhere to experiment with vibration patterns, audio ticks, and touch interactions. That became the haptics gallery, a page where I can tap through every vibration preset, drag a slider with audio clicks on each step, and compare approaches side by side on an actual phone.

You can’t evaluate haptics from a code review. You have to feel them. The artifact is the only way to know if the feedback is too aggressive, too subtle, or timed wrong. It’s a test bench that happens to live at a URL.

That’s the real pattern here. Artifacts aren’t a feature of this site. They’re how this site gets built.