Prototypes, end to end

He named the problem before I did. The important part was behavior, and flat frames can’t carry behavior.

It’s easy to hear that message as a request for better mocks. It wasn’t. He had mocks. What he couldn’t draw was the part of the idea that only exists when someone’s hand is on it: what happens when you push a value too far, what the screen does instead of letting you, and how it tells you why. A frame shows a state. His idea lived between states.

That gap is what every chapter on this page is about. Frames are very good at getting people to agree on what a thing looks like. They’re quiet about what it does, and in insurance software, what it does is usually a rule: a limit, an eligibility check, a coverage that can’t exceed another. When the rule is the product, a picture of the product leaves the product out.

The first sign that the medium was the bottleneck came from an engineer asking a designer to go past it.

Frames like these could show both answers. They couldn’t show what either one felt like to use.

Side by side, the difference is easy to state and hard to feel. The modal is one dialog. The controls are a set of components that all have to know about each other. What a still frame can’t show is the sequence: in the bottom row the agent makes a choice, the screen accepts it, and then the screen takes it back. Every round trip is a small broken promise, and you only notice it with your hand on the mouse.

On January 16 I proposed a pattern with a working prototype attached. On January 21, a hand-written HTML prototype, made before any of the tooling I use now, reached the engineer who would end up championing it:

Nobody had to be argued into anything after that. Everyone could click the same thing.

Look at his first question, though. It wasn’t whether the pattern was right. It was who made it, and the guess was someone other than the designer, because a working thing in a browser read as somebody else’s job. That assumption is what the rest of the year took apart: design hands over pictures, and someone else makes them real.

A prototype doesn’t win an argument by being persuasive. It wins by making the argument unnecessary.

The whole design is in that goal. Visible: the agent sees the rule before they break it, not after. Predictable: what the screen does next is never a surprise. And the last clause carries the most weight: without making them read and memorize the underwriting rules. The people using this are agents in the middle of a quote. They aren’t going to study a rulebook, and they shouldn’t have to. The interface should know the rule so the agent doesn’t have to.

The design file shows how I got there.

Read it left to right and the direction only goes one way: each pass moves more of the rule into the control itself. In the first, every slider runs its full length, and the shared total is a line of text at the bottom. By the second, each rail stops where the total runs out. The third adds the sentence a rule owes you when it says no: “Max limit capped by total insurable value. Lower other limits to increase available coverage.” The fourth carries the same idea up into the options above, where choices the total can’t afford turn gray before anyone picks them.

Here is the sliders prototype, exactly as it was then. Move one and watch the others give way. Its rawness is the date stamp.

Push any slider to its ceiling and it explains itself, in the prototype’s own words: “This selection is being limited in real time based on your selections for the limits to ensure the total doesn’t exceed the predefined $10K maximum.” Past the ceiling, the rail goes gray, and the number at its end moves to wherever the ceiling is now. Nothing on the screen ever lets you ask for something the total can’t give.

It’s one file, written by hand, with the styles and the logic in the same place. An engineer couldn’t adopt a line of it. That wasn’t its job. Its job was to put the behavior in front of the people deciding, so they could argue about the feeling instead of the frames, and it did.

The sliders shipped in June 2026. The engineer implementing them from my demo put the result at “95% there.”

A rule you can feel is a rule nobody has to memorize.

It reads like a small thing. It was the first time I could see that what I made and what engineering made were the same kind of material, and that the distance between them could be closed by editing instead of by starting over.

By September, the prototype was the review surface. Feedback came back as lists written against the prototype link. Product, design and engineering were all pointing at the same clickable thing.

That changes what review is. A comment on a frame is about a picture of a decision. A comment written against a link is about the decision itself, at the fidelity it will ship at, and anyone can reproduce it by clicking where the reviewer clicked. Restrictions shipped in October 2026.

When everyone reviews the same running thing, there’s nothing left to translate.

The underwriting workbench added the handoff bundle and the test that mattered: an engineer I’d barely worked with matched the design in about a day, from the bundle and the design file, with no meeting and no Loom. The rules engine and the delivery system own that story.

The quote builder is the product the old way nearly cost us, told as craft: the agent quote builder.

A prototype someone else will build from has to be held to the standard of the thing it becomes.

The difference between the two rows isn’t effort. Both have four steps, and both end in a build. The difference is what travels. In the first row, the prototype’s knowledge has to be re-described in frames and a spec, then re-read by someone who wasn’t there, and each retelling loses a little. In the second, the thing that gets handed over is the thing that was reviewed. The delivery system’s thesis started here: it looks like a prototype. It’s built like a product.

That question is where the delivery system was born.

Each stage on that list was a chapter above before it was a habit. Walking the flow is the restrictions question, is this even what you meant. Clicking instead of squinting is January. The prototype as the reference is the core account page, and builds that match is the workbench.

Downstream, it shows up in other people’s words.

The latest of these is on the homepage: Tidemark, a working prototype for a lender that doesn’t exist, with its source public on GitHub. The rules engine’s pattern is live too: the rules wrapper, a working demo with its source.

If you want to try this on your own team, here’s where I’d start, one lesson per chapter:

• Build the behavior, not the picture. If the important part is what the screen does, a frame will leave it out.
• Put the prototype where the argument is. A thing everyone can click ends debates that a deck would only prolong.
• Send it back with a question. A prototype of someone else’s requirements is the fastest way to find out you misread them.
• Review against the link. Feedback on the running thing is reproducible; feedback on a frame is a description of a description.
• Write the rules before the screens. Fictional data, no real data, dated figures. That’s what makes a prototype safe to inherit.
• Assume it will exist anyway. Then build it so the next person can use it instead of redoing it.

None of it replaced the conversation. It changed what the conversation is about. In December, the conversation was about what an idea might do. Now it starts with the idea doing it.

We can design the feeling from the very beginning now.