A six-month runway usually calls for a smaller, staged engineering commitment before a full-time hire. Hire only when the engineer will shorten the path to paid learning enough to justify the runway they consume.
In April 1970, Apollo 13 was heading for the Moon when an oxygen tank exploded. Jim Lovell, Jack Swigert and Fred Haise were suddenly aboard a spacecraft with limited power, water and breathable air. NASA’s team in Houston had to stop treating the lunar landing as the goal. Getting the crew home became the job.
NASA’s History Office documents how Mission Control and the crew conserved the consumables that remained, using the Lunar Module as a lifeboat. They did not add capability because it sounded useful. Every decision was measured against the resource that could not be replaced.
Friday payroll can create the same kind of clarity. The question is not whether a strong engineer would improve the product. They almost certainly would. The question is whether the next six months should buy more build capacity, or more chances to learn what customers will pay for.
The hire changes the clock before they write a line of code
A capable AI engineer can make a demo real, reduce technical debt and give a founder someone to reason with. Those are meaningful gains.
They also change the company’s deadline. Payroll becomes higher every month. The founder may spend weeks recruiting, onboarding and translating a half-formed customer problem into product requirements. If the product direction is still unclear, the hire can make the wrong roadmap arrive faster.
This is especially sharp for a small team working across Accra, Lagos, Berlin or a US customer base. A contract in one market may keep the company alive while pulling attention from the product customers elsewhere are asking for. The decision has to include more than the monthly salary. It includes management time, the cost of changing direction, and the pressure created when every experiment now has a larger fixed cost.
The engineer should have a defined job that leads to evidence. “Build the AI product” is too broad. “Turn the manual review step used by three pilot customers into a working workflow, then measure whether they return” gives the work a boundary.
Demand has to carry part of the risk
Before adding a full-time cost, make customers carry some of the uncertainty.
That can mean a paid design partner, a signed pilot with a named workflow owner, or a manual version of the product that exposes where the AI actually helps. The goal is not to avoid building. It is to make the first build answer a commercial question.
A founder can ask for three pieces of evidence:
- Can we name the customer’s recurring decision or task?
- Does someone on the customer side own the workflow and have reason to change it?
- What would they do, pay, or commit to if the product worked?
If those answers are vague, preserve runway and narrow the test. A contractor, a fractional engineer, or a tightly scoped build may be enough to learn what a permanent hire would later execute with confidence.
This is close to the constraint behind [Ama’s polished demo]( /blog/ama-s-polished-demo-no-pilot-until-the-workflow-had-a-clear-owner-96247638/ ): a convincing product surface cannot substitute for a customer workflow with an owner.
Define the decision that earns the full-time seat
A full-time hire becomes easier to justify when the company can say what changes after the first 30 to 60 days.
Perhaps the engineer will replace a manual process already used in a pilot. Perhaps they will make a feature reliable enough for a customer who has agreed to deploy it. Perhaps they will remove the founder as the only person who can maintain a critical system.
Write down the smallest outcome that makes the hire worthwhile before making the offer. It should include a customer signal, not only a technical milestone.
For example: one existing pilot uses the workflow weekly; the team can identify the failure cases; the customer has agreed what a successful rollout looks like; and the next version depends on engineering work that cannot stay manual. That is a stronger case than hiring because a competitor has announced an AI feature or because the demo feels overdue.
The same discipline matters when an engineer leaves. [Samira’s workflow rebuild]( /blog/machine-learning-engineer-resignation-how-samira-rebuilt-the-workflow-7c46c198/ ) points to the underlying risk: when one person holds the system in their head, hiring can become an emergency response rather than a product decision.
Keep enough runway to change your mind
Apollo 13 reached the Moon, looped around it, and returned safely to Earth. The mission succeeded as a recovery because NASA preserved the resources needed for the revised objective.
Your revised objective may be simpler than the original plan: reach a paid pilot, validate one workflow, or learn that the market needs a different product. Runway buys the ability to make that correction.
A founder who keeps the six months has not chosen caution for its own sake. They have bought time to test a specific customer promise. A founder who hires has chosen a commitment that should produce evidence quickly enough to earn the next commitment.
Make the decision on Friday with a one-page brief. State the customer problem, the evidence already in hand, the milestone the hire must reach, and the date when you will reassess. If the brief still says “we need someone technical to build faster,” keep the months.
Comments
No comments yet.