Rapid Prototyping
From Napkin to Working Prototype: How Rapid AI Prototyping De-Risks Your Idea
By Sean Doherty ยท July 3, 2026
There is a document on a shared drive somewhere right now called something like "AI Intake Assistant, Discovery Phase v4." It has an executive summary. It has a slide with three coloured columns. It has been open in a tab for six weeks. Nobody has decided anything, because a document cannot decide anything. It can only be commented on.
I want to talk about the fastest way out of that tab, because I have watched a lot of good ideas die in there, and the cause of death is almost always the same: everyone kept debating the idea instead of building a small real version of it.
Let me give you a person to follow through this. Call her the operations lead at a mid-sized firm. She has a hunch. Her team spends the first twenty minutes of every new client interaction typing the same intake details into the same form, asking the same questions in the same order, and she thinks an AI assistant could do most of that first pass. Draft the summary. Flag the missing fields. Hand the human a tidy starting point instead of a blank one. She is probably right. She is also, at the moment, stuck, because the only artifact she has is a paragraph in a planning doc, and a paragraph does not survive contact with a sceptical finance director.
The debate is the disease
Here is what happens next in the document version of her life. Someone asks whether the AI will hallucinate client details. Someone else asks about data privacy. A third person, who has read one alarming article, asks whether it will "replace the team." Each question is reasonable. None of them is answerable on paper, so the meeting ends with an action item to write more paper. Discovery Phase v5.
The reason this loops forever is that a document is an argument, and arguments are won by whoever is most senior or most tired. A working thing is not an argument. It is evidence. You can point at it and say: watch what it actually does with a real intake call.
So instead of answering the privacy question in prose, you build a small version that only touches synthetic data, and now the privacy question has a concrete shape instead of a theoretical one. The debate stops being about the idea and starts being about the thing, which is the only debate worth having.
What I learned from making a very small change at Toyota
I started my working life as Toyota's first Kaizen engineer, back in 1987. I built their first intranet, which sounds grand and was, in practice, a series of very small changes that I had to prove one at a time. That is the whole of Kaizen, and it has quietly run my career ever since: make a small change, prove it works, then scale it. Not: design the perfect system, present it, and pray.
The instinct that stuck with me is that you earn the right to scale. You do not assume it. A prototype is Kaizen applied to an idea. You are not trying to build the AI intake assistant. You are trying to build the smallest honest version that answers one question, and then you look at what it told you before you spend another penny.
For our operations lead, the smallest honest version is not a platform. It is a scrappy tool that takes the transcript of one real intake call and produces one draft summary. That is it. Two days of work, maybe three. And that scrappy thing will teach her more than v4 through v9 combined.
What a prototype proves that a document cannot
A document can describe the happy path. It is constitutionally incapable of showing you the ugly one, and the ugly one is where all the real information lives.
When our operations lead runs ten actual intake transcripts through her scrappy tool, she does not learn whether the idea is "good." She learns something far more useful. She learns that on eight of them it produces a summary that saves the human real time, and on two it confidently invents a phone number, and she learns exactly which two and why. That "why" is the entire ballgame. It is the difference between a fear and a finding.
A working prototype gives her things a deck never will:
- The real failure modes, in her actual data, not the ones people imagined in a meeting. She now knows the assistant needs a hard rule: never guess a contact detail, always flag it as missing. That rule came from evidence, not anxiety.
Notice what else happened. The finance director stopped asking whether it would replace the team the moment he saw it hand a half-finished draft to a human who then fixed it in ninety seconds. The prototype answered the political question by simply being honest about what it does and does not do. You cannot argue a person out of a fear that cheaply. You can show them.
I spent years leading digital delivery on global accounts, a content system rolled out across 180 countries for Nissan and Infiniti, work for Nintendo and PlayStation and Singapore Airlines. Later I ran operations at Betfred while it grew 100 percent year over year for five straight years, and more recently I delivered fifteen-plus enterprise AI proofs of concept across healthcare, finance and government at Coforge. The pattern held every single time. The proof of concept that took a fortnight settled debates that the strategy document had kept alive for a quarter. Shipping something small beats presenting something grand, and it is not close.
When you should not prototype
Now the part nobody in my line of work likes to say out loud, because it sounds like turning down business. Sometimes prototyping is exactly the wrong move.
Do not build a prototype when the question is not actually technical. If our operations lead's real problem is that her team distrusts any automation because the last "efficiency project" was a redundancy exercise in a nice hat, then a working demo will not fix that. You have a trust problem, and a clever tool dropped into a distrustful team just becomes the thing everyone quietly refuses to use. Solve the human problem first. No kernel of code substitutes for that conversation.
Do not prototype when the honest experiment cannot be small. If the only meaningful test requires live production data on real clients, regulated and identifiable, then a quick weekend build is not de-risking anything. It is the risk. In regulated settings the governance has to come before the prototype, not after. I feel strongly enough about this that I am building a patent-pending governance kernel, Cura Mirai, specifically for the industries where "let's just try it and see" is a genuinely bad idea. Know which industry you are in.
And do not prototype when you already know the answer and are only building a demo to win a fight. That is not evidence. That is theatre with better production values, and everyone in the room can smell it.
Back to the operations lead
Her story ends undramatically, which is how the good ones end. The three-day tool showed that the assistant saved real time on the routine cases and needed a firm human check on the exceptions. She did not scale it to the whole company. She Kaizened it. One team, one month, watch the numbers, then decide. The intake time came down. The team kept their jobs and lost the boring part of them, which is the part they were happy to lose.
The planning document, meanwhile, is still on the shared drive. It made it to v4. Somebody should probably archive it, though I suspect it will outlive us all, quietly gathering comments, waiting for a decision that a small ugly prototype already made three weeks ago.