What an AI prototype won’t tell you before you build (Sponsored)

AI coding tools have cut the time and cost of producing software, but not 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 decisions have been made. Founders show it to investors, the team starts extending it and the open questions about scope and feasibility get carried into the build, where they cost the most to answer.

So AI prototyping makes a design phase more necessary, because the gap between how finished something looks and how well it’s understood has never been wider. This phase closes that gap: it settles what needs to be built and lays the foundation for the choices that follow, from user flows to technical architecture.

What three to five weeks should settle

A product design phase doesn’t need to be long to be useful. On our projects, it runs three to five weeks and should leave a founder with four things.

• A prioritised scope. What goes into the first release, what moves to later ones and why. The most valuable output is often the list of what not to build yet.
• Tested technical unknowns. Integrations and uncertain parts are checked through short technical spikes while the product is still being designed, instead of being discovered in the third sprint.
• A clickable prototype of the main user journeys, built on top of those decisions rather than ahead of them, so stakeholders and ideally users can react to something real.
• An estimate as a range, with its assumptions written down. An optimistic, most likely, and pessimistic case is more honest than a single number, and it gives a founder something to plan a round or a runway around.

The change is in the ratio: when building gets faster, the share of total risk that sits in these decisions grows.

What the phase changed on our projects

Three recent projects show the pattern.

A digital-asset operations company came to us running its operations on a spreadsheet ledger, with every recurring payment executed by hand outside it. In one design sprint, we mapped how the work actually happened, designed the flow it should follow and turned that into a prototype of a full operations platform, with automated recurring payments, security checks built into the payment flow and a shared view of the business’s health. The company left the sprint with a defined product, validated through the prototype and ready to build, with no second discovery phase needed.

The other two started as rewrites of existing products, where the cost of building the wrong thing a second time is easy to see.

A telehealth company came to us because maintaining its app had become expensive and new features were hard to add. During the product design phase, we found features that had been built and then left unused for a couple of years. Removing them simplified the product as a whole and lowered the cost of the rewrite before any new code was written.

Another client wanted to move an existing app to newer technology that would be easier to maintain. A straight rewrite would have carried the old user flows into the new stack. The design phase showed that the flows needed rethinking to make the app easier to use, and that the new architecture should make room for features the old app had made hard to build. The client changed the brief before development started, which is the cheapest moment to change it.

In both rewrites the expensive mistake would have been rebuilding the old product well in new technology.

Where the value gets lost before the phase starts

Most design phases that disappoint don’t fail in week three. They are set up to fail before kickoff, and two patterns come up again and again.

The first is trimming the technical lead’s time to bring the price down. Nothing is being built yet, so the technical role looks like the obvious line to cut, and the result is a prototype that looks right and an estimate nobody can defend. If the budget is tight, it’s better to narrow what the phase covers than to thin out the person who checks feasibility.

The second is a missing decision-maker. If the person who controls scope and budget isn’t in the sessions, the phase produces a plan that gets reopened the moment they see it.

How to tell a useful design phase from a formality

The most useful question a founder can ask any vendor is a short one: what’s the last thing your design phase stopped a client from building? A team that runs real design phases will have an answer, and the answer says more than a process slide. A few follow-ups help with the rest. Is a technical lead involved from the first week, or brought in only for the estimate? Does the proposal name its deliverables, so that “complete” means something specific? Will the estimate come as a range with its assumptions written down?

Where the money is actually lost

AI has changed how quickly software gets built, and that’s a real gain for founders working against a runway. But the money in a new product goes on building the wrong thing well, and that risk is settled, or left open, in the few weeks before development starts.

At Thinslices, every new build starts with a product design phase.

About Thinslices

Thinslices is a product development company that designs and builds digital products and AI for funded startups, scale-ups and corporate innovation teams in the US, the UK and DACH. Since 2010 it has delivered more than 220 projects, with a client NPS of 91 for the first half of 2026. Its work starts with a product design phase of three to five weeks, which leaves founders with a prioritised scope, a clickable prototype and an estimate range before development begins.

The post What an AI prototype won’t tell you before you build (Sponsored) appeared first on EU-Startups.