A profitable automation contract can be the right choice when it buys runway without replacing the product work that must happen next. With payroll due Friday, the decision is to protect a narrow customer test, cap the contract’s demands, and treat the revenue as time to learn rather than proof that the product can wait.
Consider Esi, a composite founder in Accra. At 6:40 p.m. on Monday, she was sitting outside a small office near Osu with her laptop balanced on a tote bag, rereading a German company’s offer on a cracked phone screen. The work was familiar: automate document handling for a business that already knew what it wanted and had budget approved.
Her own product was harder. She and one engineer had spent weeks speaking with West African operators about a workflow that still changed from conversation to conversation. They had interest, but no paid commitment and no clean answer to what had to be built first.
Payroll was due in four days. If Esi declined the contract and the product conversations went nowhere, she would need to tell her engineer that the next month of work was uncertain. If she accepted it without limits, the German client could take every productive hour and leave the product as a deck, a backlog, and an increasingly expensive promise.
Neither outcome was theoretical. One missed payroll could break the trust she had built with the person carrying most of the technical work.
Revenue should fund a decision, not postpone one
The wrong framing is “services versus product.” A small company often needs both. Customer revenue can keep a team alive long enough to discover whether a product deserves more of the team’s attention.
The useful question is narrower: what product decision will this contract allow you to make within the next month?
For Esi, the decision was not whether West African businesses needed automation in the abstract. That was too broad to settle before Friday. She needed to learn whether a specific group would commit time, data, and money to one constrained workflow, even before the full product existed.
That changed the contract from a rescue rope into a tool. The German work had a clear commercial outcome. Her product work needed a clear learning outcome.
She wrote one sentence at the top of a blank document: “By the end of this contract, I need three prospective customers to react to the same proposed workflow.”
If the contract gave her money but made that sentence impossible, it would extend runway while weakening the reason for having runway.
This is the same tension behind [Ama's customer contract](\/blog\/ama-s-customer-contract-six-weeks-to-prove-paid-use-without-losing-the-roadmap-d2557dc1/). Revenue helps when it creates evidence. It becomes dangerous when every paid request quietly rewrites the roadmap.
Put the boundary in the contract before the work begins
On Tuesday morning, Esi did not reject the offer or accept it as written. She sent back a smaller proposal.
It covered one automation flow, a defined delivery window, and a named handover point. Requests outside that flow would need a separate conversation. She also kept two blocks of time each week for product interviews and prototype reviews, which meant the delivery schedule had to account for hours she would not sell.
That can feel reckless when cash is tight. It is often the only honest way to price the work.
A founder who says yes to an open-ended project is not protecting payroll. They are accepting a second company inside the first one: a client business with its own priorities, emergencies, and opinions about what should be built next.
The client may be reasonable. The pressure still accumulates. A request for one exception becomes a call. The call becomes a feature. Soon the engineer is maintaining logic built for a German client while the local customer problem remains untested.
Esi’s proposal made the trade visible. The client could accept a focused automation project, or choose someone available for a broader engagement. Either answer was better than taking money with an undefined obligation attached.
For technical work, define the human decision that remains after the automation runs. That boundary matters as much as the technical scope. [One disputed action can turn a ready AI agent into a liability](\/blog\/the-one-disputed-action-that-can-turn-a-ready-ai-agent-into-a-liability-2b66d1b1/) because a system can appear complete while responsibility is still vague.
Keep product learning embarrassingly small
The German client accepted the narrower scope late Wednesday. Esi had enough room to cover the immediate obligation, though she still had no certainty that her own product would earn its place.
She used the protected time for a small test. No platform rebuild. No broad launch. She showed the same workflow outline to a few operators, asked where it would fail in their day, and asked what they would need to see before paying for it.
The point was to make a decision difficult to avoid.
A founder can spend a month “building for the market” and finish with more code but less clarity. A better test creates a fork: continue, change direction, or stop spending on this version. Each result has value because it prevents another month of confident guessing.
That discipline matters when early-stage capital is tight and paid B2B work is carrying more weight. The contract is valuable because it gives the founder room to choose deliberately. It cannot choose for them.
Friday should leave a trace beyond payroll
On Friday afternoon, Esi sent payroll and closed the laptop before starting another client revision. The relief was real, but temporary. What mattered was the calendar she had protected for the following week and the single product question waiting there.
Her engineer knew the contract had a boundary. The prospective customers would see one proposed workflow, not a vague promise about AI. Esi would have a month to collect evidence before deciding whether the next hire, the next contract, or the next product build deserved the company’s limited attention.
That is the standard I would use under pressure: take the revenue when it protects a specific learning loop. Decline or reshape it when it turns the roadmap into whatever the next client asks for.
Comments
No comments yet.