A strong AI demo does not establish a viable product. Before you sell it, calculate what one active customer consumes in model calls, human review, support, and the exceptions that appear after the applause.
On Friday, the room was with the product. The workflow took a messy input, produced an answer that looked useful, and did it quickly enough for people to imagine it inside their business. Someone asked when they could try it. Someone else started describing a larger use case.
That is a good Friday.
Monday has a different job. Monday asks what happens when the same workflow runs all day, for a customer whose documents are longer, messier, and more important than the demo data. It asks who checks the answers that cannot be wrong. It asks what support looks like when a user gets a plausible result that does not fit their actual process.
The model bill is part of the answer. It is rarely the whole answer.
The costs a demo hides
A demo usually has a narrow path. You choose representative inputs. You stay close enough to explain what the system is doing. When something goes wrong, the person who built it is in the room and can recover.
A customer creates a wider path immediately. They upload the unusual file. They try the feature before a meeting. They ask why one result differs from another. They expect the product to remember context that was never captured. Every one of those moments can create more model usage, more manual review, or more support time.
The calculation needs to begin with a single active customer, not a future hundred.
Estimate the model calls behind their normal week. Then add the calls created by retries, follow-up questions, longer inputs, and failed outputs. Put a real cost beside the review work, even if the review is currently done by the founder. Put a cost beside support, because a product that needs explanation at every handoff has not yet earned the margin its demo suggests.
This is the same gap between a product that impresses and a product that can keep operating.
Apollo 13 had a working system with the wrong connection
In 1970, Apollo 13 had a carbon dioxide problem after the explosion that forced the mission to abandon its planned lunar landing. The lunar module had round openings for carbon dioxide scrubbers. The command module had square canisters. The available equipment did not fit together.
NASA records how engineers in Mission Control in Houston, including Ed Smylie, worked on an adapter using materials available to the crew. The crew used that improvised solution, and the Apollo 13 astronauts returned safely to Earth.
The point was never that the square canister was a bad component. It worked. The failure sat at the connection between a working component and the environment where it had to operate.
That is where AI products often get expensive. The model can produce a convincing answer. The missing connection is the operating design around it: input limits, fallback rules, review thresholds, customer expectations, and a price that covers the work.
I wrote previously about what Nia’s real workload taught us about customer trust. Trust becomes expensive when the product promises certainty but quietly depends on a person catching every exception.
Build the Monday calculation before the next sales call
I would make the economics visible in one short sheet before offering a pilot or quoting an annual contract.
Start with the customer action that creates value. It may be reviewing an invoice, generating a sales draft, classifying a support request, or extracting information from a document. Count the expected volume and the likely high-volume case. Those are different numbers, and the second one is often where the margin disappears.
Then map the work around each action:
- Model calls, including retries and follow-up prompts.
- Human review for outputs that carry financial, legal, or customer risk.
- Support time when an output is unclear or the workflow breaks.
- Data handling, monitoring, and the time required to investigate a disputed result.
You do not need false precision. A range is enough to expose whether the price leaves room for the business to breathe. If the answer depends on every customer behaving perfectly, the price is too low, the workflow is too broad, or both.
This changes the sales conversation as well. Instead of promising an unlimited version of a demo, you can define the job clearly: which inputs the product handles, when a person reviews the result, and what usage sits inside the agreed price.
That clarity can feel less exciting in the room. It is far more useful after the first invoice.
A better demo includes the boundary
The next demo can still show the fast, satisfying moment. Keep it. People need to see the value before they can assess the details.
Then show one awkward case. Show what happens when the input is incomplete, when confidence is low, or when the product needs a review step. Explain the boundary in plain language.
A buyer who understands that boundary can evaluate the product honestly. Your team can estimate the work honestly. The product has a chance to earn its margin without asking a founder to absorb the difference every Monday.
Apollo 13’s solution worked because the team designed for the materials and constraints actually available to the crew. An AI product needs the same discipline: price and shape the system for the customer who will use it, not the room that applauded it.
Comments
No comments yet.