With six weeks of runway, automate only the narrowest stable part of onboarding and preserve cash for payroll. Rebuild after you have proved where the process fails, because rebuilding an unclear process can consume the runway without fixing the customer problem.
In April 1970, carbon dioxide was rising inside Apollo 13. Jim Lovell, Fred Haise and Jack Swigert had moved into the Lunar Module after an oxygen tank explosion crippled the spacecraft on the way to the Moon. The Lunar Module was keeping them alive, but its carbon dioxide removal system had been designed for two people for a shorter period.
The Command Module carried spare filters. They were square. The Lunar Module needed round ones.
NASA had usable equipment that could not connect to the system under pressure. The crew needed a working adapter before carbon dioxide reached dangerous levels.
Build the adapter before rebuilding the system
Engineers in Houston developed an adapter using materials available aboard the spacecraft, including plastic bags, cardboard and tape. Mission Control then talked the astronauts through the assembly.
The improvised device became known as the mailbox. It reduced the carbon dioxide level and helped keep the crew alive until Apollo 13 returned safely to Earth. Jim Lovell and Jeffrey Kluger document the mission in Lost Moon, including the improvised response to systems failing far from their intended operating conditions.
The decision facing a founder in Johannesburg at 4:17 on Friday has smaller stakes but a similar shape. Customer onboarding is failing. Six weeks of runway remain. Payroll is approaching. The founder can rebuild the process or connect the parts that still work well enough to buy time.
The first question should be: which failure is actually consuming cash or losing customers?
If prospects disappear because nobody follows up after a demo request, automate the follow-up and assign an owner when the automation fails. If customers stall because required information arrives across email, chat and spreadsheets, create one intake point before replacing every internal tool.
That intervention may feel embarrassingly small. Good. A runway decision should earn the right to become larger.
Separate process failure from software failure
A rebuild often begins with a software diagnosis: the onboarding portal is slow, the workflow has too many manual steps, or the team needs an AI agent.
The deeper problem may sit elsewhere. Customers may not understand what to send. Sales may promise an onboarding path the product team cannot support. One person may hold knowledge that never reached the rest of the team. Automation can move confusion faster without removing it.
I would map the last five failed or delayed onboardings before approving either option. For each one, I would record the first point where progress stopped, who noticed it, what they did next and whether the customer recovered.
Patterns matter more than complaints. If four customers stopped at the same handoff, the handoff is a candidate for automation or redesign. If each customer failed for a different reason, a rebuild based on one explanation is a runway bet disguised as engineering work.
This is the same discipline behind asking whether a workflow can be called autonomous when a person must rescue it. Human intervention does not automatically make automation useless. Hidden intervention makes its cost impossible to judge.
Give the temporary fix an expiry condition
Apollo 13’s adapter solved the immediate carbon dioxide problem. It did not become a new spacecraft architecture.
A startup’s temporary automation needs the same boundary. Define what it covers, which failures still require a person and what evidence would justify a rebuild. Otherwise, the temporary layer collects exceptions until the team spends every morning repairing yesterday’s repair.
For six weeks of runway, I would want the first intervention small enough to ship and observe within days. I would also keep a manual escape path. If the automation sends the wrong onboarding request, duplicates a task or loses context, someone must be able to stop it and recover the customer.
The decision record can stay short:
The repeated failure occurs at this handoff. The temporary automation addresses that handoff. One person owns exceptions. We will reconsider a rebuild after enough real onboarding attempts show whether the failure rate and recovery work have changed.
That record protects the team from rewriting history later. It also makes clear why payroll took priority over a wider build.
Spend runway on evidence you can reuse
A full rebuild might eventually be necessary. The six-week question is whether the team knows enough to design the right one now.
Every customer who completes the patched process produces evidence: where they hesitate, what information is missing, which exceptions recur and how much human rescue remains. That evidence can shape the later rebuild. Code written before those answers may have little value beyond the assumptions embedded in it.
This is why runway planning should protect customer insight alongside cash. The choice resembles the one in why Kabelo kept customer insight over compute. Compute, engineering and automation matter after the team knows which uncertainty they are paying to remove.
NASA’s engineers did not redesign Apollo 13 in flight. They connected available materials to the immediate constraint, tested the procedure on the ground and gave the crew instructions they could execute with what they had.
At 4:17, the founder should name the failed handoff, cap the temporary fix and assign the rescue path. Then run payroll.
Comments
No comments yet.