The safest answer is to take the contract only if the work strengthens the product, has a firm boundary, and leaves enough runway to test the company’s own demand. Revenue that assigns the engineers to one customer’s automation problem can keep the team employed while quietly turning the product company into an agency.
In 1975, Steve Sasson stood inside Eastman Kodak in Rochester, New York, with a device that challenged the business paying everyone’s salaries. Sasson and his colleagues had built the first self-contained digital camera. It captured black-and-white images without film.
Kodak’s film business was still the centre of the company. Sasson’s prototype worked, but pursuing it seriously would have directed people and money towards a future that threatened the current source of revenue. The company patented the technology, yet failed to lead the transition it had helped begin. The Smithsonian’s National Museum of American History documents Sasson’s camera and Kodak’s early digital work.
The mechanism matters more than the familiar ending. A company can recognise a promising product and still deprive it of the resources required to become a business.
The contract changes who controls the engineers
The contract arrives when the bank balance makes every argument sound theoretical.
It can cover payroll. It may extend the company’s life by several months. The customer has a real automation problem and appears ready to pay. Friday’s decision seems to concern revenue, but the deeper decision concerns control.
Who decides what the engineers build on Monday?
If the contract requires the same customer’s data model, approval process, integrations and reporting rules, the buyer controls the next product cycle. The founder may still own the company and maintain a roadmap document. Neither guarantees control of the team’s attention.
This is where revenue can disguise a change in business model. A product team begins accepting work that must be specified, delivered and supported for one buyer. The invoices say progress. The roadmap says delay.
I have seen this tension across startup work in Africa, Germany and the US. The contract value changes by market. The underlying trade remains the same: scarce engineering time can satisfy a known buyer today or test whether a repeatable market exists tomorrow.
The useful comparison is contribution, not contract size. How much cash remains after delivery, support, founder time and the product work displaced by the commitment?
Separate reusable work from rented capacity
Before Friday, I would rewrite the opportunity in two columns.
The first column contains work the product already needs: authentication, workflow rules, reusable connectors, audit trails or a capability requested by several prospects. The second contains customer-specific work: a private approval chain, a one-off dashboard, unusual deployment requirements or an integration with no second likely user.
The contract becomes more attractive when most engineering effort sits in the first column. It becomes dangerous when the buyer is effectively renting the team.
This distinction also prevents a common rationalisation. Founders often call custom work “product learning” because the customer will provide feedback. Some custom work does create useful learning. The test is whether the result changes a product decision for a defined customer group, rather than teaching the team how to satisfy one organisation.
A similar problem appears in the spreadsheet that revealed who really owns your roadmap. Ownership becomes visible when hours, dependencies and displaced work appear in the same place.
Put the contract into that spreadsheet. Include presales calls, delivery, revisions, support and the opportunity cost of delayed validation. A profitable invoice can fund the company. A demanding invoice with thin contribution can consume runway in a more respectable form.
Put the decision into the agreement
A vague yes creates the most risk. A bounded yes can preserve the upside.
Define a fixed delivery window. Name what the customer will receive. Limit revisions and support. Keep ownership of reusable components where the agreement permits it. Set a maximum share of engineering capacity, then protect the remaining capacity for the company’s product.
Most importantly, write down the evidence the engagement must produce. Perhaps the team needs to learn whether three workflow steps repeat across customers. Perhaps it needs proof that the buyer’s problem exists beyond one procurement process. If the engagement cannot answer a product question, treat it as service revenue and judge it honestly on service economics.
The founder should also set a stop condition before the first payment arrives. If the customer requests work outside scope, the answer can be a new price, a later phase or no. Without that line, each reasonable request makes the next request harder to refuse.
Jonas’s offer paid the bills, but threatened the market research he still needed. That is the same constraint viewed from the founder’s calendar: paid work can remove the time needed to discover what should be built.
Protect the question the product still needs answered
Kodak’s mistake was larger than one staffing decision, and the digital camera did not fail because of a single contract. The analogy has limits. Its useful warning is narrower: current revenue naturally receives resources because its value is visible, while a new product’s value remains uncertain.
Your product still has a question it must answer before the runway ends. Will customers pay without custom delivery? Does the AI output solve a frequent enough problem? Can users adopt it without the founder sitting beside them? Does the buyer who praises the demo control a budget?
Write that question at the top of Friday’s decision note. Then calculate how much time the contract leaves to answer it.
If the agreement pays the team, builds reusable capability and preserves a credible test window, take it with boundaries. If it consumes the engineers until the remaining runway can no longer answer the product’s central question, the customer is buying more than automation. They are buying the company’s chance to find its own market.
Before Friday, put two dates on the calendar: the contract delivery date and the date of the next product-demand test. If the second date cannot survive the first, renegotiate the work or decline it.
Comments
No comments yet.