An overseas contract should be evaluated as a roadmap decision the moment it requires the same people, attention, or calendar time as the next release. Revenue can extend runway while quietly removing the capacity needed to validate the product that must sustain the company after the contract ends.
At 4:47 on a Friday afternoon, Ebo was at a shared desk in Accra, looking at a signature page on his laptop. A coffee ring had dried beside his notebook. The client, based overseas, wanted an automation project delivered quickly and had sent back the agreement with one last request: two members of Ebo’s three-person product team needed to join the weekly implementation calls.
The contract would cover a gap Ebo had been carrying in his head for months. It would also pull the engineer who owned the next release away from the product for most of the following month.
The release mattered because it was the first version built around what prospective customers had repeatedly asked for. If it slipped, the team would keep selling a product they already suspected was too broad. If the contract consumed the team and ended without a repeat engagement, Ebo could reach the next quarter with more cash and less evidence that the product deserved another one.
That was the decision. The signature was still waiting.
Revenue only helps if it protects the next learning cycle
I have seen founders describe work like this as “keeping the lights on,” which is true as far as it goes. The danger starts when the work borrows from the part of the company that creates its next source of leverage: customer learning, product iteration, and distribution.
A contract can be good business and still be badly timed. The question is not whether the client is credible or whether the invoice is useful. The question is what the work displaces.
For Ebo, the displaced work was not a vague roadmap item. It was a release tied to a live uncertainty: would smaller teams pay for a narrower product that solved one recurring operational task well? He had conversations scheduled with prospects who had agreed to try it once the release was ready. A delay could cool those conversations, force another round of explanations, and leave the team building from assumptions for longer.
The contract had its own uncertainty. Its revenue depended on delivery, client feedback, and the project staying within scope. The product release depended on the team having protected time. One created cash. The other created a chance to learn what to build next.
Founders often treat those as separate buckets. On a small team, they are the same calendar.
Put the cost of the signature on the same page as the revenue
Before accepting work that touches the product team, I would write down three things before the call ends.
First, name the exact release or customer commitment that moves. “The roadmap slows down” hides the cost. “The onboarding flow for the three prospects already waiting moves into next month” makes it harder to wave away.
Second, identify who absorbs the client work. A founder can take on calls, coordination, and the uncomfortable early conversations. An engineer can build. When the same person must do both, the weekly meeting is rarely only one hour. There is preparation, follow-up, change requests, and the mental switch back into product work.
Third, decide what the contract must fund. If the money simply fills a general hole, every piece of client work will look urgent. If it pays for a defined runway extension, a contractor for a bounded task, or a specific product milestone, the trade becomes visible.
This is close to the tension in The Two Engineering Offers That Made a Ghanaian Founder Pause the Hiring Plan. More capacity can look like progress until recurring commitments turn it into a fixed cost before the product has earned it.
The useful version of “yes” has a boundary
Ebo did not reject the contract. He went back with a narrower delivery plan.
The client could have the initial automation work, a fixed set of workshops, and a clear handover. Product engineers would join only where their technical judgment was necessary. Requests outside the agreed work would wait for a separate conversation instead of appearing as a helpful extra in the next meeting.
That answer risked losing the deal. The client might have wanted a more embedded team. For a few hours on Friday, Ebo had no replacement revenue lined up and no guarantee the client would accept less access. The bad ending was plain: no contract, the same cash pressure, and a team that had spent a week negotiating instead of shipping.
The client accepted the narrower scope.
On Monday, Ebo’s engineer returned to the release work with a list of technical questions from the client, but without ownership of the client relationship. The first product build still had a protected slot in the week. The contract became a source of revenue and a source of sharper customer language, rather than a new operating model hiding inside a signed PDF.
Protect the release that answers the expensive question
The hardest part is that the contract may genuinely be attractive. It may come from a market you want to understand better. It may introduce people who could become long-term partners. It may be the difference between paying the team and having a difficult conversation.
None of that removes the need to price the roadmap cost honestly.
When I look at these decisions, I ask which unanswered question becomes more expensive if we delay it. Sometimes the answer is payroll, and the contract should win. Sometimes the answer is demand, retention, or a product promise already made to a customer. In those cases, a narrower engagement can be the stronger commercial move.
Ebo’s Friday did not produce a perfect plan. The client could still expand the work. The release could still reveal that the team had built the wrong thing. But he had kept the next decisive test alive. By the following week, the product team had a build ready for the prospects who had been waiting, and the contract had a boundary everyone could point to.
Comments
No comments yet.