Show Them the Real App

Show Them the Real App

Why this matters

A prototype that doesn't look like the real product teaches engineers the wrong thing. The bar I hold, and the toolchain that now meets it.

A prototype that doesn't look like the real product teaches engineers the wrong thing. The fidelity bar I hold for what goes to eng, and the toolchain that makes it reachable.

As part of a project kick-off, I showed one of my designers an early working prototype this week, and the first thing she said about it was a critique: that’s not what the client portal looks like, and that’s not what the mobile app looks like. She was right, and it was the right instinct. That gap is the whole problem with most prototypes that go to engineering.

Here’s the bar she helped me land on:

Ideal state is that engineers see a prototype once it looks and functions like the real app. Not a sketch of the idea.

The thing, or close enough that the difference doesn’t matter. The moment an engineer sees a low-fidelity stand-in, they start solving for the stand-in. They estimate against it, they spot problems that only exist because it’s fake, and they quietly lose trust in the next thing you show them. A high-fidelity prototype collapses the conversation from “what do you mean” to “how do we build this.”

The reason that bar is reachable now, when it wasn’t two years ago, is the tooling. The loop I’ve been using and coaching: Claude Chat to shape a detailed prompt, Claude Code to build it, Vercel to host it and share a live link. The first time I ran it on a real feature, a client photo-upload flow, it took about half an hour to get something I could put in front of people. The catch is that fidelity out depends entirely on fidelity in. You have to feed the build the real screenshots, the real patterns, the future-state designs.

I’ll be specific about tools, because people keep asking. I’ve given Figma Make fully engineered context and exact pattern guidance and it still misses. I’ve taken the same context to Claude Code, run it hard, and it nailed the output. The only things I fixed were the background color and the logo. That’s the gap right now between a tool that generates an interpretation of your design and one that builds your design.

The teachable part

Set a fidelity bar for what engineering is allowed to see, and hold it. The bar that’s worked for me: it looks and functions like the real product, or it doesn’t go to eng yet. That used to be an expensive standard. The current generation of build tools makes it a half-day standard, as long as you do the unglamorous part and give the tool real context instead of a vibe. Treat the prototype’s context like a design deliverable. The output is only as honest as what you fed it.

Filed under TB Toolbox — Frameworks you can steal.