- Services
- Agency
- About us
Platform
Mustang
HR
Live
The Workforce
Procurement
Live
The Controller
Coming Soon
In Build
Growth & Customer Experience
Marketing
How AI Prototyping Is Changing Product Development: Our Scars and Lessons
Share:
How AI Prototyping Is Changing Product Development: Our Scars and Lessons
Publish date
Share:
Publish date
Share:
What changed when we moved working prototypes ahead of parts of the traditional PRD, where the speed is real, and where the bill and the bad assumptions start to show.
Context
We used to spend a lot more time describing products we had not touched yet.
Product captured requirements. UX turned them into flows and screens. Stakeholders reviewed them. Engineering interpreted the whole thing again. Much later, everyone finally interacted with working behavior.
That sequence made sense when building was the expensive part. AI prototyping changed the economics enough for us to change the order.
For some product work at Optimum Partners, we now move into a functional prototype before every part of the traditional PRD is finished. We still define the problem, the rules, the data, the users, and the constraints. Once there is enough clarity to make the central behavior tangible, we would rather put something in front of people than spend another week predicting how it will feel.
That has made us faster. It has also given us a few scars.
The First Thing We Changed Was the Order
This is the biggest change in our product process.
The traditional sequence asks documents and mockups to carry the product for a long time before the product itself can participate in the conversation. For suitable work, we now bring working behavior forward.
The prototype becomes part of discovery.
A requirement can say that an administrator approves a request before publication and still leave half the product undefined. Once the flow works, the review gets much sharper.
Those questions are easier to settle when the team can interact with the behavior instead of discussing a sentence about it.
In our process, that means the specification can become a record of decisions the prototype helped expose, rather than a prediction of every decision we hope will survive later.
Scar 1: A Functional Prototype Can Look Too Finished
AI prototypes can look very convincing, very quickly.
We have built flows that moved cleanly through the happy path and became much less impressive as soon as we pushed on the product underneath them. Permissions were thin. Error states had not been thought through. An integration behaved differently once real constraints appeared. A polished screen made the whole thing feel more settled than it was.
That changed the language we use internally. When somebody says “it works,” we want to know which kind of works.
AI makes the first two levels much cheaper to reach. The other two still need product judgment, explicit rules, engineering, validation, and production reality.
What We Now Let the Prototype Decide
We use prototypes aggressively for the questions they answer well, and keep the things they cannot safely prove explicit.
This is why “the prototype is the new PRD” is a little too neat for us. The prototype can carry behavior. The written specification still carries intent, rules, constraints, and obligations the prototype cannot prove.
Scar 2: AI Will Fill the Gaps You Leave Open
The AI will make product decisions for you if you leave enough empty space. Some are useful. Some are simply plausible.
We have seen generated work simplify a flow that needed nuance, change hierarchy because the new version looked cleaner, and carry an assumption from one screen into another as if it were a rule.
The answer for us was not endless prompting. We started giving the build stronger foundations before asking for more output.
This is where UX work becomes more important even when the screen itself becomes easier to generate. The valuable work shifts toward intent: what is deliberate, what must stay consistent, and where the AI is filling a gap with something that only looks reasonable.
We Have Paid the Tuition on This
This is not a lab exercise for us.
We build products for clients, and we have built several of our own AI products. That is a very efficient way to acquire opinions about product development.
We have enjoyed the speed, broken things, rebuilt them, spent more than expected, and changed our own process as a result. The useful part is knowing where working software should enter earlier, where a prototype is giving real evidence, and where another iteration is only postponing a decision.
If you are rebuilding a product process around AI, that is exactly the kind of work we can help with.
The interesting question is not which tool to buy. It is what should move earlier, what still needs to stay explicit, and how much product you need to build before you have learned enough.
Scar 3: Fast Building Can Get Expensive Fast
We have used Replit, Figma Make, Lovable heavily for product work. When the build is going well, the speed can feel almost ridiculous. The bill can feel ridiculous too.
This is easy to underestimate because AI prototyping does not behave like a fixed design subscription.
Cost grows with the amount of work the agent has to do, the size of the project, the context it has to carry, and how many times the team changes direction.
Replit made that visible when it moved Agent from flat checkpoint pricing to effort based pricing. In its own recap, Replit reported simple checkpoints as low as $0.06, more involved requests above $1 and sometimes multiple dollars. More important than the exact rate, it reported that project size, chat length, and AI context all affect the incremental cost of the next request.
That matches our scar. A product decision changes late. The agent reloads context, touches several parts of the app, tests again, and repairs what the change disturbed. Repeat that a few times and the cheap prototype is no longer cheap.
We now watch AI build spend while the product is still being shaped. If cost is climbing because the team keeps changing direction, the problem may be the decision loop, not the tool.
We will cover the economics of AI product development separately because it deserves its own piece. The short version is simple: AI moves cost forward too.
What We Now Do Before a Serious AI Prototype
Our process is still evolving, but one practice has survived enough real work that we recommend it: split the questions before you ask the AI to build.
Then build only enough to create evidence.
AI makes overbuilding very easy because momentum feels productive. We try to stop when the prototype has answered the question that justified building it. If the question was which approval flow works, we do not need a nearly complete admin console before reviewing it.
That discipline protects time, spend, and the team from mistaking generated volume for product progress.
A Better Question Than “Do We Still Need a PRD?”
We do not think the useful debate is whether PRDs survive.
The practical question is which parts of product definition still belong in prose and which parts are now cheaper to discover through working behavior.
We use documents for intent, constraints, decisions, and things the prototype cannot safely prove. We use prototypes to expose interaction, missing states, unclear flows, and assumptions that become obvious only when somebody tries the thing.
The boundary will keep moving as the tools improve.
Make the product real early enough that the wrong decisions are still cheap. That is the part of AI prototyping worth keeping.
Frequently Asked Questions
AI prototyping uses AI tools to turn product ideas into functional interfaces and flows much earlier in the development process. The goal is not only to make screens faster. It is to make product behavior tangible enough to test, question, and refine.
Sometimes it can replace parts of the traditional requirements process, but not the whole thing. A prototype is good at exposing behavior, flow, missing states, and interaction problems. Business rules, permissions, data constraints, acceptance criteria, and production requirements still need to be explicit.
Use it when a question is easier to answer through interaction than through prose. Good candidates include workflow design, approvals, multi step flows, role based behavior, and early UX decisions. If the main uncertainty is security, architecture, compliance, or production performance, a prototype alone will not answer it.
It moves working behavior earlier. Instead of waiting until after requirements and design are finished, teams can build enough of the product to expose missing decisions, gather feedback, and sharpen the specification before full production engineering begins.
It can be faster and cheaper for the first working version, but the cost can rise quickly through repeated regeneration, large context, testing, repairs, external services, and changing product decisions. The biggest cost often appears when the team keeps building before it has decided what should actually survive.
Current tools include Replit Agent, Figma Make, Lovable, and Bolt. They overlap, but their strengths differ. Replit is strong for functional app building, Figma Make sits closer to design and interaction, while Lovable and Bolt are commonly used to generate working web applications quickly.
Share:
Related Insights
Working on something similar?
We’ve helped teams ship smarter in AI, DevOps, product, and more. Let’s talk.