A short runway changes a hiring decision into a risk decision. Before adding an AI engineer, a founder should decide which uncertainty the company can afford to carry for the next six months: technical execution, customer demand, or cash.
At 4:17 on a Friday afternoon in Johannesburg, Kabelo, an invented composite of several early-stage founders, was holding a draft offer letter and watching his bank balance refresh. He had entered the day ready to hire an AI engineer. The candidate could start within weeks, and Monday’s call was meant to settle the final terms.
One customer had delayed signing. Another wanted a pilot before committing. If both decisions slipped, the new salary would leave Kabelo choosing between payroll and model usage costs before the product had enough paying customers to support either.
He closed the offer letter.
For the first time that week, the hiring question looked smaller than the company question.
Three uncertainties were competing for the same cash
Kabelo’s product could extract useful information from messy business documents. The demo worked well on the files his team had tested. It also failed in ways he could not yet predict: unusual layouts, incomplete scans, and prompts that made sense to customers but exposed gaps in the workflow.
An AI engineer could reduce that technical uncertainty. Better evaluation, stronger recovery paths, and tighter model selection would make the product more dependable.
The customer uncertainty was harder. Kabelo had encouraging calls, but encouragement does not fund a team. Prospects liked the demo. They had not yet proved that the problem was urgent enough to survive procurement delays, internal approvals, and the discomfort of changing an existing process.
Then there was runway uncertainty. Hiring would increase the company’s ability to build while reducing its ability to wait. Every month spent learning what customers valued would become more expensive.
This is where founders often compare a candidate’s cost with the work that person could ship. The more useful comparison is between the uncertainty the hire removes and the uncertainty the salary makes harder to carry.
Kabelo could afford imperfect technology for another quarter if pilots stayed small and closely supported. He could not afford six months of excellent engineering followed by the discovery that buyers wanted a narrower product, a different workflow, or no product at all.
The job description had assumed the answer
The draft role asked for production experience with language models, evaluation systems, APIs, and cloud deployment. It was specific about the work and silent about the decision behind it.
That silence mattered.
By writing “AI engineer,” Kabelo had already decided that technical capacity was the constraint. Yet the evidence on his desk pointed elsewhere. The team could still build. What they could not yet do was explain which customer problem deserved the next six months of building.
This was the same distinction behind Kabelo’s earlier choice to protect customer insight over compute. Compute can improve a demo. More engineering can expand what it handles. Neither choice tells you whether a buyer will change a budget, process, or deadline because of it.
At 5:06, Kabelo replaced the hiring spreadsheet with three columns: uncertainty, evidence, and cost of being wrong.
Technical execution had visible failures and plausible fixes. Demand had warm conversations but no repeated buying pattern. Runway had one fact he could trust: the company’s cash would become less forgiving the moment the hire started.
The order became clear. He needed stronger customer evidence before he needed more building capacity.
A pause still had a cost
Kabelo did not feel relieved. Delaying the hire could cost him the candidate. It could also leave the current team carrying technical debt while customer conversations consumed the founder’s week.
For one uncomfortable hour, both outcomes remained live. Hire now, and payroll might force a rushed fundraise or a smaller product budget. Wait, and the candidate could accept another offer while competitors improved their own systems.
The turn came when Kabelo changed the unit of the decision. He stopped asking whether the candidate was good enough. He asked what evidence would make the role necessary.
The answer was concrete: repeated pilot usage, a customer willing to pay for the workflow, and a known technical bottleneck preventing delivery. Until those appeared together, a permanent engineering hire would place a long commitment against a short history of demand.
He rewrote Monday’s call. Instead of presenting the offer, he would explain that the timing had changed and explore a limited piece of work with a defined endpoint, if the candidate was open to it. That option still required cash and honest scoping, but it tied spending to the immediate uncertainty rather than pretending the company already knew its shape.
Monday started with a different role
By Monday morning, the old job description was gone from Kabelo’s desk. In its place sat a short list of customer questions, two pilot milestones, and the technical failure that would trigger specialist help if the current team could not resolve it.
The company still needed engineering. It also needed permission from reality to expand the team.
This is the practical runway test I use: write down the uncertainty each hire removes, the monthly flexibility the hire consumes, and the evidence that would make waiting more expensive than acting. If those three lines stay vague, the role has arrived before the decision.
Kabelo entered Friday trying to recruit ahead of the roadmap. He left with a harder assignment: earn enough customer evidence to know which roadmap deserved a new salary.
On Monday, he made the candidate call without the offer letter open. The cash remained in the company, the technical gaps remained visible, and the next six months finally had a job description of their own.
Comments
No comments yet.