We have one office. Eight people. And, as of this year, paying customers in fourteen countries. On paper that ratio shouldn't work, and for a lot of businesses it wouldn't. It works for us for a specific reason that has very little to do with ambition and a lot to do with what we decided not to build.
The math that shouldn't work
If you'd told me in 2024 we'd be supporting businesses across fourteen countries with a team you could fit around two large tables, I'd have assumed we were planning a string of regional offices to make that possible. We never opened one. We've never stood up a satellite team anywhere. The country count grew; the office count stayed at one.
The reason the math works is that the product, not the team, is what's actually present in all fourteen countries. AIVA answers a call in Manila or handles a chat in Toronto without anyone in Rajkot doing anything differently for it, because the thing our customers are buying — instant, accurate coverage at any hour — was never going to scale by adding people in more time zones. It scales by the product not needing a person on our side in real time at all.
What actually makes it possible
We invested early in running inference from multiple regions — infrastructure, not headcount — specifically so a customer in Europe or North America gets a response that feels local in speed, even though the team that built it is nine and a half hours ahead of them on an ordinary Tuesday. That was a deliberate, unglamorous engineering call, made so a small team wouldn't have to become a large, distributed one just to serve customers who weren't in India. Rohan's written about the actual mechanics of that decision — from where I sit, the relevant part is simpler: it's the reason fourteen countries didn't force fourteen time zones of staffing on us.
Our customers get coverage around the clock. We don't run a team around the clock. Those two facts only coexist because of where we chose to put the engineering effort instead.
What doesn't scale this way, and I'd rather say so than pretend otherwise
I want to push back a little on my own framing here, because it would be easy to make this sound like a trick that solves everything, and it doesn't. Latency and coverage scale beautifully with the product-not-headcount approach. A few other things don't, and we've had to be honest with ourselves about which is which.
Account depth is one. A customer running a single clinic in Rajkot and a customer running a multi-location operation across three countries both get the same responsive product, but the second one often wants a level of ongoing account attention — someone who understands their specific rollout, their specific edge cases — that scales with relationship, not infrastructure. We can't automate that part away, and we haven't tried to. Language nuance is another: supporting a language well is a genuine, ongoing engineering and content investment per language, not a one-time unlock, so "fourteen countries" doesn't mean instantly excellent support in every language spoken in those fourteen countries — it means we've been deliberate about which ones we've gone deep on first.
Where the small-team reality still shows
I don't want to oversell this. When something genuinely breaks — not a customer's caller having a confusing conversation, but our own systems having an actual problem — the people who fix it are asleep in Rajkot, in Indian time, regardless of what time zone the affected customer is in. We carry an on-call rotation for exactly this reason, and it's earned its keep more than once. But a rotation across eight people is still eight people, and there are hours where the honest answer to "how fast can someone look at this" is slower than a company with follow-the-sun staff across three regions would give you.
We say this upfront to larger customers evaluating us, especially ones used to enterprise vendors with regional support desks. I'd rather lose that comparison honestly than have the gap surface for the first time during an actual incident. It's the same instinct behind staying at eight people rather than growing headcount ahead of proof elsewhere in the business — say the limitation out loud before someone discovers it the hard way.
Why a stable team matters more than a big one, for this specific problem
There's a quieter reason eight people can hold fourteen countries together, and it's not really about the infrastructure at all. It's that the eight people aren't new. Institutional memory turns out to matter more for this kind of spread than headcount does — knowing why a specific regional routing decision was made two years ago, or which language's edge cases still need a human eye, isn't something you can staff your way around with fresh hires. It has to live in people who've been here long enough to have made the earlier mistakes themselves. Average tenure on the team runs well above the industry norm, and I don't think that's a coincidence next to the country count. A team that turned over every year would be relearning the same regional lessons on a loop instead of building on them, no matter how good the underlying infrastructure was.
The one exception we did make
There's exactly one place where we let geography bend the team instead of the product: our customer success lead works remotely from Bengaluru rather than from the Rajkot office, specifically because that role needs to be closer to a cluster of our larger customers and the travel connections that come with them. We've written about that decision in more detail elsewhere — it's the one role where the job's actual requirements outweighed our usual preference for hiring and working from Rajkot. Every other role on the team still sits in the same office, which is part of why hiring the way we do has stayed workable even as the country count climbed.
What I'd tell someone trying to copy this
Don't try to be present everywhere. Try to build something that doesn't require you to be. Those sound similar, and they're not — one is a staffing problem that eventually crushes a small team, and the other is a product decision you make once and keep benefiting from for years afterward. We chose the second version mostly because we couldn't afford the first. It turned out to be the better choice regardless of budget.
I'd add one more piece of advice, mostly for founders in our position who assume the answer is to raise money and hire faster the moment international demand shows up: check whether the actual bottleneck is presence or capability first. We assumed, before we tested it, that going international would require people on the ground somewhere. It didn't, because the thing customers needed from us in each new country was a fast, correct answer at any hour — not a local face. That's not true of every business. It happened to be true of ours, and it's worth actually checking before you assume it isn't true of yours, because the cost of assuming wrong runs in exactly one expensive direction — hiring ahead of a need that infrastructure could have solved instead.
If you're evaluating us from one of those fourteen countries and wondering whether "small team, wide coverage" actually holds up on a real call rather than just in an essay, the fastest way to find out is to test it directly rather than take our word for either the strengths or the limits we've just laid out.