A contract large enough to fund the company can still leave the company worse off. Take it only if you can protect the product work that creates your next source of revenue; otherwise, narrow the delivery, move the date, or decline.
In 2004, Jason Fried and David Heinemeier Hansson faced a version of that choice at 37signals in Chicago. The firm earned its money from client work. Basecamp, the project-management software they had built while running those projects, was still a new product with an uncertain future.
Client work paid now. Basecamp might pay later.
Revenue can protect the company and displace it
The Johannesburg founder opened the overseas offer at 6:12 a.m. The contract could cover salaries, infrastructure and the bills that arrive regardless of whether the product has found its market.
Then he reached the delivery date.
The work would consume the quarter reserved for the product: the customer interviews, onboarding changes and releases meant to test whether users would return and pay. Accepting the offer would extend the company’s financial runway while shortening its learning runway.
That distinction matters for an early-stage AI company. Cash tells you how long the company can operate. Learning tells you whether the company is becoming worth operating.
A contract can improve the first number and quietly damage the second.
I would begin by removing the contract value from the decision. Assume the money has not appeared yet. Write down what the product must prove during the quarter and what evidence should exist by the end of it.
Perhaps the team needs to see whether customers complete a workflow without founder support. Perhaps it needs five paying renewals, lower model costs or evidence that one painful task happens often enough to support a product.
Now place the contract beside those tests. Which ones become impossible because the same engineer, founder or product lead must deliver the overseas work?
That is the real price.
Separate useful customer work from disguised employment
Some contracts strengthen a product company. They expose the team to a recurring problem, pay for reusable technical work or introduce customers from the same market.
Others turn the founders into a temporary delivery team for one buyer.
The difference appears in the scope. If the overseas customer wants custom integrations, private workflows, weekly calls and ownership of the resulting work, the contract may fund a different company from the one the founders intended to build.
I use three tests.
First, can part of the work enter the core product without forcing every other customer to inherit one buyer’s requirements?
Second, will the team learn something it already needed to learn?
Third, can the delivery succeed within a fixed share of the quarter, with named people and protected product days?
A “no” on all three does not automatically kill the deal. It does change the negotiation. Reduce the scope. Split discovery from implementation. Move nonessential work into a later phase. Charge enough to cover the interruption, including the recovery time after delivery.
The dangerous agreement is the one priced as a project but staffed like a company takeover.
This is also why Kabelo kept customer insight over compute. Runway decisions become clearer when you ask which scarce resource produces the next useful answer. Sometimes that resource is cash. Sometimes it is uninterrupted attention.
Protect the quarter before signing the contract
At 37signals, Basecamp eventually created a path away from client services. Fried and Heinemeier Hansson describe that transition in Rework: the company began as a web-design firm, built Basecamp for its own project work, then shifted its attention to the product as demand grew.
The useful part of that history comes before the outcome looked obvious. Client services were known revenue. A software product launched in 2004 was a bet. Continuing to serve clients could have felt responsible while delaying the work that would reveal whether Basecamp deserved the company’s focus.
The Johannesburg offer has the same mechanism. The immediate revenue is visible, while the cost appears later as postponed interviews, rushed releases and another quarter without a clear product answer.
Before signing, put two calendars on the table.
One shows contract delivery: milestones, meetings, revisions and the people required.
The other shows the product quarter: customer conversations, experiments, releases and decision dates.
Do not allow the same person to occupy both calendars on the same days. If the plan depends on evenings, weekends or an uninterrupted run of perfect execution, the capacity does not exist.
The founder can then make one of four calls: accept with protected product capacity, renegotiate the scope, delay the start, or decline. Each is more honest than accepting first and hoping the quarter somehow stretches.
Decide what the money must preserve
The contract should buy the company time to reach a specific product decision. “More runway” is too loose because almost any cheque can satisfy it.
Name the decision instead.
By the end of the funded period, will the team know which users return? Whether the workflow survives outside a demo? Whether pricing covers model usage? Whether the product can be delivered without the founder joining every call?
If the contract prevents that answer, it funds motion rather than progress.
Fried and Heinemeier Hansson could keep taking client work because clients were already willing to pay. Basecamp required them to protect attention for something less certain. That uncertainty was precisely why the product needed a fair test.
The Johannesburg founder should reply after the two calendars agree. If they do not, the next email should contain a narrower scope and a later delivery date, not an immediate yes.
Comments
No comments yet.