Compliance approval can still arrive too late to save a startup. When the integration date falls beyond the company’s cash runway, the real decision is whether to change the delivery path, change the commercial terms, or walk away.
At 9:12 on Monday, Kojo opened the approval message for his AI contract workflow. The compliance team had said yes. Then he checked the estimated integration date against the cash forecast.
The date came six weeks after the company ran out of money.
The system worked, but the timeline failed
In April 1970, the Apollo 13 crew was heading toward the Moon when an oxygen tank exploded. NASA had procedures, trained teams and equipment designed for spaceflight. None of that removed the immediate constraint: astronauts Jim Lovell, Jack Swigert and Fred Haise had limited power, water and breathable air inside a damaged spacecraft.
One problem was carbon dioxide. The command module used square filters, while the lunar module used round openings. The crew had the wrong shape of filter for the cabin keeping them alive.
Engineers on the ground had to devise an adapter using materials already aboard the spacecraft. The solution, later documented in Jim Lovell and Jeffrey Kluger’s book Lost Moon, helped keep the air safe while NASA worked through the larger problem of bringing the crew home.
The mechanism matters here. NASA could not respond to a shrinking survival window by pointing to the quality of its original process. The process had produced a mission that was now in danger. The remaining resources and time determined the next move.
Kojo’s approval created the same kind of mismatch at a smaller scale. Compliance had answered one question: could the workflow proceed under its requirements? The cash forecast answered another: would the company still exist when the approved integration was ready?
Only the second answer could set Monday’s priority.
Approval has no value until it changes cash timing
An early-stage founder can spend months treating approval as the finish line. That is understandable when security reviews, data questions and procurement calls consume the week. Each completed document feels like progress.
But approval usually unlocks another queue. Integration, legal paperwork, testing, internal training and payment can still sit between the founder and cash in the bank.
Kojo needed to redraw the deal from the payment date backwards. If the customer paid after integration, and integration landed six weeks beyond the runway, the approved contract could not fund the company under its current structure.
That left a short set of decisions.
Could the customer pay for a defined discovery or setup phase before the full integration? Could Kojo deliver a narrower workflow using the systems already approved? Could both sides agree on a manual bridge while the technical connection moved through its queue? If none of those changed the cash date, what work would Kojo stop funding now?
These are commercial questions, even when they arrive wearing compliance language.
The same distinction appears in Ama’s delayed approval path. A completed review can establish permission without establishing a viable route to delivery. Founders have to model both.
Build the smallest bridge the approval permits
The dangerous response would be to accelerate the entire product. Kojo could ask the engineer to rush the integration, postpone existing roadmap work and hope the customer’s internal date moved forward.
That plan would spend scarce cash against a dependency Kojo did not control.
A better bridge would preserve the approved boundary while reducing what had to happen before the customer received something useful. That might mean processing one contract type instead of every document in the workflow. It might mean keeping a human approval step where the eventual product would automate it. It might mean charging for implementation work that had previously been bundled into a future subscription.
The narrower version needs its own acceptance criteria. What data enters the system? Which action requires a person? What output does the customer receive? When does payment become due?
Without those answers, a “small pilot” can absorb the same runway as the full integration. The scope sounds smaller while the meetings, exceptions and support work remain.
I would put the bridge in a one-page delivery map and ask the customer to confirm it. One outcome. One responsible owner on each side. One payment trigger tied to work Kojo can complete before the runway ends.
If the customer cannot accept any earlier commercial milestone, Kojo has learned something important before spending the remaining cash. The approval is real. The deal is still too late.
Runway must govern the next conversation
Apollo 13 returned safely because the people solving the crisis worked from the resources and time that remained. The improvised filter did not complete the original mission. It kept the crew alive long enough to pursue the outcome that now mattered.
Kojo needs the startup version of that decision. By Monday afternoon, he should send the customer a revised path with the smallest approved deliverable, the earliest defensible payment milestone and the decisions required from both teams.
Then he should update the cash forecast using the date money can actually arrive, rather than the date someone said yes.
Comments
No comments yet.