🎧 Listen to the full episode here.
Discussing software ideas is the easy part. You explain the problem, describe what the product should do, and agree on the requirements. But until there is something you can actually see and interact with, it is difficult to know whether an idea that sounds good on paper will actually work in practice.
AI is starting to change this process. Instead of waiting until the design and development work has been done, teams can start experimenting with something they can actually see, click, and react to.
In a recent episode of The Open Podcast, Sander Mangel speaks with Radu Barbu, Senior Software Engineer and Tech Lead, about how this is changing their approach to prototyping, from the first conversation with a client to gathering feedback on a working prototype.
‍
The change for the prototyping process
Radu defines traditional prototyping as one involving “a lot of documents, a lot of text and a lot of back and forth.” As Radu explains, “there was a lot of time spent before the client could actually have an image of what the deliverable would look like,” let alone something they could interact with.
The longer it took to get something tangible in front of a client, the longer everyone spent discussing something hypothetical. Radu recalls that the process could involve weeks of planning, prototyping, and defining requirements before development properly began.
Then the real problems only became visible once development was already underway. Clients would start seeing the product come to life and realize that a particular part did not work or that they wanted something different. At that point, changing the requirements was possible, but costly and unpredictable.
AI makes it possible to move that feedback loop much closer to the beginning of the process. “Code is cheap now, so we can move prototyping much earlier in the process, even before a contract is signed,” Sander says.
Radu's experience reflects that change. Something that might previously have taken around a week can now result in “something more meaningful in an afternoon” when the tools are used properly.
This puts an idea in front of a client faster, gets an immediate reaction, and decides whether the product is actually moving in the right direction before committing to development. Prototyping has become a way of having a better conversation about the product itself.
‍
What prototyping with AI actually looks like
AI is very good at filling in the gaps when instructions are vague. This can be both useful and problematic. If you give an AI tool a request to create a customer management grid, it may decide that the product needs search, inline editing, and many other features. The result looks polished, but AI has also started making product decisions nobody asked for.
For Radu, an effective prototype is more focused. “You just need to emphasize the fundamental business flows,” he explains.
The purpose is to demonstrate how a particular process works, rather than to create a miniature version of the finished product with every possible feature included.
Sander describes it as a way of proving a particular process or job rather than trying to “show off all the features, all the bells and whistles that we can build later.”
This becomes particularly important when working with AI, because adding functionality is so easy. A human developer naturally has to think about the time involved in building something. An AI tool does not have the same constraint when it generates a prototype, so it adds things that seem useful without considering whether it is actually necessary.
Radu's approach is to be explicit about what AI should and should not do by prompting “Hey, just stick to the basics. Do not assume, do not add unnecessary things. We will add them later.” The goal is to produce just enough to answer the question you actually have.
‍
The value of seeing something real
Clients often understand a product differently once they can see and interact with it. A written requirement can seem perfectly clear until it becomes a screen. Clients looking at it notice that the process does not make sense or that some information is missing.
Radu calls this as the “aha moment” that can happen when a client sees the prototype. “Nobody knows exactly what they want,” he says, qualifying the statement before explaining that people can think they know what they want until they see something coming to life.
The prototype gives them something to compare their expectations against. This can be particularly valuable for agencies. Instead of asking a client to approve a specification based on descriptions of future functionality, the team can show them a version of the experience and ask whether it reflects the business problem they are trying to solve.
It also gives the development team more clarity. Once the prototype has been discussed and adjusted, there is a shared reference point for what is actually being built.
Radu describes this as clarifying things for both sides by knowing that “This is where we're heading. This is what you're going to get. This is what we need to deliver.”
‍
AI still needs direction
The speed of the process should not be confused with a lack of expertise. In fact, Radu's experience suggests almost the opposite. His first attempts at AI prototyping were not particularly great. The tool made assumptions, changes were sometimes difficult to communicate and longer conversations could cause the AI to lose track of what had already been established. As he puts it, “you kind of start losing control” when the context becomes too complicated or instructions are not precise enough.
After working on several prototypes, however, the process became much more predictable. Radu learned what the tool was likely to produce and how to structure his instructions accordingly. That learning curve is an important part of working with AI. AI is not just something you switch on and know how to use effectively. Understanding how it behaves becomes part of the skill.
His workflow starts before the AI tool itself. He goes back to a pen and paper and works through the customer conversation, the available documentation, and his own understanding of the problem. Experience plays an important role because it needs to have an internal logic and represent something that could actually work.
Only then does he move into the AI workflow, starting with the business context and the desired flow before breaking the implementation into smaller phases.
“It's a good practice that you feed AI tools tasks in small, precise, well-defined chunks,” he explains.
Each step can then be checked before moving on to the next one. If something is wrong, it is much easier to correct one small part than to fix an entire prototype generated from a single instruction.
‍
How this looks like in practice at Open Commerce
The approach was recently put into practice while Open Commerce was talking to an agricultural equipment manufacturer. Radu did not have extensive knowledge of agriculture or a detailed understanding of the client. What he did have was an understanding of the business requirements and the fact that the client was looking for something standard rather than a completely custom solution. In this case, the requirement was essentially a dealer portal, something that was not entirely new from a B2B perspective.
The prototype turned that understanding into something tangible quickly. Radu estimates that the initial discussion, prototype, and adjustments took around 3-4 hours. The brief was created from the team's conversation with the client, the prototype was developed, and then refined through Slack. Rather than scheduling another meeting for every change, the team could look at the prototype, suggest an adjustment, and iterate.
The same approach can also work when the project is based on an existing commerce platform rather than being built from scratch. For one prototype, Radu used Shopware as the reference point for the look and feel while deliberately avoiding the need for a real server, database, or production environment. The AI was able to reproduce the visual language of the platform closely, but it also demonstrated exactly why human direction remains necessary.
Since Radu had asked it to make the prototype feel like Shopware, it initially added the entire standard menu rather than only the sections required for the prototype. This illustrates how AI does what it thinks makes sense, based on the information it has. The human behind it still needs to recognize the difference between what the tool generated and what the project actually requires.
‍
A different way of working with AI
AI prototyping can change when and how teams make decisions. Radu sees potential for this approach within roles such as business analysis, where it can help teams define business tasks and think through their implications. Sander also points out the value for sales. You can present a live, clickable experience that is more useful in a customer conversation than a powerpoint presentation.
However, at the end of the day, people have to direct the process. Radu emphasizes that “you still need to think of AI as a tool.”
Sander's comparison is “you are still the director, the AI is your orchestra. It's like using the self-driving feature of a car, but in the end, you're the driver. You need to kind of steer it in the right direction.”
This is how we should think about AI prototyping today. It is not a shortcut from idea to production. It is a faster route from a business problem to something concrete enough to discuss, test, and change.
Once everyone can see where the product is going, the more important question becomes much easier to answer. Is this actually where we want to go?
