When runway can fund either AI inference or the contractor who understands customer abandonment, keep the contractor long enough to locate the failure and reduce inference spend. Compute only creates value when customers can complete the workflow it supports.
At 4:47 on a Friday afternoon in Pretoria, Kabelo had two renewal tabs open on his laptop. He is a composite founder, but the decision is one I recognise: one payment would keep his AI document assistant running for another month; the other would retain Mira, the contractor who had spent six weeks watching trial users disappear halfway through setup.
He could afford one.
If the inference account ran dry, the demo would stop working before Monday’s investor call. If Mira left, nobody else could explain why three promising customers had reached the same screen, paused, and never returned. The company might survive a broken demo. It would struggle to survive another month of paying for answers nobody reached.
Kabelo’s cursor stayed over the inference invoice. Keeping the product online felt like keeping the company alive.
The visible failure was easier to fear
Compute had a date attached to it. Miss the payment and the consequence was immediate: requests failed, the demo stalled, and the product looked dead.
Mira’s value was harder to display. She had no dramatic dashboard. Her notes contained short observations from customer calls: where a finance manager hesitated, which document label caused confusion, and why a founder abandoned the workflow after the model asked for information already supplied earlier.
That made the choice psychologically uneven. One expense protected something visible. The other protected understanding.
Founders often defend the machine first because downtime feels like an emergency. Customer confusion arrives quietly. There is no alert when someone decides the product asks too much of them. They close the tab and return to the spreadsheet, email thread, or junior employee who handled the task before.
By Friday, Kabelo was choosing between preserving output and preserving the ability to learn why the output was going unused.
The contractor held the missing context
Mira had noticed that customers were not leaving because the model answered poorly. They were leaving before the expensive inference step.
The workflow asked them to describe their goal, upload source material, choose an output type, and confirm several settings. The team had assumed those choices created flexibility. On calls, Mira heard a different interpretation: customers felt they were configuring a tool they had already paid to understand their problem.
That distinction changed the economics.
If Kabelo bought another month of inference without changing the path, he would fund more abandoned sessions. If he kept Mira, she could help remove the unnecessary questions, identify the smallest useful default, and test whether customers reached the model at all.
This was the same kind of ownership problem that appears after launch, when a feature’s cost continues through support, explanation, and correction. I wrote about that wider pattern in Feature Cost After Launch. A line item rarely tells you who holds the knowledge required to make that spending useful.
Kabelo paid Mira.
The decision still left a live risk. The inference balance could expire before the revised workflow produced evidence. An investor could open the demo at exactly the wrong moment. There was no comfortable version of the choice.
They bought time by narrowing the product
On Monday morning, Kabelo and Mira removed most of the setup choices from the first session. They selected one common document workflow and gave it a default path. They also limited repeated generations during testing, so a curious user could not consume the remaining inference balance by clicking through minor variations.
They did not solve every product question. They created a cheaper way to answer the most important one: would customers continue when the product made the first decision for them?
This is where runway planning becomes product work. A founder may think the choice is between one month of infrastructure and one month of labour. The real choice is between two kinds of uncertainty.
Infrastructure keeps the current system available. A person with direct customer context can sometimes change the system so it needs less infrastructure, reaches value sooner, or stops serving an unproven use case. That possibility matters most when cash is short because every untouched assumption keeps charging rent.
The same reasoning applies when an API deadline threatens a customer relationship. The immediate technical failure can pull all attention toward keeping the service alive, while the more valuable decision concerns what must be protected and what can be narrowed. I explored that tension in What Should You Do When the API Will Miss a Customer’s Renewal Deadline?.
The next invoice needed evidence
By the following Friday, Kabelo’s product still had a thin inference balance and an investor demo that required care. But he also had recordings of customers moving past the screen where earlier sessions had ended. Mira’s notebook now contained a sharper question about the next abandonment point.
That was enough to change the next decision.
Before renewing compute, he could examine completed workflows, the cost of each one, and whether anyone returned to run another. Before renewing Mira, he could ask whether her customer knowledge had been transferred into the product, the analytics, and the team’s decisions.
Runway should buy evidence that changes what you do next. When two expenses compete, I ask which one can reduce uncertainty around demand, remove future cost, or reveal that the current product should become smaller.
At 4:47 the next Friday, Kabelo still had two tabs open. This time, one of them contained customer behaviour he could use.
Comments
No comments yet.