Praise for an AI feature means little until the price covers what it costs to serve one customer. Before building further, calculate the feature’s cost per real customer at the price that customer can actually pay.
In 2017, MoviePass faced that same test at a much larger scale. CEO Mitch Lowe had helped turn a little-known cinema subscription into an offer people immediately understood: watch films in cinemas for a low monthly fee. Demand surged. The unresolved question was whether every new subscriber created a viable business or another bill MoviePass could not afford.
When strong demand makes weak economics harder to see
MoviePass paid cinemas when subscribers used the service. Heavy use therefore increased the company’s costs, even while subscriber growth looked like proof that the offer worked.
Business Insider documented the company’s rise and collapse through interviews with former employees and executives. The central problem was plain: the subscription price and the cost of fulfilling its promise did not hold together. MoviePass had found something people wanted. It had not found a price at which the company could keep giving it to them.
That distinction matters for AI founders because feature enthusiasm often arrives before anyone measures the full serving cost.
A Cape Town founder can leave an investor meeting with a page of positive notes about an AI research feature. The demo may produce a useful answer, explain its reasoning and save a customer an hour. Every person in the room can praise it honestly.
Then the first local customer uses it repeatedly.
Each request triggers several model calls. Documents must be parsed again because the retrieval layer is still crude. Failed outputs need retries. A founder or engineer checks edge cases by hand. Support arrives through WhatsApp because that is where the customer already communicates. By the end of the month, the cost of delivering the feature exceeds the amount the customer is prepared to pay.
The praise was real. The price was wrong.
Calculate the cost of the behaviour you are selling
Early AI pricing often begins with a competitor’s monthly fee or a number that feels reasonable for the market. Neither tells you whether your particular product can serve your particular customer profitably.
Start with one customer and their actual behaviour.
Count the model calls behind a completed task, including retries and background steps. Add document processing, storage, search, monitoring and any paid data sources. Then include the human work hidden behind the interface: reviewing outputs, correcting records, handling support and rescuing failed workflows.
This is where founders often discover that the expensive part is not the visible response. It is everything required to make that response dependable.
The same issue appears in automation products. A workflow can look autonomous during a controlled demonstration and still depend on a person whenever the final action fails. I wrote about that gap in Can We Call a Workflow Autonomous If a Person Must Rescue It?. Rescue work belongs in the cost calculation, even when it happens irregularly.
Run the calculation against a heavy user, an ordinary user and a customer who encounters failures. Average usage can conceal the account that consumes the margin from several others.
Change the product before defending the price
Once the numbers fail, raising the price is only one option. In price-sensitive markets, it may be the least useful first move.
The founder can narrow the feature to the part customers value most. A broad AI research assistant might become a specific document-checking workflow. The product can use a cheaper model for routine steps and reserve the expensive model for cases that need it. It can cache repeated work, limit context, process documents once or ask the customer to approve costly actions before they run.
Usage-based pricing can help when customer behaviour varies widely, but customers still need a bill they can predict. A base allowance with clearly priced additional usage may be easier to trust than an open meter.
Sometimes the correct decision is to remove the feature from the core plan. Sell it separately, restrict it to higher-value workflows or keep it out of production until the delivery cost falls. That choice can protect runway better than hiring another engineer to improve a feature whose demand has not been tested at a sustainable price. The trade-off resembles the one in AI Startup Runway Planning: Why Kabelo Kept Customer Insight Over Compute.
Put the price inside the product decision
MoviePass did not fail because customers rejected the offer. Its popularity increased the pressure created by its economics. The more people used what they had bought, the harder the model became to sustain.
An AI feature can create the same trap on a smaller balance sheet. Investor praise may confirm that the demonstration is clear. Customer use confirms whether the feature solves a problem. Only the serving-cost calculation shows whether the company can afford that success.
Before the next demo, take the last five completed customer tasks and calculate the full cost of each one. Include retries, support and founder time. Compare that figure with the price customers have accepted, then decide whether to change the model, narrow the workflow, meter usage or stop selling the feature in its current form.
Comments
No comments yet.