Building a CRM for Whatsapp choosing the backend

When I decided to create a WhatsApp CRM, I began researching existing apps from a technical perspective to understand their challenges and how difficult WhatsApp integration would be.

Fortunately, I found a video from the entrepreneurs behind LeadSales platform where they explained the technical challenges they've faced (I'm not sure if they still have these issues).

What caught my attention most was their scalability challenge. In their video, they mentioned handling 70 million messages per month—a considerable volume—and were experiencing scalability problems.

This is where I thought: they're already established with many users, and any entrepreneur would tell you to build an MVP to test the market first, or create a prototype.

However, in this case, they had already done that research for me, validating the market. According to various entrepreneurship books I've read, you either find a "blue ocean" (extremely rare these days) or enter to compete. I chose the latter, only verifying the market wasn't as saturated as others like note-taking apps, personal finance apps, video games, etc.

The first challenge they presented was scaling. Many engineers' natural response is microservices—the trend for the past 10 years. But as I've said before and will continue saying, 99% of cases don't require microservices. In practice, I see many disadvantages which I won't detail here (perhaps in another article).

Ten years ago, I had the opportunity to meet the development team behind Microsoft Orleans, a framework powering Microsoft services like Office 365, Xbox Live, and games like Halo and Gears of War.

For these reasons, I chose a more pragmatic and simple approach to solve the problem.

A modular architecture (Modular Monolith) with Microsoft Orleans is the perfect solution for this scenario.

Let's Talk Tech

Look, when I mention Microsoft Orleans, I'm talking about this cool actor-based framework that makes distributed systems way less painful. Instead of building dozens of separate services that need to talk to each other through complex APIs and message queues, Orleans gives you these things called "virtual actors" that just handle their business automatically across your servers. It's like getting all the scaling benefits without the massive headache.

And this Modular Monolith approach? It's basically having your cake and eating it too. You deploy one application (simple!) but organize it internally into clean, separated modules (organized!). I've seen too many teams jump straight to microservices without realizing what they're signing up for.

The Microservices Trap

I can't tell you how many projects I've seen where teams went full microservices way too early. The data backs this up too. I was reading that something like 60% of microservices projects fail to deliver what they promised. That's insane!

Most devs don't talk about the hidden costs – you end up with separate databases, complicated service discovery, multiple deployment pipelines, inconsistent monitoring... it's a mess unless you really need it.

At my previous company, we spent almost half our time just managing the infrastructure for our "elegant" microservices architecture. We could've built twice as many features with a simpler approach.

That's why I'm betting on Orleans for this WhatsApp CRM. It's how Xbox Live handles millions of concurrent gamers. If it works for them, it'll definitely handle my messaging volume without forcing me to become a Kubernetes expert overnight.

Sometimes the boring solution is the right one. Build a solid, modular system first. You can always break things apart later when you actually have the scaling problems that microservices solve – which, let's be honest, most of us won't have for a long time.