The most common way I see an early stage Indian company fail is not running out of money or running out of talent. It is running out of eighteen months while six vendors each deliver exactly what they were asked for.

I have been to five events in the last few months where founders talk about what they are building. The pattern shows up often enough that I want to write it down.

The company has raised a seed round or is running on revenue. It has a product that is genuinely more than one thing: an app, a backend, a hardware piece, an ML component, a compliance layer. The founders are not engineers, or are engineers in one of those five areas and not the others. So they contract out.

An agency for the app. A different one for the backend, because the first one does not do backend. A hardware design consultancy. A freelance ML person. A compliance consultant. Someone for the website.

Eighteen months later there is no product. Not a bad product. No product.

Every individual contract was reasonable. Each vendor delivered roughly what the statement of work said. And the thing does not exist.

The arithmetic nobody does at contracting time

When you split work across parties, you are not dividing the work. You are dividing the work and adding interfaces.

Two parties have one interface between them. Three have three. Six have fifteen. The count of pairwise communication paths grows as n(n-1)/2, which Fred Brooks pointed out about programming teams in 1975 and which has not stopped being true because we moved the boundaries from teams to companies.

Interfaces between companies are much more expensive than interfaces inside one. Inside a company you can walk over. Between companies there is a contract that defines the interface, and the contract was written before anyone knew what the interface needed to be. Changing it costs a negotiation. So people do not change it. They build to the wrong specification and discover the mismatch at integration.

The other asymmetry is incentive. A vendor is paid for delivering their piece to spec. Nobody is paid for the system working. Integration is the residual, and the residual falls on the founder, who is the only party with an interest in the whole thing functioning and usually the party least equipped to debug an interface between two codebases they did not write.

What it looks like from inside

The failures are specific and they repeat.

The app team assumed the backend would return a certain shape. The backend team built to a document written four months earlier. Neither is wrong. Both are done. The thing does not work and each escalation goes through two account managers.

The hardware arrives and the firmware interface is not what the app expects, and now there is a question about who pays for the change, and the answer takes three weeks that have nothing to do with engineering.

The ML person delivered a model with good validation numbers on a dataset the backend cannot actually produce in production, because nobody asked what the data pipeline would look like at inference time.

Everyone can point at their contract. That is the tell. When every party can demonstrate they delivered and the system does not work, the decomposition was wrong.

Why smart people do it anyway

It is not stupidity. There are real reasons and they are worth naming, because the fix has to survive them.

Vendors are legible. A quote for a fixed scope at a fixed price is something you can put in a board update and a spreadsheet. Hiring an engineer is a slower, riskier, less legible commitment that shows up as burn.

Specialisation looks efficient. It is efficient, for the piece. The efficiency is real and it is measured on the piece, while the cost lands on the joins, where nobody is measuring.

Founders without a technical background have no basis for estimating integration cost. It is invisible. You can see the price of the app. You cannot see the price of making the app talk to the backend, because it does not appear in any quote.

And there is a status effect. Having vendors and partners feels like operating a company. It generates meetings and updates and a sense of motion, all of which are easy to put in an investor update and none of which are a product.

What the ones that work do differently

The companies I have met that got through this did some version of the same thing.

They kept the interfaces in-house even when they outsourced the parts. One person or one small team owns the contract between components, writes the specification, and has authority to change it. This is the single strongest predictor I have seen. It does not require doing all the work internally. It requires that the joins have one owner.

They cut along interfaces that were already standard. Outsourcing a mobile app that talks to your backend over an API you defined is fine, because the interface is narrow, documented and stable. Outsourcing a component that has to be co-designed with another component is where it goes wrong. If two pieces need to change together, they belong to one team.

They wrote the integration test before the contracts. Not the unit tests. The end to end path, defined as an artefact, before anyone was hired. It becomes the acceptance criterion for every vendor at once, and it makes the interface explicit at the point where changing it is still cheap.

They paid for the integration explicitly. A named line item with a named owner and a schedule. Integration takes as long as it takes whether or not you budgeted for it. Budgeting for it just means you are not surprised.

They started with one vendor and one problem. Sequential rather than parallel. Slower on paper and faster in practice, because the second contract is written by someone who now knows what the first interface actually needed.

The rule I would give

Before you split a piece of work out, ask what has to be true for the piece to come back and fit.

If you can write that down in a page, and the answer does not change based on things the other vendors are still deciding, split it. If you cannot, or if it does, keep it. Hire one person instead of contracting three.

Coordination is not overhead on the work. Past a certain number of parties, coordination is the work, and treating it as a thing that happens for free between deliverables is how eighteen months disappear with everyone able to prove they did their job.

So when I look at a company of this shape, the first question is not what they are building. It is who owns the joins. If the answer is nobody, the rest of the diligence is decoration.

Related: