Companies & OSS | Prakash Suresh

In May 2023, someone asked Kailash Nadh whether a developer should choose Go or Rust. Zerodha’s CTO answered in one line:

“We’ll look at Rust (or whatever else) when a need arises. Right tool for the right job!”

The interesting word is not Rust. It is need.

Kailash can build. Zerodha runs a brokerage stack across cloud and physical data centres with a small engineering team. In a later interview, he described using an LLM to produce a reasonably complex Rust prototype in hours rather than days. The ability was never in doubt.

The restraint is more instructive.

Modern engineering rewards visible construction. A new database, queue, language, or proxy is easy to admire. It demonstrates skill, creates a clean origin story, and avoids the compromises of someone else’s design. Open-source software offers a less dramatic path: begin with what already works, learn its limits, and change only the layer that has earned a change.

Sometimes that path ends in a new system. Cloudflare replaced part of its NGINX estate with Pingora. Shopify helped build YJIT into Ruby. Zerodha wrote a new document pipeline. These were not acts of technological faith. Each followed a repeated production constraint and arrived with numbers.

That is the distinction this post is about. A company should inherit by default, extend when it can, fork when it must, and build from scratch when evidence makes the continuing cost worth owning.

The expensive word is need

Kailash used the same phrase when asked about hiring. Zerodha’s technology team, he said, grows slowly and organically “as a need arises.” Software and headcount seem like different decisions, but they draw from the same finite pool: attention.

Every new person needs context, coordination, and a useful problem. Every new production system needs interfaces, observability, security work, migrations, incident response, upgrades, and somebody who remembers why an odd decision was made three years ago. The first version is the visible part. The organisation around it is the bill.

Zerodha’s account of scaling with common sense is full of this restraint. Its team adopted Kubernetes only after deployments had become complicated enough to justify it. It chose Go for specific WebSocket and concurrency demands after evaluating alternatives. Python services were not rewritten merely because another language benchmarked better. They moved only after the existing implementation had crossed what Kailash called a point of redemption.

This is not conservatism disguised as engineering wisdom. Keeping a failing system can be as irrational as replacing a working one. The useful question is whether a constraint has become expensive, frequent, and understood enough to justify a permanent new responsibility.

Context matters here. Zerodha operates under brokerage rules, exchange connectivity requirements, and a team comfortable running infrastructure. It uses AWS compute, storage, and bandwidth but largely self-hosts software on Linux instances. Kailash has cited cost, vendor lock-in, and the knowledge gained from operating the stack. A young SaaS company may rationally choose managed PostgreSQL, a hosted queue, and a platform that deploys its code. It has different constraints and different people.

Zerodha is a case study, not a default architecture.

The common principle is smaller: technology earns its place by solving a real problem in its setting. Company prestige, language fashion, and the pleasure of building do not supply that evidence.

Inherit before you replace

In October 2024, Zerodha committed $1 million a year to free and open-source software. Its announcement made the dependency plain: without FOSS, Zerodha would not exist.

Read that line as an architecture diagram. The customer-facing brokerage sits above Linux, PostgreSQL, ClickHouse, Redis, ScyllaDB, NGINX, HAProxy, Kafka, NATS, Grafana, compilers, libraries, and protocols built over decades. Zerodha did not employ the people who created all of them. It inherited their work.

Inheritance is not limited to self-hosting. A team can buy proprietary SaaS, use a managed service built on an open database, run open-source components on cloud machines, or operate physical servers. Most companies mix these choices. The boundary moves, but the underlying question remains: who handles upgrades, failures, migrations, and the eventual exit?

That boundary is why “build versus buy” is too crude. The practical ladder has more rungs:

Adopt and configure the existing system.
Extend it or contribute the missing capability upstream.
Fork it when the necessary change cannot live upstream.
Build a replacement when the previous three cannot meet a measured need.

Each step buys more control by accepting more ownership.

Zerodha’s own Kafka installation makes the point. In its 2021 infrastructure review, the company described Kafka as the central bus for standard topics and said the installation had required practically zero maintenance over years. Kafka is not universally simple, and another workload may expose very different costs. But a mature open system already meeting the requirement is evidence too. There is no prize for replacing it.

Shopify followed the same ladder from another direction. It began on Rails, employed core contributors as its dependence grew, and built YJIT to improve Ruby rather than rewrite every commerce service in a different language. Production traffic found problems that synthetic benchmarks missed; the fixes returned to CRuby. YouTube created Vitess when its MySQL operating model stopped scaling, and Slack later adopted Vitess rather than discard MySQL and years of organisational knowledge.

The pattern resembles the argument in Companies & Languages. A company does not prove technical depth by owning every layer. It proves depth by knowing which layer deserves its attention.

Evidence earns the rewrite

