When payroll is four days away, take the enterprise automation contract only if its scope, team allocation, and exit point protect the product you still intend to build. Cash that turns your product team into a permanent client-services unit buys time while quietly changing the company.
In April 1970, Apollo 13 was headed to the Moon when an oxygen tank exploded. Jim Lovell, Jack Swigert, and Fred Haise had to preserve power, water, and breathable air long enough to get home. NASA’s Mission Control in Houston did not get to choose the mission it had planned. It had to choose the work that kept the crew alive.
That is the shape of a Friday payroll decision. The planned roadmap can wait. The company cannot.
The contract can solve the wrong problem
An enterprise automation contract arrives with a number large enough to cover payroll. The buyer has urgency, a real workflow, and people who can approve an invoice. In a tight capital market, that can feel like the only serious option.
The danger sits inside the delivery plan.
If the contract requires your product engineer to become a dedicated implementation lead, your designer to work around one client’s process, and your founder to spend every week in account calls, the contract may remove the immediate cash problem while creating a product problem you cannot afford to ignore.
You need to ask a harder question than, “Can this pay the team?”
Ask: “What will still exist after we have delivered this?”
A useful contract leaves behind one of three things: reusable product capability, a repeatable implementation pattern, or a customer relationship that points toward a market you already want to serve. If it leaves behind a custom workflow that only one client can operate, call it services revenue and price it accordingly. Do not call it product validation.
That distinction gets sharper when capital is constrained and the market is rearranging around AI adoption. TechCabal recently reported rising African tech M&A alongside substantially higher layoffs, with restructuring and AI adoption among the cited causes. A signed contract is valuable. It also deserves more scrutiny when it could set the direction of a small team for months.
Put a boundary around the rescue money
At four days of runway, you may not have the luxury of rejecting the contract. You still have room to shape it.
Start with a narrow statement of work. Define the business process, the named users, the systems you will connect, and the approval point before anything reaches production. Put the custom work in a separate line item from the reusable product work. That protects the conversation later, when a reasonable request becomes a second bespoke workflow.
Then set a capacity limit before signing. A two-person product team cannot promise the enterprise buyer priority access to everyone whenever a deadline moves. Decide which person owns delivery, how much time the rest of the team can contribute, and what part of the roadmap will pause. Say it plainly.
This is where a written exit condition matters. It could be the end of a fixed implementation period, acceptance of a defined workflow, or a decision checkpoint after the first live use. Without one, an urgent project expands through small requests. Each request sounds temporary. Together, they become the company.
The operational ownership questions in Kojo’s pilot lacked an owner. Live queue access stayed unsafe. matter here too. An automation contract becomes dangerous when no one on the client side owns the real workflow. Your team then becomes the default owner of exceptions, access, and decisions that belong inside the customer’s business.
Keep Monday visible on Friday
A founder under pressure often treats the roadmap as a document for calmer times. That is how the contract becomes the roadmap by default.
Before signing, write down Monday’s smallest protected product commitment. It might be one customer interview, one release, or one decision about the product’s core workflow. Keep it small enough that the team can honour it during delivery. The point is to preserve contact with the product thesis while the contract pays for survival.
Also decide what evidence the contract must produce. If you are building AI software for a specific workflow, require access to the moments where the workflow breaks: the handoffs, approvals, missing data, and exceptions. A buyer’s polished requirements document is useful. Their real process is more useful. What Esi Learned From a Customer’s Real Workflow is the difference between building from a demo and building from the work people actually do.
The test is simple. At the end of the engagement, can you explain what you learned that changes the product for the next customer? If the answer is unclear, you have taken on temporary revenue. That may still be the right call. Name it honestly, and protect the team from pretending it is something else.
Survival needs a route home
Apollo 13 did not continue toward the Moon because that was the original mission. The crew and Mission Control changed the plan around the constraint that mattered most: getting the astronauts back safely. NASA documents the mission as an aborted lunar landing, but its systems, procedures, and people did what they needed to do under pressure.
Your Friday contract should have the same discipline. Take the cash if it preserves the people and capabilities required for the company you want on Monday. Set the scope, protect a small piece of roadmap capacity, and choose the point where the team returns to building for more than one buyer.
Comments
No comments yet.