Your AI Prototype Looks Done, But Here’s What It’s Hiding

Jan de Vries · 2026-11-10

AI coding tools have slashed the time and cost of producing software. But they haven't touched the cost of building the wrong thing. That cost now makes up a larger share of the risk in a new product, and most of it is decided before the first sprint. A short product design phase lets founders settle scope, feasibility, and budget while changes are still cheap. ### The question founders ask now Many of the founders who come to us now bring a clickable prototype of what they want to build, usually put together with AI tools in place of a written brief. It's a better starting point than most requirement documents, and we treat it as one: it shows how the founder sees the product and gives the first conversation something concrete to work from. Then comes the question: If this took a couple of weekends, why pay for weeks of design before development? Part of the answer is that a prototype like this is mostly frontend. A product people can rely on also needs a backend, infrastructure, security, a design system, and a frontend built to scale, and putting those together takes more than a few prompts. The bigger part of the answer is that the prototype answers a different question from the one that decides whether the product succeeds. It shows that something can be built. It rarely shows what to build first, what the full version will cost, or which decisions will be expensive to change once real users and real data depend on them. ### What AI made cheaper and what it didn't Our teams have worked with AI coding tools since the first ones appeared, testing each new generation on internal work and client projects, keeping what held up in production and dropping what didn't. Most of what we know about AI in a build comes from that habit of testing before trusting, and it has shown us clearly which parts of the work got cheaper. The biggest gains are in work that used to be slow but predictable. A designer and a technical lead can now turn screens from the design file into a working frontend prototype and iterate on it directly, where that used to mean waiting for a developer to build each screen by hand. When an integration looks uncertain, the technical lead can build a working proof of concept with agentic coding tools in hours rather than days, so the feasibility answer arrives while the product is still being designed. Hours of recorded discovery sessions get synthesised into themes and contradictions in minutes. Documentation, including the usage guidelines that make a design system usable, gets written alongside the work instead of being skipped under time pressure, and AI-written unit and end-to-end tests cover more cases in less time. That applies to the full products we ship, as well as to prototypes. For a maritime technology venture, that meant the prototype could answer real questions: we built interactive prototypes on the client's regulations and procedures, so crew and compliance teams tested how the product would respond before we built the MVP. What hasn't moved is the cost of the decisions around the code. A scope that tries to fit everything into the first release is as expensive with AI as without it, and more tempting, because each extra feature now looks cheap. An integration with a payment provider, a legacy system, or a third-party API still behaves differently in production than in its documentation. An estimate without stated assumptions is still a guess. And some decisions, such as the data model or how permissions work, get harder to reverse with every week of development built on top of them. The cost of writing code fell. The cost of writing the wrong code didn't, and because teams now produce more of it faster, a wrong decision travels further before anyone notices. ### Why a fast prototype can raise the risk This is where I'd push back on a common assumption. A prototype built in days looks finished, and that is the problem. It creates momentum toward development before the underlying questions are answered. > "A prototype shows that something can be built. It rarely shows what to build first, what the full version will cost, or which decisions will be expensive to change." That momentum can be costly. When you skip the design phase, you risk committing to a scope that's too broad, an architecture that won't scale, or a user experience that misses the mark. And because AI makes it easy to add features, you might end up building more than you need—before you've validated what users actually want. A short product design phase—even just a few weeks—can save months of rework. It forces you to ask the hard questions early: What problem are we solving? Who is it for? What's the minimum viable product? What are the technical risks? By answering these before you write a line of production code, you set yourself up for success. So, if you're holding a shiny AI-generated prototype, don't mistake it for a finished product. Use it as a conversation starter, not a blueprint. Invest in the design phase to turn that prototype into a product people will actually use—and pay for.