A demo earns trust when someone can explain the code, its limits, and who accepted the risk of shipping it. Producing working code is only the first decision. Approval is the decision to stand behind what that code will do when a prospect asks harder questions.
The question came after the demo worked
Consider Daniel, a composite founder in Accra, standing at the end of a video call with a prospective customer in Berlin. It was late enough that the light from his laptop had replaced the room. He had just shown an AI workflow that read incoming requests, drafted a response, and placed the result into a queue for review.
The prospect had watched the demo move cleanly from input to output. Then she asked, “Who approved the code behind this?”
Daniel had expected questions about model choice, data handling, and price. He had answers ready for all three. This one landed differently.
A contractor had built the first version quickly. Daniel had tested the happy path himself, forwarded a few screenshots, and focused on the next customer conversation. The workflow had been useful enough to demonstrate. Yet he could not point to a person who had reviewed the failure paths, agreed on what the agent must never do, or signed off on the code that connected it to a live process.
The contract was still possible. So was the other ending: the prospect could decide that a product nobody owned was too risky to bring into her team.
There was a pause on the call. Daniel said the only accurate thing: the code had been produced and tested for the demo, but it had not yet gone through the review the customer was asking about.
That answer may feel uncomfortable. It is better than turning a missing decision into a confident sentence.
Code generation creates a new ownership problem
AI coding tools can make a prototype appear in an afternoon. A founder can describe a feature, paste an error into a chat window, and get a plausible fix before lunch. That speed changes the work. It does not remove the need to decide what is safe to ship.
The bottleneck moves from writing code to judging it.
A prospect who asks who approved the code is rarely asking for a formal ceremony. They are trying to locate responsibility. If an automation sends the wrong message, exposes information, or takes an action outside the intended path, who can explain why it happened and change it?
That question matters most when the demo crosses into a customer’s real workflow. A browser prototype can survive ambiguity. A system that reads customer records, routes requests, or triggers follow-up messages carries decisions that need an owner.
The distinction becomes clearer when you look at the action, not the model. Someone may approve an AI assistant drafting a reply while requiring a person to approve every send. Someone may allow automatic classification while keeping disputed cases out of the automated path. That is the kind of boundary that turns a demo into a product a team can use with confidence.
The same tension sits behind the decision to ship an AI agent in Berlin with human approval. The useful question is not whether the agent appears capable. It is which outcome must remain under human control while the product earns evidence.
Approval needs a named owner and a visible boundary
Daniel did not need to become the best engineer in the room before returning to the prospect. He needed a better record of decisions.
He went back through the workflow with the contractor and wrote down three things: what the agent could do without intervention, what required review, and what happened when the input did not match the expected pattern. They tested the awkward cases that had been absent from the demo: incomplete requests, conflicting details, and a message that looked routine but should have been escalated.
The first pass exposed a problem. The system could place an uncertain result in the same queue as a confident one, with no signal that the draft needed closer review. That was manageable in a demo. In a customer workflow, it could create the appearance of certainty where none existed.
So they changed the handoff. Low-confidence cases were marked for review, the action log captured the input and outcome, and Daniel took responsibility for approving changes before they reached the customer environment. The contractor could still build. Daniel could now explain the operating boundary.
When he followed up, he did not claim that the product had become risk-free. He described what had changed, what remained supervised, and how exceptions would be handled.
That is a more useful credibility surface than a long explanation of the stack. Buyers evaluating a founder or an automation partner want to see that the person building the system can distinguish a working output from an accountable one.
Treat the demo as the first review meeting
The prospect’s question gave Daniel a task he could act on before the next call. It also changed how he prepared demos. Each one now came with a short answer to four practical questions:
- What action does this code take in the real workflow?
- Who can approve changes before that action reaches customers?
- Which cases leave the automated path?
- Where can someone see what the system did?
Those questions are small enough for a founder with limited runway to answer. They also prevent a familiar mistake: adding more capability before anyone has accepted responsibility for the capability already shown.
The sharper version of this problem appears when a single action can create a dispute or liability. One disputed action can turn a ready AI agent into a liability because the code may behave exactly as built and still create a result nobody is prepared to defend.
A week after that first call, Daniel opened the same workflow from a café table before a second meeting. The interface looked almost unchanged. The difference sat behind it: uncertain cases had somewhere to go, changes had an owner, and he could answer the ordinary question without reaching for a vague promise.
Comments
No comments yet.