27 people, 50 million users: thoughts on scaling efficiently

Last year The New York Times profiled a startup called Gamma (read their blog) that, at the time, had 50 million users supported by 27 people. As of November it had $100m in ARR and 52 employees.

I’ve long been fascinated with companies that scale to exceptional usage with small teams.

Companies like:

• WhatsApp, which had 50 engineers when it was acquired.
• Basecamp (37Signals) which today has just over 150 employees supporting three products, including a secure email product.
• Craigslist, which has been cited as having 40-60 people throughout it’s history.
• Instagram, which had 13 employees when it was acquired.

These companies have something in common. They are B2C in nature: they have low-touch funnels and they can therefore have small go-to-market teams.

But, even if we accept that a B2B company is going to have a larger go-to-market team given the more direct relationship between number of customers and salespeople, there are still examples.

Linear has grown to tens of millions of dollars in revenue supported by tens of employees, including serious and fast-growing enterprises. Notion was similar in the early days too and, even today, has relatively few employees for it’s $600m in ARR.

I do not think there is an agreed-upon reason that some companies can do this and others cannot, but some companies find a way to meet their customers’ needs with small teams for longer than others.

From what I have read and observed, conversations with other founders I have met and, to some degree my own experience, there are a couple of things that stand out about these companies and I’ll break them down below.

It is also interesting to reflect on what opportunities AI is affording a company that has this mindset. I have broken that down as well. But first, there are two big things that I think have an impact from a product and engineering point of view.

At some point, every company that succeeds at a meaningful scale will need to hire more people. Increased usage creates more operational load, more edge cases, more customer needs. The most important thing is that you keep up with your customers.

Ultimately the question is not whether you hire. The question is how complexity scales relative to growth.

Some companies seem able to grow revenue and usage much faster than they grow headcount. Others see headcount rise almost in lockstep with growth.

That ratio is where things get interesting.

Product and Engineering Foundations

Constraints

All of the companies that seem to excel at scaling efficiently are very deliberate about what they and, more importantly, do not build.

We have probably all heard Steve Jobs talking about “saying no”:

Constraints can be found in different ways.

For Basecamp, the idea of “less” itself has always been their strategic positioning. They have sold to SMBs and, as their competitors have added more and more features, they have deliberately and successfully leaned into having less as a key reason you should buy their product.

In general, being opinionated is key to focus. If you have a certain view of the world and are clear about who you are selling to, then you can focus on only building the things those customers value.

Linear is a great example of this. They focus 100% on engineers rather than general task management. It made it much clearer which features will bring huge value and which features they can let go of or wait until much later to develop.

Finding a way to say “no” and to focus is a key aspect of staying small for longer.

Architecture

Making sound architectural decisions early is no doubt a clear prerequisite for scaling further with a small team.

Many of the exceptionally efficient businesses were founded by teams with very experienced engineers who had built scalable systems in previous roles, and in doing so were able to hit the ground running designing architectures that could support huge volumes of users.

This comes down to:

• Choosing the right technologies
• Understanding your SLAs, SLIs, and SLOs and Ensuring that breakpoints do not result in reduced resilience.
• Well-managed change cycles, with configuration-as-code as the default.
• Planning and understanding what would be needed to support a feature if it becomes successful.
• Writing well-crafted code that can be maintained by a small team.

I am not an engineer in my day-to-day anymore and I do think that great architecture is hard to define exactly, but it is one of those things that, when you see it, you know it.

It is worth noting that architecture on its own is not enough.

You can have beautifully designed systems and still end up with a large team if your product surface area keeps expanding. Architecture creates leverage, but leverage only matters if you are disciplined about what you are applying it to.

In other words, good architecture enables scale. It does not replace the need for focus.

Applying this thinking beyond engineering

These are two examples that I think are key from a product and engineering point of view. But there is no doubt that bringing this thinking to other aspects of the business is also important.

One example is investing early in great technical documentation. If you want to grow scalably, this can be as important as, if not more important than, great support. It comes from the mindset of asking, “How can we support customers without human power?”

This is easier to do if you have a clear vision and a confident, opinionated approach.

Another example is running self-serve demos that are still gated behind a form where you collect lead details. I have seen some companies do this with great success.

Naturally, there is a trade-off. You are not necessarily learning from every call you would otherwise have. In this scenario, it only works if you are conscious of those trade-offs and clear about where you already have confidence versus where you still need to build it.

How AI plays into this

Ignoring the hype and focusing solely on the Vero team’s experience using the tools that are already available, it is clear that LLMs have already changed what is possible in the major functions of product, engineering, customer support, customer success, sales and marketing in a software company.

It is my view that this means a small team can go even further in terms of scalability.

Gamma, mentioned at the start, is an example of this. They have had a powerful pull for their AI-driven product, but they themselves have also invested in using AI early.

There are areas, like AI-driven outbound, where something that previously could not be done at near-human quality without scaling humans can now get very close—perhaps 95% of the way there—by just one or two people. This will have flow-on effects for the channel, but it is an example of something that previously could not be done in a scalable way and can now be done much more scalably.

As existentially challenging as it is, this is also an exciting period for software companies.There will be a period where adjustments can be made and value can be captured within your organisation. Perhaps you can build more and sell more to customers without growing your team. Perhaps there are areas of your business that can be made more efficient.

None of us know where “AI” is going so, in the interim, we should make the maximum use of the technology in this period between possibility and the inevitable reality that the market will equalise.

Conclusion

The point of this post is to highlight that there is a mindset certain companies adopt. With that mindset, they find ways to scale further than many of their contemporaries, pushing them into the upper echelon when it comes to efficiency.

This sort of optimisation does not occur by accident. It requires deliberate constraint, strong architectural foundations, and a clear view of the trade-offs being made.

Growth alone does not create this outcome. Intentional design does.