When a model-usage invoice competes with payroll, protect the engineer and reduce or pause the workload creating the bill. Compute spend can be recovered after a delay; losing the person who understands the product can cost months of runway.
At 4:37 on a Friday afternoon in Johannesburg, Kabelo was holding two payment notices on his laptop screen. One covered the next model-usage charge for his AI product. The other was the salary due to his only engineer on Monday.
Kabelo is an illustrative composite, but the decision is familiar. He had spent the week preparing a demo for a potential customer in Europe. His engineer, Thandi, had stayed late twice to repair an unreliable document-processing flow. The demo worked again. The invoice arrived before the customer had committed.
Both payments could not clear.
The invoice exposed the real product decision
Kabelo first treated the problem as a cash timing issue. Perhaps the customer would confirm on Monday morning. Perhaps the model provider would allow another attempt after a failed payment. Perhaps Thandi would accept a short delay if he explained it properly.
Each possibility moved the discomfort forward without changing the underlying decision.
The model bill had grown because the team was running repeated evaluations, keeping a demonstration environment active and processing sample documents at a quality level the buyer had never agreed to pay for. The invoice looked like infrastructure spend. In practice, it recorded a product decision: Kabelo had funded proof before securing enough evidence of demand.
That distinction matters on limited runway. A technical bill can feel compulsory because the service sits inside the product. Yet the amount often reflects choices about traffic, model size, retries, logging, evaluation frequency and how long an unpaid pilot remains available.
Payroll carries a different obligation. Thandi had already exchanged her time for an agreed salary. Delaying it would transfer the company’s product risk onto her household.
By Friday evening, the bad ending was clear. If Kabelo paid the model charge, Thandi’s salary could fail on Monday. She might leave, and the product would lose the person who knew why its extraction pipeline failed on particular document layouts. If he protected payroll, the demonstration environment could stop before the buyer’s next review.
There was no painless option left.
Protect the capability that takes longest to replace
I would compare the two payments by reversibility.
A suspended model account can usually be restored once funds arrive. A smaller model, usage cap or temporarily reduced workload can keep essential paths alive. Some evaluations can wait. An unpaid engineer cannot be treated as capacity that pauses cleanly and returns when convenient.
The harder question is what the engineer is currently preserving. Thandi held more than code output. She knew which apparent bugs came from prompt changes, which failures belonged in application logic and which edge cases the team had accepted because fixing them would consume another week. That knowledge had accumulated through shipped work.
Kabelo chose payroll.
The decision did not solve Monday’s demo problem. It gave him a basis for solving it honestly. He shut down nonessential evaluation runs, disabled the public demonstration path and kept a narrow internal test available within a lower usage limit. Then he told the buyer that the next review would use a controlled sample rather than an always-on environment.
He also removed a planned feature from the week’s work. The team would spend that time measuring the cost of each successful document run and identifying retries that produced no customer value.
This is the same discipline required when an external dependency threatens a commercial commitment. In What Should You Do When the API Will Miss a Customer’s Renewal Deadline?, the useful move is to expose the dependency early enough to change the promise. Waiting preserves appearances while the available choices get worse.
Put a commercial limit around every technical experiment
The mistake happened before the invoice arrived.
Kabelo had allowed an unpaid buying process to behave like a live customer account. Each request from the prospect sounded small: another document set, a cleaner output, a fresh run before the next call. Together, those requests created recurring compute spend and consumed the engineer’s attention.
A useful control is to define the experiment before running it:
- Set the maximum spend the company will risk before receiving payment or a signed commitment.
- Name the decision the experiment must unlock, such as whether extraction quality clears the buyer’s threshold.
- Stop workloads that do not contribute to that decision.
- Review model cost per completed customer task, including failed calls and retries.
This protects runway while producing better product information. A lower invoice alone proves little. Knowing which customer action creates the cost gives the team something it can price, redesign or refuse.
The same ownership problem appears after launch, when a small feature quietly creates support work nobody budgeted for. Feature Cost After Launch follows that cost beyond the release itself.
Monday began with a smaller promise
On Monday morning, Thandi’s salary cleared. The broad demo environment stayed off.
Kabelo joined the buyer call with a controlled set of documents and a narrower claim about what the product could currently do. The buyer could have walked away. That possibility remained part of the decision.
Instead of spending the call defending an expensive demonstration, Kabelo asked which document flow mattered enough to fund a pilot. He left without a contract, but with a defined test, a spending ceiling and no hidden payroll debt.
The next invoice would no longer decide whether his engineer got paid. Before the team ran another model evaluation, Kabelo would know which commercial question it was meant to answer and exactly when the experiment had to stop.
Comments
No comments yet.