Why we build products instead of taking projects

There is a version of this business that is easier than the one we chose.

In that version, a client describes what they want, we scope it, we build it, we invoice it, and we move on. The work is real. The engineering is genuinely hard. The money is good and, more importantly, it is predictable. You can look at a signed statement of work and know roughly what next quarter looks like.

We know that version well. We were good at it. And we still walked away from it as our centre of gravity, because of something that took years to see clearly.

Project work resets. Product work compounds.

Here is the thing nobody tells you about services: every project starts at zero.

You finish something excellent, you hand it over, and then the next engagement begins on a blank page. The codebase isn't yours. The users aren't yours. The lessons stay in your head instead of in the product. You get better at building things, which is not nothing, but you never get better at any one thing.

Products work the other way. The version we ship this month starts from everything we learned last month. A fix we make for one customer improves it for every customer, including the ones who haven't signed up yet. Decisions accumulate instead of evaporating. Three years in, a product isn't three years of effort. It is three years of effort multiplied by everything that effort taught us.

That difference is boring in month one and enormous in year three.

Owning the whole problem changes what you build

When you take a project, you inherit someone else's problem statement. That is the deal, and it is an honest one: they have decided what to build, and you are being trusted to build it well. Your job is execution.

But some of the best decisions in a product are the ones made before the spec: the feature not built, the flow simplified, the assumption questioned. In project work, those conversations are awkward at best. You are being paid to deliver a defined thing, and "I think you are solving the wrong problem" is not usually what a client is buying.

With our own products, that conversation is the job. When we built Aadhaar verification into Accordsign, nobody handed us a requirements document. We looked at what actually breaks when a document is signed, which is almost never the signature itself, and almost always the question of who signed it, and built for that. That decision would have been very hard to make as a line item in someone else's scope.

The uncomfortable part

We should be honest about the trade, because the case for products is usually made by people who conveniently skip it.

Project work pays now. Product work pays later, if it pays at all. You carry the cost of every wrong guess yourself. There is no client to validate the idea, no purchase order confirming that someone wants this. You ship something you believe in, and the market is entirely free to disagree.

You also inherit everything permanently. There is no handover. Every product we have shipped is something we are still responsible for: the support, the edge cases, the version that breaks on a device we did not test. Products are not a way to stop doing the hard work. They are a way to do the hard work forever, on purpose.

We think that is the right trade. But it is a trade, not a free lunch, and anyone telling you otherwise is selling something.

What this means for the people we work with

We still work with founders and teams. That has not changed. What changed is how.

We partner rather than take orders. If we are building the first version of something with you, we are going to have opinions about what should not be built, and we would rather have that argument early than deliver something polished that does not work. We choose these engagements carefully, because a partnership where we do not believe the product should exist is bad for everyone, most of all you.

The same instinct shapes how we help teams build engineering capability. The goal is that you end up owning it, not that you end up dependent on us. Build, operate, transfer, and then genuinely transfer. If we have done it right, we become unnecessary.

The point

Building products is slower, riskier, and more stubborn than taking projects. It is also the only way we know to get properly good at something rather than broadly competent at everything.

We would rather ship a handful of things we will still be proud of in five years than a hundred things we have forgotten by then.

That is the whole strategy. Everything else is just execution.