Protect Friday payroll and reduce the AI feature to the smallest test that can answer a commercial question. Hiring a machine-learning engineer before that test creates a new fixed cost while leaving the demand risk untouched.
In April 1970, Apollo 13’s crew faced rising carbon dioxide inside the lunar module Aquarius. The command module’s lithium hydroxide canisters were square. The lunar module’s openings were round. NASA engineer Ed Smylie and a team in Houston had to make the incompatible parts work using materials already available aboard the spacecraft.
The outcome was still uncertain. The crew had limited power, limited supplies and no option to fetch better equipment. NASA’s history of Apollo 13 documents the improvised adapter that the astronauts assembled from instructions sent by Mission Control. It helped keep James Lovell, Jack Swigert and Fred Haise alive until their return to Earth.
The useful part of that story for a founder is smaller than the mission itself: when resources were constrained, the team solved the immediate survival problem with what they already had. They did not expand the team before proving the fix.
Payroll buys time to learn
The Accra founder in this decision has cash for one of two moves. The company can make one more full-team payroll, or it can hire a machine-learning engineer to accelerate the AI feature investors keep asking about.
The engineer appears to be the ambitious choice. It gives the founder a concrete answer for the next investor call: the AI hire has started, the feature is moving, the company is responding.
But the hire answers a staffing question. It does not answer the commercial one.
Will customers pay for the feature? Does the feature need a custom model, or would an existing API produce enough value? Is model quality the current constraint, or are customers still unclear about the job the product should perform?
Payroll keeps the people who already understand the customers, codebase and current commitments in place for another cycle. That time has value only if the founder uses it to remove uncertainty. Paying everyone and continuing the same roadmap would postpone the decision without improving it.
Build the smallest credible AI test
The founder should define the narrowest version of the AI feature that can change a decision. That might be a manual workflow behind a product screen, an existing model connected to a small set of customer data, or a prototype tested with a few current users.
The test needs a pass condition before anyone builds it. For example: a customer agrees to use the workflow on a real task, accepts the limitations and commits to a paid pilot if the result meets an agreed standard.
Investor enthusiasm does not count as validation. Demo applause does not count either. The test should produce evidence tied to customer behaviour: access to real inputs, repeated use, a signed pilot, payment or a clear refusal with reasons.
This is the same runway logic behind why Kabelo kept customer insight over compute. Compute and specialist talent can increase technical capability. Neither tells you which capability a customer values enough to fund.
A smaller demo can also expose whether the company truly has an AI problem. Sometimes the missing piece is model performance. Sometimes it is weak onboarding, unavailable customer data or a workflow nobody wants to change. Hiring a specialist before locating that constraint gives an expensive person a poorly defined problem.
Put conditions on the hire
Choosing payroll this Friday should not become a permanent rule against hiring. It should create a short, explicit path to the hiring decision.
Write down what must become true first. The condition might be a paid pilot that depends on better model performance, repeated customer use that exceeds the current system’s capacity, or evidence that the team cannot reach the required accuracy with existing tools.
Then define what the engineer would own. “Ship the AI feature” is too broad. “Reduce classification errors on these customer documents to the agreed acceptance level” gives the candidate, founder and customer something concrete to evaluate.
If the test reaches that threshold, the hire becomes easier to defend. The founder can show why generalist engineering capacity is insufficient, what commercial commitment depends on the work and how much runway remains after adding the role.
If the test fails, payroll has purchased an answer before the company added another recurring obligation. That is painful evidence, but it is cheaper than discovering the same thing after recruiting, onboarding and reshaping the roadmap around investor pressure.
Send investors the decision record
The founder still needs to answer the investors. A vague promise to move quickly will create the same question next week.
Send a short decision record instead: the company protected payroll, reduced the AI concept to one customer test, named the evidence required and set the condition for hiring. Include what remains unresolved. The purpose is to show that the company is moving toward evidence, rather than using headcount as a substitute for it.
Apollo 13’s adapter worked because Smylie’s team understood the immediate constraint and designed around materials already on board. An early-stage company has a different scale of risk, but the operating principle holds. Preserve the team long enough to test the critical assumption, then hire when the evidence identifies work that only the hire can do.
On Friday, run payroll. On Monday, put the smallest credible AI test in front of a customer.
Comments
No comments yet.