When a promised API will arrive after a customer’s renewal deadline, tell the customer before proposing a temporary patch. Use the patch only if it solves the immediate need safely, has a named owner and removal date, and does not pretend the delayed integration already exists.
In April 1970, Apollo 13’s crew faced a deadline no project plan could move. After an oxygen tank exploded, carbon dioxide began accumulating inside the spacecraft. The lunar module had working scrubbers, but its square cartridges did not fit the command module’s round openings.
NASA could not deliver a redesigned life-support system to space. The crew needed a temporary adapter built from materials already aboard.
When a patch is the responsible choice
At Mission Control in Houston, engineers developed a way for Jim Lovell, Jack Swigert and Fred Haise to connect the incompatible parts using items available in the spacecraft. Lovell and Jeffrey Kluger document the episode in Lost Moon, their account of the mission later published as Apollo 13.
The improvised adapter worked. It reduced the carbon dioxide level and helped keep the crew alive until they returned to Earth.
That story has acquired a tidy ending, but the decision was made before anyone knew the full mission would succeed. The engineers were dealing with a fixed inventory, rising carbon dioxide and no opportunity to send replacement hardware. They did not present the adapter as a completed redesign. They defined the immediate failure, tested a temporary answer on the ground, and gave the crew instructions for building it.
A software patch can be responsible for the same reasons. It addresses a narrow, time-bound problem. The customer understands what it does. The team can test the path that matters before anyone depends on it.
The important word is temporary. A patch becomes dangerous when the sales conversation quietly turns it into the promised integration.
Put the dates on one page
I would start by writing down three dates: the customer’s renewal decision, the earliest credible API release, and the last day a temporary path can be tested without making the customer the test environment.
This often changes the discussion. “The API is nearly ready” sounds reassuring until the dates show that the customer must decide first. At that point, engineering progress and customer risk are moving on different clocks.
The next question is whether the patch solves the customer’s actual renewal concern. A manual export may keep reports moving, for example, while failing to address permissions, audit history or the staff time required to run it. The workaround can function technically and still leave the commercial problem untouched.
Ask the customer which workflow must remain usable after renewal. Then demonstrate that exact workflow with the patch. Avoid showing the parts that already work while talking around the missing step.
This resembles the timing problem in what happens when compliance approval arrives after cash runway ends. A valuable future outcome cannot settle an earlier decision by itself. The plan has to survive the order in which events occur.
Give the customer a real choice
An honest reset should contain four facts: what was promised, what will miss the renewal date, what the temporary path can and cannot do, and when both sides will decide whether to continue.
That conversation may put the renewal at risk. Hiding the timing problem puts more at risk. The customer could renew based on an assumption your team already knows is false, then discover the gap during a live workflow. You would enter the next negotiation defending both a product delay and a credibility failure.
Presenting the options plainly gives the customer decision rights. They can accept the patch for a defined period, renew on revised terms, reduce scope, or leave. Some founders avoid this because the final option is real. It was real before the conversation too.
If the patch requires daily intervention from an engineer, name that dependency. If it handles only one data path, state which one. If the permanent API date still carries uncertainty, give the next review point instead of turning an internal target into an external promise.
Make temporary work visibly temporary
Every workaround needs an owner, a removal condition and a failure response. Put those beside the renewal terms, not in an engineering note the customer never sees.
The removal condition matters more than a hopeful date. It might be successful completion of the customer’s required workflow through the API, followed by a short period in which both routes can be compared. If that test fails, the team should already know whether it will extend the patch, reduce scope or stop supporting the arrangement.
Apollo 13’s adapter was appropriate because the constraint was explicit and the objective was narrow: control carbon dioxide during the return to Earth. Nobody confused it with the spacecraft NASA intended to build next.
Treat the customer patch with the same discipline. Before the renewal discussion, send one page containing the two timelines, the workflow the patch covers, the known gaps, the person responsible and the next decision date. Then ask the customer to choose with the real facts in front of them.
Comments
No comments yet.