The first delivery through someone else’s hands
The delivery system’s real test wasn’t my project. It was the morning an engineer I’d barely worked with picked it up cold.
Part One ends with the system carrying a second surface, an underwriting rule editor, and rebuilding it from its own documentation in a single working day. That proves the documentation was complete enough for its author. It doesn’t prove it was complete enough for anyone else, and that’s the question every skeptical reader should ask: fine, but does any of this survive contact with an engineer who wasn’t in the room?
This is what happened when one picked it up cold.
The commission
The project was an internal underwriting workbench: a rules-engine interface, the kind of dense operational surface where design handoffs usually go to die. What made this one different started before any pixels. The engineer who owns the adoption pipeline asked, in writing, for the prototype to be built from reusable components, with every leaf and branch of the design defined for the engineers who would do the building. Engineering didn’t tolerate design-authored code on this project. It specified requirements for it.
The build
Same law as Part One, applied to a second codebase: briefs, isolated builds, one change per commit, an independent gate on everything. The first leaf, a status-badge set, went live in a browsable gallery on Aug 28, 2026. Then came the part most teams skip: the delivery interface itself got co-designed with its consumer. An extraction manifest in the repo listed the exact files, dependencies and pinned versions for every component, and each component’s page carried the working variant next to a copy-ready snippet and the actual token values. Before scaling that pattern past the first component, I asked the owning engineer one question: is this the shape you actually want these in? Now’s the cheap time to say so.
The twist
Mid-project, the stack decision changed: the production build would use a different component library than the prototype assumed. This is where delivery systems usually start lying. The written law says outbound documents get re-verified at send time, so when the handoff came, the materials went out with the degradation flagged by me, unprompted: this part is from when we thought it’d be a different stack; it’s significantly less helpful now. A handoff that advertises its own weak spots is the only kind an engineer learns to trust.
The test
Tuesday morning, an implementation engineer I’d barely worked with, not the pipeline’s owner and not someone who’d watched the system evolve, asked for the design materials for his build ticket. The entire handoff was one message: the repo, the live prototype, the design source of truth. I asked for exactly one thing back: an honest read on what was useful and what wasn’t. Even “I literally don’t know what this pile of garbage is” would count as useful information.
Wednesday, 9:35am, about a day later, he posted a live review build of the dashboard.
“between that and the figma I was able to pretty much exactly match the design”
“2 years ago this would have been a month of work”
The verdict I didn’t expect
The honest-read request came back with more than a pass or fail. He’d evaluated the delivery approaches against each other and ranked them, and the winner wasn’t the full working prototype. It was the context-rich design artifact built alongside AI: enough embedded intent and structure for engineering to pull into their own harnesses and adapt, without adopting someone else’s app wholesale. The full prototype keeps its job. It’s where stakeholders experience the truth of a design before anyone commits. But for the engineering transfer itself, context beat code.
“What you did with [the playground] is honestly probably the best path. You design the app with the AI there, it has enough context for Eng to pull into our own harnesses and tweak. There might be cases where a full working proto app is useful.”
That finding got recorded, not defended. The habit of writing down what you learn applies hardest when the learning trims your favorite artifact.
What this proves that Part One couldn’t
A delivery system that works through its author’s hands proves authorship. One that works through a stranger’s hands, on a changed stack, with its weak spots flagged in advance, proves transfer, and transfer is the whole claim. The system’s output was never really code. It was context complete enough that the next person could build correctly without me in the room.
The handoff-to-review-build window is verified by message timestamps, Oct 27–28, 2026. The first component went live Aug 28, 2026. Quoted lines are reproduced with the engineer’s consent and attributed by role. The machinery behind this, the gates, the manifest and the written law, is Part One; the law itself is the Method page; the component inventory that started the adoption thread is the diff that audited the design system; and the same project through the design lens is designing a rules engine humans can read.
Building something in this lane? Email me.