Company
We Opened a Second Office in Chennai
In the months before we took Codity public, we opened a second engineering office in Chennai and grew the team there. Here is why we picked the city, what the team works on, and how we run two offices as one.
Codity now has a second engineering office, in Chennai.
We opened it quietly, in the run up to our launch, and most of the work that shipped that week came out of a team that had only recently moved into it. This post is the part we did not stop to write down at the time: why we opened a second office at all, why Chennai, and what has actually changed now that we are working out of two.
Why we opened a second office before launching
The honest answer is that the product got bigger than the room it was being built in.
Codity is not one thing. It is a reviewer that indexes a whole repository, a security suite, a persistent architecture map you can ask questions of, and the analytics underneath all of it, running across GitHub, GitLab, Bitbucket and Azure DevOps. Every one of those is a real surface with its own edge cases, and every provider we support is a separate integration with its own idea of what a pull request is.
We could feel the shape of the problem in our own backlog. Work was queueing behind people rather than behind decisions. That is the point where hiring stops being a nice to have and starts being the thing standing between a plan and a shipped feature.
So we made the call to expand ahead of the launch rather than after it. Hiring into a launch is not a strategy we would recommend to anyone who has the choice, but the alternative was launching a product we did not have the hands to support. Given those two, we would make the same call again.
Why Chennai
We looked at a few cities. Chennai won on three things.
The engineering depth is real and it is deep in the right places. Chennai has decades of systems, infrastructure and platform engineering behind it, not just application work. Codity is a static analysis and indexing problem before it is a product problem. We needed people who are comfortable reasoning about parsers, graphs, retrieval and the performance of all three on repositories with a decade of history in them. That profile is not scarce in Chennai.
It is close enough to run as one team. Bangalore and Chennai are a short hop apart, in the same time zone, on the same working calendar. Nobody has to take a call at eleven at night. Someone can get on an early train, spend the day at a whiteboard, and be home that evening. Distributed teams fail on the small stuff, and most of the small stuff here simply does not apply.
People wanted to stay. A good number of the engineers we most wanted to work with were already in Chennai and had no interest in relocating, which is entirely reasonable. Opening an office was the cheaper answer to that than trying to argue with it.
What the Chennai team works on
We did not want a satellite office, and we were quite deliberate about avoiding one. A second site that only gets handed the maintenance work becomes a second class site within about a quarter, and everyone there knows it before you do.
So Chennai owns whole surfaces, end to end.
Provider integrations. Supporting four providers properly is much harder than supporting one and listing three on a roadmap. Webhooks, review threads, merge status checks and permission models are all different in ways that only show up in production. This work lives in Chennai.
Indexing and retrieval performance. The reason Codity reviews against the repository rather than the diff is also the reason we have a hard engineering problem: the index has to be built, kept fresh, and queried fast enough that a review does not hold up a merge. Making that fast on large, old, multi repository codebases is a Chennai workstream.
Security scanning. Secrets, injection and unsafe data handling, authentication gaps, vulnerable dependencies and license compliance, plus the work of explaining each finding as an exploit path instead of a rule ID. More on that in security scans.
The CLI. Everything that runs locally and in CI, including the Claude Code plugin, gets a lot of its attention from this office.
Those are not starter projects. They were picked because they are the surfaces where a bad quarter would hurt us most, which is the only honest signal about how much you trust a new team.
How we keep two offices from becoming two companies
The failure mode with a second site is not distance. It is drift: two groups quietly forming two different opinions about what good looks like, and nobody noticing until the code makes it obvious.
A few things we do about that.
Written decisions over meetings. If a decision only exists in a conversation, it exists in one office. Design notes get written down and argued with in text, which is slower on the day and much faster over a quarter.
We review each other's code across sites, on purpose. Reviewers are not assigned by location. It is the fastest way to keep one bar rather than two, and it means context spreads as a side effect of work that was going to happen anyway.
We run Codity on Codity. Every pull request in both offices goes through our own reviewer, against our own index. That is partly dogfooding and partly the thing that makes cross site review workable at all: a new engineer in Chennai gets the same repository wide context that someone who has been in the codebase for a year carries in their head. We wrote about why that context matters in AI is writing more code than ever.
Everyone visits. Regularly, not once at onboarding. Whiteboards still beat calls, and the trust that makes a hard code review land in good faith is built in person and spent remotely.
Where to find us
The new office is at 33A, RR Tower 5, Lazer Street, Thiru Vi Ka Industrial Estate, Chennai, Tamil Nadu 600032, under Ekaha Labs Private Limited. It sits alongside our Bangalore office in Indiranagar and our US entity in Delaware.
If you are in Chennai and you work on static analysis, developer tooling, or anything adjacent, we would genuinely like to meet you, whether or not there is a role in it. Write to us at contact@codity.ai.
Thank you
To everyone who joined in Chennai in the middle of a launch, before the office had settled and while the product was changing under them every week: thank you. You shipped surfaces that the rest of the company now depends on, and you did it without the benefit of a quiet quarter to learn in.
If you want to see what the team has been building, the fastest way is to point it at your own repository. The pricing page has the plans, or you can book a demo and we will walk your codebase with you.
We are not here to predict the future of code quality. We are here to build it. Now we are building it from two cities.
