When an autonomous feature fails hours before an investor demo, cut it and show the workflow customers can already complete reliably. A narrower product that finishes a valuable job gives investors more evidence than an ambitious system that may fail on screen.
Consider Kofi, a composite founder building an AI purchasing assistant for small distributors. At 12:07 a.m. in Accra, he was still at his desk, cold tea beside the trackpad, watching the assistant prepare tomorrow’s supplier order.
It chose the wrong quantity again.
The demo was scheduled for the morning. Kofi had promised the assistant would inspect sales history, choose what to reorder, and send the purchase request without human help. If it made the same mistake in the meeting, the investor would see a product making confident decisions with a customer’s money.
There was no safe explanation for that.
The feature that made the pitch weaker
Kofi had built the autonomous step because it gave the product a stronger sentence: “The AI runs purchasing for you.”
The working version offered a smaller promise. It gathered recent orders, flagged unusual changes, drafted the next purchase request, and asked the manager to approve it. Customers could already complete that workflow. They understood where judgment remained theirs.
Autonomy looked like progress on the roadmap, but it removed the point where a person could catch a bad quantity. Worse, the team could not explain why the assistant occasionally changed its recommendation after receiving nearly identical inputs.
At 12:31 a.m., Kofi faced two options. He could keep the autonomous flow and rehearse around its weak spots, hoping the right sample data produced the right answer. Or he could remove the final action and walk into the meeting with a smaller claim.
The first option protected the story he wanted to tell. The second protected the evidence he actually had.
A completed workflow beats simulated confidence
I have seen this decision appear in different forms while building products across African, European, and US markets. A founder wants the demo to show where the product is going. The buyer or investor needs to know what works now, who depends on it, and what happens when the model is wrong.
Those are different conversations.
A useful demo should make the product’s boundary visible. In Kofi’s case, the system could prepare the decision. The manager still needed to make it. That boundary reduced the headline appeal, but it made the workflow credible.
This is also why a polished AI output can become dangerous when the underlying reasoning remains hidden. The failure is rarely limited to an awkward meeting. A wrong balance, order, or recommendation can damage the trust required for the next transaction. Youssef’s AI showed the wrong closing balance because the team had treated a convincing answer as sufficient evidence.
Kofi opened the demo branch and removed automatic sending. He added an approval screen showing the proposed quantity, the recent orders behind it, and the field a manager could change.
By 1:18 a.m., the demo had lost autonomy. It had gained an honest ending.
The meeting changed when the risk became visible
The next morning, Kofi did not apologise for the approval step. He showed the investor how a distributor moved from scattered order records to a prepared purchase request, then paused before the commitment.
“What happens when the recommendation is wrong?” the investor asked.
Kofi changed the quantity and approved the corrected order.
That moment gave him a better conversation than the autonomous sequence would have produced. They could discuss where customer judgment belonged, which decisions created financial exposure, and what evidence would justify removing approval later.
The constraint became part of the product logic.
Founders sometimes hide manual steps because they fear appearing early. Yet a visible checkpoint can show that the team understands the cost of failure. The same principle applied when a cash step had to remain visible in a fintech product launch. When money, trust, or an irreversible action is involved, clarity can carry more weight than automation.
Decide what the demo must prove
Before showing an AI feature, write down the one claim the demo must establish. Then ask what evidence appears on screen.
If the claim is that the product completes a customer workflow, show the workflow reaching a useful end. If the claim is that the model can act without review, show how it handles uncertainty, exceptions, and correction. A smooth path through one prepared example cannot prove reliable autonomy.
Then identify the point where failure becomes costly. Put a human checkpoint before it until production evidence supports removing that checkpoint. This may make the demo less dramatic. It also makes the product easier to trust.
After the meeting, Kofi kept the approval screen. The autonomous version stayed off the roadmap until his team could define the conditions under which the system should act, pause, or ask for help.
That afternoon, a purchasing manager reviewed a drafted order, changed one quantity, and sent it. The product completed the job it could defend.
Comments
No comments yet.