The client pays for the research
Contract work is not a distraction from the product if every contract is chosen for what it leaves behind. A rule for picking which paying work a small product company should take.
CustomGlide exists because SocialSure needed to pay for itself. That is the honest version of the origin story, and I no longer think it needs a better one. The unified CRM and the QR ticketing system were contract work before they were products, built for clients who described what they needed and then checked that I had built it. What turned that work into a product line was not a pivot. It was a selection rule I did not have at the start and now apply to every engagement before I quote it.
Two ledgers
Every contract gets entered twice. The first entry is cash: the fee, the payment schedule, the retention. The second entry is residue: what the work leaves in the product once the client has their deliverable. Residue comes in three forms. A component, which is a piece of software the product line will reuse. An integration, which is a working connection to a system the product line will meet again. Demand evidence, which is a paying customer who described a need precisely, paid to have it met, and used the result.
The rule is that a contract with a blank second entry is declined, however good the first entry looks. That sounds austere until you notice what it prevents. A small company that takes every well-paid job becomes an agency with a product on the side, and the product starves quietly, one reasonable decision at a time. A small company that refuses all contract work runs out of money before it learns what the product should be. The two-ledger test is the narrow path between those, and it is narrow on purpose.
Why this is the default path in India
I would give the same advice anywhere, but in India it is less a preference than a description. Tracxn's annual funding report for 2025 puts total funding into Indian tech at 10.5 billion dollars for the year, down from 12.7 billion in 2024 and 11.0 billion in 2023. The 2023 report had put 2022 at 25 billion, and described 2023 as the lowest year in five. Whatever the exact revisions between editions, the shape is the same: the 2021 to 2022 window closed, and it has not reopened.
For an engineer-founder without a fundraising story, that chart says the product will be paid for by customers or not at all, and the earliest customers who will pay are the ones who need something specific built. So the question is not whether to take contract work. It is which contract work, and the answer has to be about residue, because cash alone will keep you alive without moving you anywhere.
The three residues, in practice
A component is the easiest to recognise and the easiest to overvalue. The ticket-validation service inside the QR system is a component: a small piece that admits a visitor exactly once and can sit beside any booking flow. It was built for one client's gates and it is now the reason the product exists. But a component only counts if it is general enough to be reused without a rewrite and specific enough to be worth reusing. A client's custom report is not a component. A rate limiter that every future API will need is.
An integration is a connector to a system the product line will meet again, and it is worth more than it looks because the second time you meet the system, the work is already paid for. A CRM that is a migration target for teams leaving Salesforce, HubSpot and Zoho lives or dies by its importers, and every importer was, at some point, one client's migration. The client paid for the first version. The product got the connector.
Demand evidence is the residue people forget to count, and it is the one that would cost the most to buy any other way. A paying client is the only user who will tell you exactly what they need, pay to have it built, and then check, in production, that it does what they said. Every feature in a product roadmap that came from a paying client has passed a test that survey answers and pilot signups never pass. When I weigh a contract, a client who can describe a verb precisely is worth more than a client who pays more.
The four cells
Two questions sort every proposal: is the cash good, and is the residue real. Each pair of answers has its own response.
The top-left cell is the dangerous one, because it is where the best-paying work usually sits. A large client wants something bespoke that nothing else will ever use, and the fee is excellent. The response there is to re-scope before declining: can the deliverable be built as a general component with a thin custom layer, can the integration be written against the vendor's public API rather than the client's private one, can the contract include the right to reuse what is built. Often it can, and the client rarely minds, because they are buying an outcome, not exclusivity. When it cannot, the money is still declined, and that is the moment the rule is either real or decorative.
The pattern is older than the word startup
None of this is new. Mailchimp began in 2001 as a side project of the Rocket Science Group, a web design agency in Atlanta, and outgrew the agency. Basecamp was built inside 37signals, a design consultancy, to manage the consultancy's own client projects, launched in 2004, and the company eventually renamed itself after the product. Trello was built at Fog Creek Software, launched in 2011, spun out as its own company in 2014, and was bought by Atlassian in 2017. Three agencies, three products that each began as residue from paid work.
What those three have in common is not luck. In each case the agency built something for its own paid work or a client's, noticed that the residue was more valuable than the fee, and had the discipline to keep the residue general. That last part is the whole skill. Basecamp was useful to other consultancies because it was built for the general problem of managing client projects, not for one client's project. The fee for the client work paid the salaries while the general thing was being noticed, which is the only role cash plays in this story.
The limit of the rule
Residue that nobody consumes is just code. A component with no product line waiting for it is a library you maintain for free, and an integration to a system you never meet again is a connector that rots. So the second ledger needs one more column: who consumes this, and when. If I cannot name the product line that will use the residue within a year, the entry is blank, whatever the engineering elegance of the thing. That is the correction that keeps the test honest, and it is the one I most often need.
The rule, then, in full. Enter every contract twice, decline the ones with a blank second entry, re-scope the well-paid ones until the entry fills in, and name the consumer of every residue before you count it. The client pays for the research. Your job is to make sure the research is about something you were going to build anyway.
Get new posts by email
Occasional essays on engineering, AI, and building for the people technology leaves behind.
Subscribe with RSS