The question I get asked most by candidates, and the one journalists ask most predictably, is a version of "so when are you really going to start hiring?" The premise behind the question is that 8 people is a stage a company passes through, not a place it stays. I want to explain why, for us, it's closer to the second thing — not because we lack ambition, but because of what we've watched headcount actually cost, up close, at other companies and occasionally at our own.
The math we didn't expect to like this much
Four million conversations a month, eight people, across fourteen countries. That's roughly half a million conversations per person, which is a slightly absurd number to say out loud, and also the whole point of the product we build. AIVA exists so a business can support far more customer conversations than its headcount would otherwise allow. It would be a strange thing to build that product and not apply the same logic to ourselves. We're not avoiding the effort of scaling operations — we're routing it through the product instead of the org chart. We've written elsewhere about what those four million conversations actually taught us about the customers on the other end of them; the same dataset is, indirectly, most of the evidence for why we haven't needed a bigger team to keep making sense of it.
What more people actually buys, and what it costs
More hires means more parallel work, obviously — that part isn't in dispute. What's less obvious until you've lived it is what comes attached: more coordination overhead — more meetings, more handoffs where context gets lost between the person who understands a customer's problem and the person who ships the fix, more need for someone whose job is managing the people doing the work rather than doing the work. None of that is inherently bad. It's just a cost, and it's a cost that compounds in ways that don't show up on a headcount slide.
I've watched this happen at close range, not just from the outside. A friend who runs a twenty-person team at a funded startup once described her week to me: four hours in status meetings, two of them purely to relay context between two people who'd have had a five-minute conversation directly if the org chart didn't route them through her. That's not a story about a badly run company. It's what happens by default once headcount crosses a threshold where not everyone can plausibly know what everyone else is doing. We're not there yet, and staying small is partly just staying on the near side of that threshold on purpose.
We didn't stay small because we're precious about it. We stayed small because every layer we've watched other companies add put one more person between the decision and the customer it affects.
The honest challenge: is this a story, or a constraint?
I want to take the sharpest version of the skeptical read seriously, because it's the one I'd make if I were reading this from outside. The skeptical version goes: you're bootstrapped, which means every hire has to be funded out of revenue rather than someone else's capital — so of course you've stayed small, and calling it a principle is just a more flattering way to describe a budget constraint you didn't choose.
There's real truth in that, and I don't want to argue it away entirely. Being bootstrapped absolutely means we can't hire the way a company holding the ₹8 crore a VC firm once offered us could. But the part that isn't just a budget story: we came close to a hire we could have afforded, and turned it down anyway, specifically because of what the role would have been rather than what it would have cost. If this were purely about affordability, that's exactly the hire we'd have made — we had the revenue for it. We didn't make it because the role itself would have added the kind of distance we're trying to avoid, not because the number on the offer letter was too high. That's the distinction I'd ask a skeptical reader to sit with: we've said no to hires we could pay for, not just ones we couldn't.
Why 8 specifically works for us
The thing that actually matters isn't the number — it's what the number protects. Every person on our team still does something that keeps them next to a real customer or a real line of code. I still do infrastructure work. Arjun is still on sales calls most weeks. Meera still personally onboards a meaningful share of new customers. Nobody's full-time job is translating between people who talk to customers and people who don't, because we don't have enough layers for that role to exist yet. That groundedness is the actual value. The small headcount is just the mechanism.
What the ninth hire would actually need to do
When we do talk about the next hire seriously, the conversation isn't "what headcount number should we hit." It's a much narrower filter: would this specific person spend most of their week either building something or talking to a customer, or would they mostly spend their week keeping the rest of us informed about each other. The first kind of role has cleared the bar every time we've discussed it. The second kind hasn't yet, and I don't think it will until the coordination cost of staying at 8 genuinely outweighs the cost of adding a layer — a threshold we watch for directly, not one we're guessing at from a growth chart.
Where 8 will have to become something else
I don't think 8 is a permanent number, and I'd rather say that plainly than defend it past the point it makes sense. It's a proxy for a principle — no one becomes purely a manager of managers, no one loses direct contact with customers or the product — and if we ever grow past what 8 people can hold, it'll be because the principle needs more hands, not because a number on a slide expired.
We came close to testing this a few months ago, when workload genuinely justified a coordination-focused hire — someone whose main job would have been keeping the rest of us in sync rather than shipping anything themselves. We talked about it seriously, more than once, across a few weeks. We decided against it and absorbed the coordination cost ourselves instead, mostly because we weren't convinced the role would stay close to customers the way every other role on the team does. We might be wrong about that. We'd rather find out by feeling the strain ourselves than by hiring around it prematurely. It's the same reasoning that shaped how we sequenced our very first hires — we let what a role actually needed decide whether to make it, rather than filling a slot because the org chart suggested one was due.
The trade-off, stated plainly
We move slower than a funded competitor with five times our headcount could move. Roadmap items sit longer than I'd like. We say no to things a bigger team could say yes to. I'm not going to dress that up as secretly an advantage in every case — sometimes it's just a cost. We accept it because the alternative, on the evidence we've seen elsewhere, isn't a faster version of the same company. It's a different company, with more distance between the people making decisions and the customers living with them. We'd rather stay slow and close than fast and far — the same trade-off, really, that shows up in why we hire out of Rajkot instead of a bigger recruiting market even though it costs us time on every search. If a role ever does clear our bar, it'll show up on our careers page — not because we hit a headcount target, but because the work in front of us finally needed a specific person we don't have yet.