Building for India, seven projects later

I have never had one India career. I have had several, stacked untidily on top of each other.

I built software for colleges and an education company. I helped make a newsroom work across sixteen languages. I opened hostels in Goa. I joined a crypto exchange as it went from fifty thousand users to two million, then built a network for web3 founders across twenty cities. More recently, I tried to draw seventy years of Indian development as a technology tree.

On paper, these projects have very little in common. Looking back, they kept teaching me versions of the same lesson:

India is not one large market. It is a dense collection of different systems, moving at different speeds, connected just enough to surprise you.

That changes how you build here.

Scale arrives before sameness

My first product was an alumni-management SaaS for colleges. Seven institutions eventually put it in front of more than 750,000 people. Soon after, I worked on an e-learning platform serving over 250,000 students.

Those numbers sound like internet scale. The work did not feel like serving one giant, uniform audience. Every institution had its own processes, gatekeepers, data, incentives, and definition of success. Distribution happened one relationship at a time even when usage became enormous.

The same thing became literal when we built a CMS for Zee’s regional channels. It had to work across sixteen languages. Language was not a translation layer to add after the product was finished. It shaped permissions, workflows, publishing, and who could operate the system in the first place.

India gives you scale quickly and standardisation slowly. A product can reach a huge number of people while still crossing dozens of institutional and cultural boundaries. “The Indian user” is usually a sign that someone has stopped looking closely enough.

Communities need a place to become real

Then I left software for hostels.

Happy Panda hosted more than 1,400 people from 53 countries before it was sold. Imagination, the artists’ hostel that followed, became something stranger and more interesting: a place where books were written, bands formed, songs were made, and relationships outlasted the building itself.

The useful part was not simply putting interesting people under one roof. It was giving them enough structure to collide repeatedly: shared tables, recurring rituals, reasons to contribute, and time for trust to compound.

I carried that lesson into every community I built later. A large chat group is not an ecosystem. A list of members is not a network. People need a room — physical or otherwise — and a reason to keep showing up for one another.

Distribution is part of the product

At WazirX, I joined as the third person on the marketing team. The exchange grew from roughly 50,000 users to two million in a year.

Crypto was global software meeting a particularly Indian mix of curiosity, skepticism, regulation, aspiration, and word of mouth. Explaining the product was part of making the product useful. Trust could not be separated from growth, especially when the category itself was unfamiliar and contested.

The small team mattered too. Better-funded competitors could buy more attention. We had to understand where conviction already existed, give it language, and help a community carry the story further than a campaign could.

India often rewards this kind of distribution: not broadcasting one message to everyone, but finding the communities where an idea already has energy and giving them tools to move it.

There is no single startup ecosystem

Buidlers Tribe began with the same mistake many ecosystem projects make: the temptation to treat founders, capital, advice, and opportunity as if they all lived in one room.

They did not. We worked with 1,200 founders and 360 investors, ran sixteen demo days in a year, and built chapters across twenty cities. The city chapters were not regional copies of a central community. Each place had different densities, ambitions, constraints, and people capable of pulling others together.

An ecosystem is not a national leaderboard. It is a set of local trust networks with bridges between them. The bridges matter, but so do the local differences. Flatten those differences and you usually end up designing only for the people already closest to capital and attention.

The missing layer is often a capability

Years later, I found myself trying to understand why India’s achievements can look so contradictory.

The country can export software at enormous scale, land near the Moon’s southern polar region, manufacture medicines for the world, and run interoperable digital payments for a continent-sized population. It can also struggle with average learning outcomes, productive employment, supplier depth, and the diffusion of excellent institutions.

That became India’s Capability Tree: a map of twenty-five national capabilities across people, systems, production, knowledge, and the state. The central idea is that visible outcomes sit on top of prerequisites. You do not get industrial depth from one factory, or a research system from one excellent laboratory, or an ecosystem from one successful company.

This is also true at the scale of a product. When adoption stalls, the missing piece is not always another feature. It may be trust, language, distribution, trained operators, reliable infrastructure, or an institution that lets people coordinate repeatedly.

What I carry into the next build

None of this adds up to a neat playbook. India is very good at breaking neat playbooks. But a few working rules have survived:

1. Design for plurality from the beginning. Language, geography, class, institutions, and access are product architecture, not edge cases.
2. Build distribution into the thing itself. In a fragmented market, the path between communities matters as much as the experience after arrival.
3. Look for the missing capability. A feature cannot compensate for absent trust, skills, infrastructure, or incentives.
4. Create rooms, not audiences. The strongest communities let members make things with one another, not merely listen to the person at the centre.
5. Measure diffusion. A brilliant pilot is evidence. The real test is whether the underlying ability becomes repeatable beyond the original team.

The thread through my work is clearer to me now. The college portal, the newsroom, the hostels, the exchange, the founder network, and the capability map were all attempts to make a complicated system easier to enter.

India keeps making that work difficult. It also makes it worth doing.

The projects and numbers mentioned here are documented in my proof of work. The national-capability claims, sources, and methodology live in India's Capability Tree.