🎧 A Dutch version of this conversation is available as a podcast episode.
In this episode of The Open Podcast, Sander Mangel sits down with Jeroen van Mierle and Chris Constandse from PragmAI to talk about rapid prototyping in the AI era. They dive into why prototyping no longer requires enterprise budgets, how AI tools have compressed the timeline from a raw idea to a working concept, and why the most critical question to ask before building anything is simple: "What do we actually want to learn?"
Most companies still associate prototyping with massive, high-risk projects. The assumption is always the same: you need a massive budget, a dedicated team, and weeks of runway before anything tangible becomes visible.
Jeroen van Mierle and Chris Constandse from PragmAI challenge that old playbook. They argue that prototyping has become highly accessible for projects of any size. The real hurdle now isn't the technology, it is the mindset.
Prototyping doesn't have to be the whole project
Prototyping a single feature is entirely different from prototyping an entire platform. Recognizing this distinction removes the biggest roadblock teams face that you need to have every single detail figured out before showing your work.
"The thing about making prototypes for SME clients," Chris notes, "is that you can move very quickly to a first visualization and validate it relatively quickly without needing those large investments."
What AI really changed is the cost of context. Previously, aligning stakeholders on what was being built required endless documentation, alignment meetings, and external workshops. Now, that context can be built straight into the prototype itself, fast enough to happen live during a single session.
According to Jeroen, when prototypes fail inside organizations, it is rarely a technical issue. It happens because stakeholders didn't grasp the broader picture or the underlying "why." AI makes it cheap enough to close that understanding gap upfront.
The gap between a business idea and actual execution
In digital commerce projects, stakeholders usually know what features they want, whether that is a configurator, a product finder, or an inventory dashboard. The vision for the front-end experience is concrete, but the underlying business logic is often completely missing.
Sander sums it up perfectly: "The technology isn't going to decide how a price calculation is done." That decision belongs to the business, and until it is made, development is stuck.
A prototype forces those decisions to the surface before they become expensive mistakes. Chris shared an example of a B2B stock dashboard built to balance inventory across multiple stores. The prototype quickly exposed a messy ERP system, data that required urgent standardization, and dependencies that nobody had mapped out yet.
Jeroen describes this fast-paced dynamic as Agile reinvented. Everything lives on a live URL, modifications happen mid-session, and the actual work unfolds right in front of the client.
In digital commerce, your front-end experience is only as good as the data feeding it. Prototyping forces you to confront your data realities on day one, not during the final launch week.
What the tooling looks like today
The pace of change in this space is staggering. Jeroen pointed out that as recently as early 2024, most teams were still relying on traditional, slower workflows. The shift since then has been massive.
PragmAI's current stack leverages Claude, Replit, Figma AI, Claude Code, and GitHub repositories, alongside Atlassian's Rovo to digest client documentation. This toolset is constantly evolving. Chris mentioned that a new tool with practical, real-world client value seems to emerge every few days.
However, there is a massive gap between casual AI usage and professional prototyping. Generating a polished image out of ChatGPT is a world away from engineering a functional prototype that respects a client's complex brand identity. The tools are open to anyone, but using them effectively still requires a deep understanding of the problem you are solving and who you are solving it for.
"You have a meeting in the morning and a working new prototype at the end of the day," Jeroen says. "That's already possible."
How prototyping workshops kick off
The most critical takeaway from the conversation centered on how prototyping workshops kick off. Most agencies start by asking what the organization wants to build. Jeroen argues they should ask what the organization wants to learn.
Ask what they want to build, and you get a generic wishlist. In e-commerce, clients usually point to giants like Coolblue or Amazon. Those are recognizable reference points, but they make terrible project briefs.
Ask what they want to learn, and the conversation pivots to what makes their specific business unique. It forces them to pinpoint the exact problem only they are positioned to solve.
Sander shared a clear example: a transport company operating exclusively between the Netherlands and England. They know every nuance of that specific route, including the paperwork, the customs bottlenecks, and the edge cases. An app engineered around that precise operational knowledge is incredibly valuable. A generic delivery tracker is useless.
Chris frames this as finding the core impact. The objective of a prototyping workshop is to strip away the noise and find what your organization does that no one else can match. That is your actual starting point. From there, the scoping strategy is straightforward: start small. Not as a compromise, but as a deliberate strategy to tackle a single, tangible problem the entire team feels.
What goes in determines what comes out
Before a single line of code is generated, there is a preparation phase that Chris insists on: "The AI you work with is only as good as the data you feed it."
That means gathering raw documentation beforehand such as feature requirements, old project notes, meeting transcripts, and Jira tickets. Strip out the sensitive data, upload the rest, and use it as your baseline context.
Using tools like Claude Projects, that context remains persistent and searchable throughout the entire engagement. The focus then becomes practical: given what we know, how do we move toward a working prototype, and where are the gaps?
You also need the right mix of people in the room. This means business stakeholders who live the problem, a tech lead or solutions architect to validate what is feasible with the underlying systems, and someone championing the UX perspective. They aren't there to debate final implementation, but to pressure-test whether the concept works in reality.
No cold handovers
By the time a prototype is finished, the handover should already be complete. Jeroen’s rule of thumb is simple: if you are presenting a finished concept to a team that wasn't involved in building it, your process fails.
The transparency that makes live prototyping work, like constant milestone check-ins, shared URLs, and real-time iterations, ensures that everyone is aligned on the next steps long before the final presentation.
"Let that ribbon stay off," as Jeroen puts it.
The team should already know exactly what needs to happen next.
Chris highlights the bigger picture, "a prototype is never the final product. It is functional proof that a concept is worth building properly. Its true value lies in the data-backed clarity it unlocks: hard evidence of what works, faster alignment, and zero wasted development hours."
Cut the noise, start building
Prototyping is no longer an enterprise luxury. The tools have evolved to the point where you can use this methodology for a single, isolated feature just as effectively as a massive platform overhaul.
However, the fundamentals of a successful project remain identical. Start with the right question. Let data insights dictate what makes your business unique, rather than guessing. Keep the initial scope small enough to test immediately. Stay highly collaborative.
And remember: the prototype itself was never the end goal, it is just the vehicle to get you there faster.
