Will Streeter

IInvisible Man found me at Berkeley — not as an assignment but as a collision. The novel made something click about how systems are designed to make certain people unseeable, and what it takes to redesign them from the inside out. Ellison's narrator is perpetually legible to himself but illegible to every institution he moves through — and the novel is the account of what it costs to keep insisting on your own visibility. The instinct that formed in that reading never left. It migrated, intact, into every piece of software I've built since: the conviction that the right system makes something that was invisible to everyone else suddenly, undeniably there.

BBefore software, there was a classroom. The same instinct — make the invisible legible — applied to algebra and to the students who had been told, in small and large ways, that they could not do it. The work was identical: find the gap between what someone knows and what they can show, and close it. Not by simplifying the material but by building a better entry point into it. The lesson about entry points never stopped applying. Every product problem I've worked on since has been, at its root, a teaching problem — someone has something fully formed in their head that they cannot yet make legible to anyone else.

TThe first real product. A web TV platform built before streaming was a category — before the category had a name, before the infrastructure existed to support it at scale, before anyone had figured out what the interface should feel like. The question the product kept asking was not technical but experiential: what does it feel like to browse video the way you browse a magazine? At some point I said it out loud, and the CEO picked it up and started repeating it as the product vision. That sentence has not stopped being true. Navigation is content. The path is the experience. Getting that right requires a different kind of thinking than writing features.

“

You should have just as much fun traversing the site as watching it.

”

AA mobile recording studio built for musicians who work in stolen moments — on the bus, between sets, in the three minutes before an idea dissolves. The constraint was total: the interface could not require any cognitive overhead at the moment of capture. Musicians already had their hands full with the music itself. This meant the architecture had to do all the work invisibly — organizing, filing, sequencing — while the front surface stayed completely transparent. The interface had to feel like the instrument, not the tool. When that works, the user never thinks about the software at all. They only think about the thing they are making.

TThe move from Angular 1 to Angular 2 was not a version bump — it was a different way of thinking about an application entirely. TypeScript forced the kind of structural discipline that had always felt right but was never enforced. NgRx and RxJS made the data flow explicit: every state change declared, observable, traceable through the system in a single direction. Working with those tools at Kaiser crystallized something that had been forming since Nocsonic — a strict separation between the view layer, the business layer, and the data layer, each communicating only through defined interfaces. The presentation knew nothing about where the data came from. The data layer knew nothing about what displayed it. Nothing leaked between stations.

OObo was the proof. The same separation of concerns I had written about at Kaiser — view, business, data — now applied to React, with hooks as the connective tissue and Redux observables managing state across the layers. Same architecture, new framework, same result: a codebase that any engineer on the team could enter at any layer without unraveling the others. The assembly line held. When an architecture is genuinely right, it stops being a framework the team works inside and starts being a language they share.

“

This setup is even something I can build with.

”

VVue, Angular, and vanilla JavaScript — three codebases, different eras, different teams, one hospitality platform that could not stop flying while the work was being done. The Webpack Module Federation architecture unified them without a rewrite and without pausing the product. The metaphor that stuck was exactly right: you do not land the plane to replace the engine. You build the new system around the running one, verify that each piece holds before you remove the old piece, and hand the plane back to the pilots at the end of every sprint. No team lost a sprint. No feature was delayed. The migration shipped. The plane stayed in the air.

TThe studio is the practice made public. A founder lands here and within ten seconds knows exactly what this is and whether it is for them. The work is Product Inception — the gap between knowing and showing, between what a founder has fully formed in their head and what everyone else in the room can see. We build the interaction that proves the idea works. Not the whole product. The one moment that demonstrates the core hypothesis. Prove it before you build it.