Building dev tools from Pune: distributed teams, timezone math

I run the Pune side of tailtest. My co-founder Nikhil runs the California and Texas side. Our engineering team is spread across Pune, Bangalore, Hyderabad, and a couple of US time zones. We are building a developer tools company. The headquarters question, on a form, gets answered as “distributed.” The honest version is “Pune is where the work happens; California is where the calls happen.” This post is the honest version.

I want to write about it because the question I get most often from founders in India, from engineers thinking about joining us, from people on LinkedIn asking how the org actually works, is some version of “how do you build dev tools India out of India when the customers are mostly elsewhere.” The answer is not “remote work is easy now.” The answer is more interesting than that.

Why we set up the way we did

Tailtest is open source. The customers are everywhere Claude Code is used, which is everywhere. The marketing channels are GitHub stars, Hacker News, dev.to, and the long tail of people who blog about their tooling stack. None of those care where you sit.

What does care where you sit is funding, partnerships, and the kind of high-trust early adopter relationships that get a dev tool from “interesting prototype” to “thing teams actually run in production.” For those, being on Pacific time during US business hours is meaningful. Not necessary, but meaningful enough that we built the team around it.

So Nikhil sits in California. He is the CTO and the US-facing face of the company. Most of the early customer calls go through him. Most of the partnership conversations with companies in the LLM-tooling space happen on his hours. I sit in Pune. I run the operational side, the engineering hiring, the India-side partnerships, the day-to-day of building the team. The engineering work itself happens primarily on Pune hours because that is where most of the engineers are.

This is not unusual for India-led dev tools in 2026. It is what Postman did. It is what Atlan does. It is what Hasura does. The pattern is “US-facing founder, India-engineering reality.” We did not invent it. We picked it because it works.

The timezone math is not actually that bad

The thing American engineering managers seem to assume about distributed India-US teams is that the time zone gap is brutal. It is not. It is structural in a way that, once you accept it, is more workable than the West-Coast-to-East-Coast gap a lot of US-only companies pretend does not exist.

Pune to California is 12.5 hours in the summer, 13.5 in winter (Indian Standard Time does not do daylight saving). When it is 10am in Pune, it is 9:30pm the previous day in San Francisco. When it is 10am in San Francisco, it is 10:30pm in Pune. There is a window of overlap from 8 to 10pm Pune time (8 to 10am SF time, Monday to Thursday) where both sides are awake and can do live work. Two hours a day, four days a week. Eight hours of overlap a week.

That sounds bad. It is not bad if you design for it. The trick is to put all the synchronous work (decisions, alignment, customer calls, hiring loops) in the overlap window, and put all the asynchronous work (writing, coding, designing, reviewing) in the non-overlap time. The asynchronous work then happens on a 12-hour relay, which is faster than a co-located team can move because the work is literally being progressed 24 hours a day.

Tailtest’s daily cycle:

• 9am to 7pm Pune: engineering team writes code, reviews PRs, ships releases. I do operations, hiring, India-side meetings.
• 8pm to 10pm Pune (8am to 10am SF): standup, customer calls, decisions with Nikhil. The two-hour overlap.
• 11am to 7pm SF (after Pune team is asleep): Nikhil does deep customer work, partnership calls, the things that need US presence.
• Repeat.

The handoff pattern is the load-bearing piece. By 7pm Pune time, the engineering team has a clean state to hand to Nikhil. By 8am SF the next morning, Nikhil has reviewed and either approved, pushed back, or escalated. The engineering team starts the next day at 9am Pune already knowing what to act on.

This is not magic. It just requires writing things down. Slack threads. PR descriptions that explain intent. Decisions documented in plans/ files. The cost of writing things down is real and it is what makes the relay work. Teams that try to run distributed without that cost end up with the brutal version of the timezone gap I described above.

The India dev ecosystem is not what it was five years ago

When I started in dev tools in 2017, the India dev tools ecosystem was Postman and a few outsourcing companies. Today it is dozens of companies building serious products: Hasura, Atlan, RudderStack, Refyne, Tessell, Slang Labs, Last9, the list keeps going. Some are unicorns. Most are profitable or close. All of them are run with the same India-engineering-US-customers shape we use.

