A cloud subsidy should accelerate learning, not pressure a founder into scaling an unproven AI product. With six weeks of runway left, the right move is to spend only enough of the expiring credits to answer the next commercial question before cash becomes the constraint.
At 9:40 on Monday morning in Accra, Kweku sat in a shared office with a cooling cup of coffee and the cloud dashboard open on his laptop. The credits expired Friday. His product could read customer messages, classify the request and draft a response, but three pilot companies had used it only in guided demonstrations. None had trusted it with a live queue.
Kweku is an invented composite, but the decision is familiar. He could increase model usage, process thousands of sample conversations and build the polished demo an investor expected to see. Or he could preserve his team’s attention for the slower work of finding out whether anyone would pay.
The bad ending was clear. By Friday, the startup could have an impressive technical system, no committed buyer and six fewer days to make payroll possible.
Expiring credits distort the decision
Free infrastructure changes how a founder sees cost. A model run priced at zero feels harmless, even when it consumes engineering time, creates monitoring work and produces features nobody requested.
Kweku’s first plan filled the week. His engineer would expand the message categories, connect another model and prepare a larger evaluation set. Kweku would record a new demo and send it to prospects.
Each activity sounded defensible. Together, they avoided the unresolved question: would a company allow this product to handle a real customer request?
The subsidy also created a false deadline. Friday mattered to the cloud provider. Kweku’s actual deadline came six weeks later, when the company needed enough cash to keep operating. Treating those deadlines as equal would let somebody else’s promotion set his product roadmap.
This is the same tension behind how an AI adviser can consume runway. Compute attracts attention because its usage appears neatly on a dashboard. Founder time disappears more quietly.
Replace the build plan with a proof plan
Kweku closed the infrastructure estimate and wrote one sentence on a sheet of paper:
“Before Friday, one operations lead must let the product classify a small batch of real, anonymised requests and tell us what would stop them using it again.”
That changed the week.
The engineer no longer needed to prepare for broad usage. She needed a narrow test with clear boundaries, a manual review step and a way to inspect every classification. Kweku no longer needed more prospect conversations in general. He needed one person willing to put actual work through the product.
This distinction matters with AI products because technical activity can imitate progress for a long time. More prompts, evaluations and integrations may improve the system while leaving the buying decision untouched. A useful test connects model behaviour to a decision a customer must make.
For Kweku, the proof plan had three limits. The test would use a small batch. Nothing would reach a customer without human approval. Any cloud spending had to support that test directly.
Those constraints reduced the amount of credit he could use. That was acceptable. Expired credit is cheaper than a month spent maintaining the wrong product.
The customer’s hesitation became the roadmap
By Thursday afternoon, one operations lead had agreed to the controlled test. Then the product misclassified a request that included two issues in the same message.
The room went quiet.
If the same error happened in live use, the company could send the request to the wrong person and miss a promise made to its customer. The operations lead paused the test. Kweku had less than a day before the credits disappeared, and the only evidence he had collected appeared to argue against deployment.
This was the useful moment.
The operations lead did not ask for more categories or a faster response. She asked to see uncertain classifications separately, with the original message beside them, so her team could decide. The product did not need to pretend certainty. It needed to make uncertainty visible.
Kweku and his engineer changed the workflow that evening. High-confidence classifications followed the normal review path. Ambiguous messages entered a separate queue with the relevant text highlighted. The next morning, the operations lead completed the remaining batch and agreed to discuss a longer pilot.
The credits had helped, but only after a customer’s hesitation determined where to spend them. That is a better roadmap signal than an expiring balance.
Leave Friday with evidence, not infrastructure
On Friday evening, Kweku still had unused credits. A week earlier, that would have looked like waste.
Instead, he had something more valuable: a specific failure mode, a product change tied to real work and a next conversation with someone who had seen the system under pressure. He also knew what remained unresolved. One controlled batch did not prove retention, acceptable error rates or willingness to pay.
His Monday decision became simpler. The team would keep the separate uncertainty queue, run another supervised test and ask for a paid pilot before expanding the architecture. If no company accepted that step, more cloud capacity would not rescue the product.
When a subsidy is about to expire, write down the customer decision your spending must unlock. Give the week a small test, a named risk and a stopping point. Then let unused credits disappear if the evidence tells you to stop.
On Kweku’s desk, the cloud dashboard still showed a balance. Beside it, the sheet of paper now held a second sentence: “Ask for the paid pilot on Monday.”
Comments
No comments yet.