What Happens When the Build Cannot Meet Monday’s Customer Deadline?

With four weeks of runway and a customer deadline on Monday, pause product development and pay for the spreadsheet workflow that delivers the required result. The right decision is the one that protects the customer commitment and buys time to learn whether the work deserves to become product.

At 4:17 on Friday, the build had to stop. The demo was close enough to make abandoning it painful, but too far from reliable enough for a customer who needed an answer on Monday. The team could spend the weekend chasing edge cases, or set up a spreadsheet, define the manual checks, and deliver the output the customer had actually asked for.

The customer’s deadline is the constraint

A product roadmap can make a manual workflow feel like retreat. It is not. A spreadsheet can be the shortest path to finding out what a customer will repeatedly pay for.

Write down what must be true by Monday: the input the customer sends, the output they expect, who checks it, and what happens when the data is incomplete. Then build only that path. If the customer needs a reviewed recommendation, give them a reviewed recommendation. Do not spend four weeks of runway building permissions, dashboards, or a model pipeline before you know the recommendation changes a decision.

This is the same discipline behind [Nia’s ready pull request](\/blog/nia-s-ready-pull-request-one-launch-could-delay-a-second-customer-aeb89ced/). Shipping code can feel like progress. Protecting the next learning opportunity often matters more.

Apollo 13 had to use what was already there

In 1970, Apollo 13 was in trouble after an oxygen tank explosion forced Jim Lovell, Fred Haise, and Jack Swigert to abandon the planned lunar landing. The lunar module became their lifeboat, but its carbon dioxide filters were designed for two people, not three.

Mission Control in Houston had a practical problem: square command-module lithium hydroxide canisters would not fit the lunar module’s round receptacles. The crew could not wait for a better-designed system. Engineers on the ground worked from the materials available onboard and developed an adapter using items including plastic bags, cardboard, tape, and a flight manual cover. The crew assembled it, and the carbon dioxide problem was brought under control before the astronauts returned safely to Earth.

NASA’s Apollo 13 history documents the adaptation because it was a response to a live constraint, with the outcome still uncertain. The solution was not elegant product design. It was a working interface between what existed and what the mission needed next.

Your spreadsheet is that adapter. It does not need to become the company’s operating system. It needs to let a customer get through Monday while you discover where the real product boundary is.

Pay for speed to evidence

Paying for a workflow can feel difficult when runway is short. But the relevant comparison is rarely between a free build and a paid tool. It is between paying for something that works now and paying salaries while a build misses the deadline.

Choose the smallest paid setup that gives you three things:

• A clear record of each customer input and outcome.
• A reliable way to assign and complete the manual work.
• Enough structure to see which steps repeat across customers.

Avoid buying a large suite because it promises a future architecture. You are buying evidence. If a simple spreadsheet plus a paid automation tool gets the customer a useful result, use it. Keep a short note beside each row: what required judgment, what failed, what the customer asked for next, and what could have been automated safely.

That record is more valuable than a polished demo with no operating reality behind it.

Turn the manual work into a product decision

After Monday, review the workflow before restarting the build. Look for the repeated pain, not the loudest feature request. If every customer needs the same data cleaned before the AI can help, the product problem may be ingestion. If each output needs an approval step, the product may need controls before it needs more generation.

The manual workflow also exposes what should remain manual. Some decisions carry enough customer or compliance risk that removing a person would weaken the service. That is a product insight, not a failure to automate.

Apollo 13’s adapter was never meant to be a permanent spacecraft system. It was built for the mission in front of the crew. Treat your Monday workflow the same way: make it dependable, document what it teaches you, and restart the build only when you can name the repeated job the code must do.