← Product

Case study 01 · Concept · Systems design · Color science · AI direction

Insulator

9 crates · 5 platforms from one source · 1,220 tests passing

An offline music player with two interfaces, and the split is by form factor rather than by taste. The classic Winamp form — genuine .wsz skin support — is a fixed 275×116 framebuffer, so it belongs where windows dock: desktop, and iPad. A phone has no windows to dock, so it gets ARC — the modern skin, and my design. You pick a photograph from your library and it becomes the ground the interface sits on. One decision about where the thing is used, not two features. An insulator holds high tension so it never arcs; ARC is the one place that energy is allowed to show. No streaming, no account, no network. It plays the files you already own. See the proof — the phone interface, with live controls →

I built it because of how I actually work. Long hours on composites, mockups and edits with my own music running — and every player wanted an account and a connection first. High tension, low noise: the line carries the music and nothing else gets through.

My role
Concept, product design, naming and the trademark clearance behind it, the color system, AI direction.
Built with
Claude — Rust, nine crates, 296 commits, 1,220 tests passing. I wrote the build as twenty-one ordered specs, with acceptance criteria where it mattered, then directed against them.
Status
In build — fourteen of twenty-one specs built, nine of them with direct evidence and five inferred from the artifacts rather than checked. On the desktop it plays, loads real .wsz skins, and manages a 3,083-track library across five roots with audio-fingerprint duplicate detection; the default skin that ships with it is painted. ★ The iOS build renders my own Winamp Classic skin from the same shared Rust compositor — the architecture argument above, proven rather than asserted. In the simulator: it has not run on physical hardware yet. Remaining: the iOS shell, packaging, a hardening pass.
The decision it turns on

The Winamp UI is a framebuffer, not a widget set. 275×116 pixels of RGBA — no layout engine, no text metrics, hit-testing by rectangle comparison. Once you see that, the whole architecture falls out of it: the interface can live in shared code as pixels, so each platform needs only a window, a bitmap and an audio sink — a few hundred lines. It also means the interface can be tested as an image, which you cannot do to a native widget tree. And it means a photograph can be the interface. One observation, three consequences. That is what looking closely buys you.

the photograph A 35mm film scan looking up between city towers at night in the NYC Financial District, sodium-lit yellow-green against a dark sky, printed with the sprocket holes left in down both edges.
the interface it becomes

Open the full design proof — the same interface at size, with the decisions written beside it.

ARC — the other interface, and this one is my design. The classic shell reproduces Winamp; this is the mode where the design is a decision rather than a reproduction. The user picks a photograph from their own library and it becomes the ground the interface sits on — one image behind all three panels, cut out by them, desaturated under the controls so white type stays legible over any picture. That constraint is the whole design problem: the app cannot know what photograph is coming.
Ergonomic UXOne-handed thumb operation, on the hand already holding the phone — for the controls you actually use. Most players assume two thumbs and a desk. ARC assumes one hand and no surface, and the design work is deciding which controls have earned that reach. Winamp stacks player, EQ, playlist; ARC inverts it to playlist, player, EQ, because on a phone the lowest third is the reachable third and browsing belongs up top, where a scroll gesture works from anywhere. ★ Playback and browsing sit in comfortable thumb reach. The equalizer does not need to — an EQ is set once to your listening preference and left there, so it is not a one-handed control, and pretending otherwise would be designing for a demo rather than a commute. It still takes the bottom, because when you do adjust it you are dragging — sustained, precise, over a small vertical range, and nothing compensates for poor reach on a drag. ⛔ Which is also why it locks. The equalizer occupies the most reachable band on the screen and is disengaged by default: the thing your thumb passes over most often is the thing you least want to move by accident. Unlock it deliberately, and by then you are probably using two hands anyway. ⛔ And nothing is pinned to the very bottom edge — that band sits outside the comfortable thumb arc and forces a regrip, which is exactly what most apps get wrong.
the photographA 35mm film scan, NYC Financial District at 2am that I shot on the street and printed with the sprocket holes left in. The full design proof is published, with live controls — drag them and the phone re-themes →
The half nobody sees — and the rule it inherited

A skin and an EQ are what a music player looks like. The library is where you live in it. Insulator's is 7,700 lines that decide what music exists, and a second crate that decides what should change about it — duplicates, filenames, missing album art. That second crate cannot change anything.

Every operation it produces is a plan, handed to a separate safety layer that owns the dry run, the undo journal, atomic writes and quarantine. The safety layer was built before any of the features that need it, because — in the build guide's own words — written three times inconsistently, it is the thing that eventually eats someone's music. When two copies sit in albums whose tags disagree, the default is keep both. Album art is written beside the file, never embedded, because that is reversible.

The tag reader has the same shape: it never rewrites a tag. When it thinks an album artist is wrong or text was decoded in the wrong character set, it writes a proposal into a review table and waits. A scanner that silently repairs is indistinguishable from one that silently corrupts — and afterwards there is nothing left to compare against.

★ I did not decide that for this product. Seven years earlier I wrote lab tooling that reclaimed drives and rebuilt systems, under one rule: anything that deletes or overwrites shows you exactly what it found, then waits for a yes. The same sentence, in Rust, enforced by a database that has nowhere to store the destructive version.

All five product case studies →

The design-side case study → — where the color comes from: a photograph in, a palette out, and a brand system built to survive being handed to the audience.