Smaller, sharper, and more automated turned out to beat bigger and busier.
A few years ago, we were a company of twenty-something people plus outside help. Today, the core team is a handful — three or four of us doing the work that matters most. On paper that sounds like a story of decline, the kind of thing companies bury in a vague update. I'd rather tell the honest version, because the truth is more interesting: we ship more software, more reliably, than we did at three times the size. And we've come to see small not as a scar, but as a feature.
I won't pretend the shrinking was all strategy. Some of it was the reality every small company in this region knows — markets shift, plans change, and you adapt or you don't survive. But what we did with that constraint is the part I'm proud of, and it's the part worth writing about. We didn't try to do the same things with fewer people and burn out. We changed what the work was.
What actually changed
Two things, mostly. First, we got ruthless about what genuinely requires a human. Second, we automated nearly everything that doesn't. The work that remains is concentrated in a few senior people who hold the whole system in their heads — and an ops layer of AI agents that handles the repetitive operational work that used to need a whole team.
- A small number of senior architects who carry the full picture, end to end.
- AI agents running the repetitive operational work, start to finish, with an audit trail.
- Dedicated people exactly where it counts most — support and onboarding.
- Designers and specialists brought in for specific work, not kept idle between projects.
- A deep bias toward deleting work rather than hiring someone to absorb it.
Why small turned out to be an advantage
Here's what surprised us. A small, senior team makes decisions in minutes that used to take meetings. There's less to coordinate, less to misunderstand in a handoff, and a much shorter line between a customer's problem and the person who can actually fix it. When you email us, you reach someone who builds the product. When something breaks, the loop from report to fix is short because there's no layer of translation in between.
The automation does the volume; the people do the judgement. That combination is genuinely faster than the bigger version of us ever was. We're not nostalgic for the days of more headcount and more process — we were slower then, even though we felt busier. Busy and effective are not the same thing, and the gap between them is where a lot of companies quietly waste their best years.
“We don't ship despite being small. We ship quickly because we are.”
What this means for the people who use Vendor
There's a real, tangible upside for merchants in all of this. The loop from a problem you report to a fix we ship is short, because there are very few people between you and the code. The platform keeps improving quickly because the team isn't drowning in operational overhead. And when you talk to us, you're talking to people who genuinely understand the thing you're using, because they made it.
An honest closing note
I want to be careful not to romanticise being under-resourced — that's a trap, and pretending constraints are gifts is its own kind of dishonesty. What I'm actually saying is narrower and truer: a small, senior, heavily-automated team turned out to be the right shape for building this particular thing, in this particular place. It's the bet the whole company runs on, and so far, it's paying off.
