With one night left, repair the signup first. A stronger application can win attention, but a broken onboarding step prevents customers from producing the evidence that makes the story credible.
In 1970, carbon dioxide was rising inside Apollo 13’s lunar module while astronauts Jim Lovell, Jack Swigert and Fred Haise were using it as a lifeboat. The spacecraft carried lithium hydroxide canisters that could remove the carbon dioxide, but the command module’s square canisters did not fit the lunar module’s round openings.
NASA engineers in Houston had procedures to revise and decisions to explain. None of that mattered until the crew could keep breathing.
The failure underneath the story
The engineers developed an adapter using materials available aboard the spacecraft, including plastic bags, cardboard and tape. Mission Control then guided the astronauts through assembling it.
The improvised adapter worked. NASA’s account of the mission, including its Apollo 13 mission report, documents the carbon dioxide problem and the crew’s use of the modified canister arrangement. The repair did not guarantee their return to Earth, but it removed one immediate threat while the larger recovery effort continued.
The mechanism matters here. When the system carrying the mission has stopped working, improving the explanation of the mission comes second.
At 11:47 PM, a founder facing an ECOWAS application deadline has a smaller version of that decision. One browser tab contains the application. The opening paragraph still sounds broad. The market section needs a cleaner account of why this product belongs in Ghana, Nigeria or the wider region.
Another tab contains the signup flow. A customer enters an email address, continues, and reaches the point where the product should deliver its first useful result. It fails.
The application describes access. The product currently denies it.
Repair the evidence judges cannot see
The tempting choice is the application. Its deadline is visible, and the remaining work feels contained. Rewrite three paragraphs. Tighten the founder story. Explain the market. Submit before midnight.
The signup problem is less polite. It might take twelve minutes. It might expose a second failure. There may be no clean ending before the deadline.
I would still repair onboarding first, within a strict time box.
The reason is practical. A functioning signup can create evidence after the application closes. A customer can complete the flow, reach the product and tell you what happens next. A repaired paragraph cannot recover a customer who left at the broken step.
This does not mean spending the whole night rebuilding authentication or replacing the onboarding architecture. The task is narrower: identify the first point where a qualified user cannot proceed, restore that path, and verify it from a fresh session.
If the full repair exceeds the available time, create the smallest honest recovery path. Preserve the customer’s submitted details. Show a clear next step. Alert yourself when the failure occurs. Avoid a success message when nothing succeeded.
The same distinction appears in the 9:12 onboarding failure and what the five o’clock deadline could cost. A deadline creates pressure, but the customer’s blocked action identifies the actual constraint.
Give the application what remains
Once the signup path works, return to the application with the time left.
Do not attempt a complete rewrite. Make three passes.
First, remove any claim the repaired product still cannot support. Judges can forgive an early product with limits. Contradictions between the application and the experience are harder to defend.
Second, replace broad market language with the decision the founder has already made. Name the customer, the problem and the reason this product is being built now. If the strongest sentence requires words such as “transform” or “ecosystem,” it probably needs another concrete detail instead.
Third, describe the repaired onboarding step as current evidence only if it has been verified. “Customers can complete signup and reach the first result” is useful when true. A forecast written in the present tense creates a problem for the next conversation.
This is close to the choice in Kojo’s empty “jobs created” box. An application field can invite a founder to stretch the available evidence. Leaving the claim modest protects the product story after the deadline.
Use the deadline to expose the constraint
The useful outcome from this night extends beyond a submitted form.
A broken signup reveals where the product’s promise stops becoming customer experience. Repairing it protects tomorrow morning’s user, preserves a possible conversion and gives the founder a fact worth carrying into later applications.
Apollo 13’s engineers still needed procedures, calculations and clear communication. They simply handled the accumulating carbon dioxide before polishing the account of what the mission was meant to achieve.
At 11:47 PM, set a timer. Open a private browser window, enter the signup flow as a new customer, and repair the first blocked step. Then submit the clearest application the remaining minutes allow.
Comments
No comments yet.