WhatsApp had fewer engineers than your startup
The WhatsApp story gets told as a language story: they used Erlang, Erlang is built for concurrency, therefore a tiny team could serve enormous scale. That is true and it is incomplete in a way that matters if you are trying to learn something from it.
The Erlang part is real
Erlang was built at Ericsson for telephone switches. The requirements there were: handle enormous numbers of simultaneous connections, never go down, and survive individual failures without taking the system with you. Those are precisely the requirements of a messaging service, which is a coincidence WhatsApp exploited to the fullest.
The BEAM virtual machine runs extremely lightweight processes — millions of them — each isolated, each able to crash without damaging its neighbours. Building that on a runtime not designed for it takes considerable engineering. On BEAM it is the default.
The part that gets left out
WhatsApp also did remarkably little. No ads. No games. No timeline. No stickers marketplace. No feed algorithm. For years, not even a web client. The product surface was deliberately, almost aggressively small.
A team stays small partly because of what it builds on and largely because of what it declines to build. Every feature carries permanent maintenance cost, and WhatsApp said no to nearly all of them.
What this means for you
If you adopt Elixir tomorrow because of this story, you get the concurrency model, which is genuinely excellent. You do not get the small team, because your headcount is driven by product surface area, not runtime.
The uncomfortable version of the lesson: if your engineering team feels too large for what you ship, the problem is more likely your roadmap than your stack. That is a harder conversation than a migration, which is probably why the migration gets proposed more often.