JD’s posthaven

The best sign that a prototype worked is the first thing people say when they see it: "Wait, you already built the app?"

No. I built a prototype. It exists so we can talk.

There's a reflex I keep seeing with AI coding: people believe they have to pour everything into one enormous, detailed spec so the agent can nail it in a single shot. Plan mode, spec-driven development, the perfect document up front. And in that rush, they forget something obvious. Today, instead of planning* the thing, you can just build it. You can even code a small prototype yourself.

We learned this lesson once already. It's the whole reason software teams tried to move away from waterfall and toward more iterative, incremental ways of working: you can't anticipate everything, you're not a fortune-teller, and you can't write the spec for an application from scratch without studying how users actually work and talking with them at length. Even the users can't describe everything they need in a single pass.

I am using the words iterative and incremental deliberately. Some process terms now carry too much baggage for many people, often for good reasons. The philosophy still matters. Build something, learn from it, improve it, and keep moving.

Of course, for a small task, one-shotting works fine. But you can't design a complete application in one go, not with humans and not with agents, because we struggle to describe what we want, and the agent struggles to understand what we're asking.

So prototype instead. And not only the front-end or the UI, but the features, the flows, the back-end, the data. Because to give real feedback, you have to see the thing. To follow a process, understand it, and improve it, you need to watch it run on real data. And for an interface, you need to see it and click through it, to find out whether the agent actually understood what you meant. A document can't give you that. A running prototype can.

My loop is simple and fast:

- Build a functional prototype, quickly. Minutes to a few hours. A day for something real. A few days, never more than a week, for something genuinely complex.

- Make it realistic enough to trigger real feedback, but deliberately incomplete. You advance one feature, one screen, one workflow at a time.

- Show it to users early, and let them react. The feedback is far more useful than any spec review, because people respond to something they can feel. I also record the meeting with a tool like Granola or CircleBack, so I can stay fully focused on the exchange instead of slowing it down by taking notes that are never quite complete.

- When the workflow is complex, compare several approaches. Build three or four versions of the interface, then feed the prototype with a realistic synthetic dataset. That is what lets the user step into the situation, compare options, and project forward.

Two reactions come back almost every time. At the start: "You built the app?"* No, it's a prototype, it's here so we can talk. And at the end of the meeting: "Great, so I can start using it?" Not yet. This let us align. Now I'll fold in everything you just told me. But very soon, in two, five, or ten days depending on the complexity, you'll have the real application.

That leaves the most important point, the one most people get wrong: what happens to the prototype next?

**The prototype is throwaway.** Its job is to answer questions and reduce risk, but also to sharpen the need, test the PM's hypotheses, and create a concrete support for ideation. It helps validate whether the PM's understanding and intuition converge with the user's reality. Faced with something concrete, the user's critical thinking wakes up. They see what works, what feels wrong, and what they actually need.

It is not, however, your production codebase. Shipping the prototype as production is how you inherit accidental technical choices that every future agent then faithfully reproduces. So once it has done its job, I don't "productionize" it. I use it as the reference to build a first alpha that is clean, robust, fully tested, and reviewed end to end: code I've actually read, that sets the patterns, the tone, the spirit of the project. That alpha is the healthy foundation everything else is built on. The prototype is there to understand, compare, and decide. The alpha is built to last and to run in production.

The right sequence is not spec, then production. It is prototype, learning, clean alpha. The prototype lets you understand the need, test the assumptions, compare interface options, and watch real behaviour run on realistic data. The alpha turns those answers into a solid technical base.

So before polishing another spec, build something your users can click through, criticize, and correct. Then build the real application properly, so it lasts.