Zerodha did eventually rebuild its contract-note pipeline. The old process took seven to eight hours to generate and deliver the day’s PDFs. That was not a hypothetical scale concern. Customers and operations encountered it every trading day.

The team overhauled the pipeline after testing the available options. It wrote a lightweight queue called Tasqueue, moved a worker to Go, benchmarked PDF engines, selected Typst, and changed storage and delivery. The resulting system generated 1.5 million PDFs in roughly 25 minutes at negligible infrastructure cost.

Notice the order. There was a baseline. Existing options were evaluated. Individual components were replaced for stated reasons. The result was measured against the original failure. “We can build it” was never the whole argument.

Cloudflare’s Pingora story follows the same order at a different scale. NGINX had served the company well, but its process model and the cost of extending C and Lua became recurring constraints. Cloudflare considered continuing, adopting another proxy, forking, and building. Its production report said Pingora served more than a trillion requests a day while consuming about 70 percent less CPU and 67 percent less memory at the same traffic load. Those are Cloudflare’s measurements on Cloudflare’s workload, not a general verdict on NGINX.

Discord also had evidence before moving message storage from Cassandra to ScyllaDB: hot partitions, unpredictable latency, compaction backlogs, garbage-collection pauses, and frequent pages. Even with a compatible database, the company had to build Rust services, dual-write, verify results, migrate trillions of records, and learn a new set of failures. Compatibility reduced the move. It did not remove it.

Before a production team creates a replacement, five questions should survive a written answer:

What repeated production constraint does the existing system fail to meet?
What baseline or benchmark proves the gap?
Why can configuration, an extension, an upstream contribution, a fork, or an adjacent service not solve it?
What measurable target defines success, including migration and reliability?
Who owns compatibility, security, operations, and maintenance after launch?

A learning project does not need this gate. Rebuilding PostgreSQL, Kafka, Redis, or a compiler can teach more than weeks of reading. Exploration is a sufficient goal when the artifact is allowed to remain an experiment.

Production changes the contract. Without a constraint, a baseline, a success measure, and an owner, the experiment has not become a strategy. It has only acquired users.

AI makes the first draft cheaper

Kailash’s Rust prototype matters because it sharpens the tension. An engineer who understands the problem can now ask an LLM for scaffolding, tests, unfamiliar syntax, and candidate implementations. Work that once took days can sometimes appear in hours.

This is good. More people can study systems by building them. Small teams can test an architecture before a quarterly planning cycle would have approved the experiment. An idea can reach a benchmark sooner and fail sooner.

But cheaper implementation changes only one part of the equation. Generated code does not establish that a production constraint exists. A convincing local benchmark does not migrate customer data, preserve every odd compatibility promise, respond to a security advisory, or explain a failure at 2 AM. AI can help with all of that work. It does not make the work disappear.

The gap between an artifact and a system is time.

A prototype has to work for its author today. A production system has to work for other engineers, under hostile inputs, during migrations, after dependencies change, and when the original author is unavailable. The code may have become cheaper before the meeting ends. Its lifecycle has not.

The ability to build is becoming less scarce. The judgement to decide what deserves to exist in production is not.

That judgement may still lead to a new queue, database, runtime, or proxy. Cloudflare and Zerodha show that clearly. It should lead there with more evidence than excitement, because AI has made excitement unusually easy to turn into code.

Somebody still has to stay

Open source supplies one more option when an upstream project no longer fits: leave with the code. Redis’s 2024 licensing change led former contributors and companies to create Valkey from Redis 7.2.4 under the Linux Foundation. OpenSearch followed an earlier licensing change at Elastic. In both cases, permission to fork made an exit possible.

Permission was the beginning, not the rescue. People had to accept release engineering, vulnerability handling, compatibility, governance, documentation, and the question of who would care five years later. Freedom arrives with a pager.

The same obligation exists for a private replacement. The people who approve version one are rarely the only people who will carry version six. Ownership outlives the benchmark and often outlives the reason the first team was excited.

This is where Zerodha’s FLOSS fund becomes more than a donation headline. Its 2025 report says the full $1 million was allocated across projects including OpenSSL, FFmpeg, Blender, and OpenStreetMap. Not all are direct brokerage dependencies. The fund recognises that useful inheritance reaches beyond one company’s dependency file, and that maintainers must be able to stay too.

Companies can return different things: patches, production evidence, documentation, maintainer time, money, or honest accounts of failure. A small startup cannot carry the same obligation as a profitable company whose revenue depends on a project. Responsibility should be proportional to dependence and capacity.

Building is not the opposite of inheritance. Pingora, YJIT, Tasqueue, Valkey, and OpenSearch all began from systems and constraints that already existed. Their teams kept what worked, changed what did not, and then carried the result beyond version one.

I began with admiration for the engineer who can build almost anything. That admiration remains, but it has moved one level up: to the team that can build and still waits for evidence.

Build when the need arises. Until then, inherit what works.