The AI can produce the right result and the company can still fail to deliver. If a paid customer’s workflow starts only when the founder presses a button, the product has a human dependency that must be treated as part of the production system.
At 4:47 p.m., the customer is waiting. The model works. The prompt has been tested. The output has passed review before. Then the founder notices the missing step: nothing happens until he manually starts the workflow.
That changes the decision. He can trigger the run now and protect today’s delivery. He can stop and automate the trigger while the customer waits. Or he can acknowledge the manual dependency, deliver deliberately, and schedule the smallest change that removes him from the path.
A working component can still leave the system broken
In April 1970, the Apollo 13 crew faced rising carbon dioxide inside the spacecraft. The command module’s square lithium hydroxide canisters could not fit the lunar module’s round openings. The canisters worked. The filtration system worked. The pieces could not connect in the situation the crew was now in.
NASA engineers in Houston had to devise an adapter using materials available aboard the spacecraft. Astronauts Jim Lovell, Jack Swigert and Fred Haise then assembled the device by hand from instructions sent from the ground.
NASA documents the mission and the improvised carbon dioxide removal system in its Apollo 13 history: https://www.nasa.gov/mission/apollo-13/
The important detail is the gap between capability and delivery. NASA had functioning equipment, trained people and a spacecraft designed with redundancy. Survival still depended on joining incompatible parts under pressure.
A founder discovering a manual trigger at 4:47 p.m. faces smaller stakes, but the system has the same shape. The AI’s output quality answers one question: can the model do the work? It does not answer another: can the company deliver that work reliably when the founder is unavailable?
Deliver first, then name the dependency honestly
With a paid customer waiting, I would usually start the workflow manually and complete the delivery. Rebuilding the trigger under deadline pressure creates a second risk beside the first. A hurried change can break a path that currently works.
I would also record exactly what happened before closing the laptop:
- What event should have started the workflow?
- Why did that event fail to start it?
- Which account, permission or decision still belongs only to the founder?
- What would the customer have experienced if the founder had been on a flight, asleep or dealing with another failure?
This is more useful than writing “automate workflow” in a backlog. That phrase hides the actual dependency.
Perhaps an order arrives by email, but someone must copy its contents into an internal form. Perhaps a scheduled job exists, but the founder must approve every run. Perhaps the AI completes the analysis, while sending the result still depends on a private account. Each problem requires a different fix.
The manual step may even be sensible at the current stage. Early deliveries often need close review because the team is still learning where the model fails. The mistake is allowing a temporary control to become invisible infrastructure.
That distinction also matters when deciding whether to hire. A founder bottleneck does not automatically justify another engineer. Sometimes the next step is a scheduled trigger, a documented approval rule or access for a second operator. The decision resembles the one in Should Your Last Salary Fund Sales Evidence or an Engineer?: spend against the constraint you can demonstrate, rather than the architecture you imagine you will need.
Move the founder out of the critical path in stages
The first improvement should remove the deadline risk without removing judgment the product still needs.
Start by giving the workflow a named owner and a visible status. “Waiting for founder” should become an explicit state, not something discovered through a customer message. Add a second person who can start the run. Write the short recovery procedure while the failure is still fresh.
Then separate initiation from review. The system can start automatically while holding the result for human approval. That preserves quality control without requiring the founder to notice every new job. Once the team understands the common failure modes, approval can move to exceptions instead of every delivery.
Finally, test absence. The useful test is not another successful run with the founder watching the dashboard. Let a real delivery move through the documented path while the founder stays out of it. If someone needs a password, an explanation or an unrecorded judgment, the dependency remains.
This is closely related to The 9:12 Onboarding Failure, and What the Five O’Clock Deadline Could Cost. Deadlines reveal operational gaps that product demos rarely expose.
The next Friday should feel ordinary
Apollo 13’s improvised adapter succeeded because Houston could define the problem, work with the materials available and send instructions the crew could execute. NASA did not confuse a functioning canister with a functioning life-support path.
The founder at 4:47 p.m. needs the same precision. Start today’s run. Deliver what the customer paid for. Then identify the exact point where the workflow waits for one person and remove that dependency before the next paid delivery arrives.
On the following Friday, the best evidence of progress will be unremarkable: the job starts, the right person reviews the exception, and the founder learns about the delivery after it has already happened.
Comments
No comments yet.