The thing that has changed is the talent. In 2017, hiring an experienced product engineer in Pune meant competing with Infosys and TCS for someone who would rather work at a startup. The pay gap was real. The career-risk gap was real. Most engineers picked the safer path. By 2026, the Indian dev tools companies pay well enough, ship products visible enough, and have demonstrated enough exits that the calculus has shifted. We can hire engineers who choose us over MAANG India offices because the work is more interesting and the autonomy is higher. The Pune talent pool, specifically, is unusually deep in Python and infrastructure because of the legacy of companies like Persistent, Veritas, and Symantec hiring at scale here for two decades.

The vibe coding wave is hitting India hard. A lot of the engineers we talk to are using Claude Code for their own side projects, which means they understand the tailtest pitch immediately. They have already lived through “I let Claude write this and it broke in a weird way two weeks later.” When you are hiring for a tool that solves a problem the candidate has personally felt, the interviews are short.

What we get wrong about distributed work, that I want to flag

A few honest things.

We over-index on the overlap window. Two hours a day is not enough for high-bandwidth conversations. Nikhil and I sometimes do calls at 11pm Pune / 10:30am SF when something is urgent. That works because it is the two of us and we both signed up for the founder schedule. It does not scale to the engineering team. We try not to ask engineers to take late calls; when we do, it costs us in trust.

Hiring across time zones is harder than building across time zones. The interview loop has to fit in the overlap window. We have offered roles to candidates in three days because we ran the loop concentrated; we have also lost candidates because we could not get the right interviewer available during the window. There is no clean fix.

Documentation drift kills you faster in distributed teams. If the plan file is two weeks stale, the relay breaks. We spend more time on documentation hygiene than any co-located team I know. It is the tax we pay for the leverage.

The cultural-distance gap, specifically between US customer expectations and Indian engineering norms, is real but smaller than people think. Indian engineers in 2026 have grown up reading the same Hacker News threads, watching the same conference talks, and shipping side projects to the same global audiences as engineers in the US. The cultural-distance gap is much smaller than the one in 2010. What remains is mostly communication-style differences, which are real but trainable.

What we have learned about hiring for this shape

A few things, sharper than the platitudes:

We hire for written communication first. The interview includes a written response to a real situation: “here is a Slack thread from one of our engineering channels; what would you write next.” The candidates whose written response is clear and structured succeed in our setup. The candidates who are smart but write hastily struggle, regardless of technical depth.

We hire for ownership orientation, not for breadth. In a co-located team, you can compensate for a junior person’s narrow scope by having a senior person nearby. In a distributed team, you cannot; the senior person is asleep. Junior hires need to be people who will pick up a problem, work on it for six hours without checking in, and either solve it or come back with a clear “here is what I tried, here is what I am stuck on.” Both ends of that loop need to be there.

We try to do at least one in-person week per quarter. The Pune team gets together at our office; we fly Nikhil over at least twice a year. The in-person time is disproportionately useful for the hard conversations (compensation, role changes, conflict). Distributed-by-default does not mean distributed-always.

Why I think more dev tools should be built from India

The economics make sense, the talent is available, and the market is global. The non-obvious piece is the iteration pace. Pune-led teams ship faster than US-led teams I have worked with because the cost of an engineer hour is lower and the autonomy norms are higher. We can run three or four parallel experiments where a US-led team would run one. Most of the experiments do not work. The ones that do compound.

The bottleneck for India-led dev tools is not capability. It is the founder-side discipline of building US-facing distribution and trust. That is harder than building the product. It is what the US co-founder shape solves.

If you are an Indian founder thinking about building a dev tool, my honest advice: do it. Pick a co-founder or partner on US time. Build the product on India time. Spend the first year obsessing over the marketing and trust channels. The product will work. The hard part is being heard.

If you want to work with us

We are hiring engineers in Pune and Bangalore primarily, with some remote roles open across India. The work is open source dev tools, Python and TypeScript, the kind of thing where your commits are visible on GitHub from day one. The team is small (under 15 today) and we want it to stay small for as long as possible.

If you want to read about the technical work before deciding whether the team is interesting to you, hook-based testing explained is the most representative engineering post we have shipped. The R15 adversarial post is the empirical-research post. Both are by team members. Both are the kind of work we want to keep producing.

If you want to try the product, the Claude Code solution page is the place to start. Open source, MIT, no SaaS, no telemetry.

If you have feedback on this post or the company, my LinkedIn is the easiest way to reach me. Pune coffee is on me if you are in town.

Building dev tools from Pune is not a constraint to work around. It is a choice that, in 2026, makes more sense than most of the alternatives. We are going to keep building it this way and see how far it goes.