How we built a product that grew to 240,000 users and never fell over

A few years ago my team and I built a crypto wallet that lives inside WhatsApp. You send money by typing a sentence into a chat. It grew to 240,000 users.

People usually ask me about the crypto. The more useful story is how a small team kept a product standing while it grew that fast.

Most systems break long before they reach that size. A process that works for 40 people starts to crack at 400. I see the same pattern now in businesses adding AI and automation to their operations. These are the four things that kept ours standing.

1. We built inside something people already used

We did not ask anyone to download an app. The wallet sits in WhatsApp, which our users already opened many times a day.

That decision did two things. It removed the biggest barrier to adoption, because there was nothing new to install or learn. It also removed a huge amount of what could break. We had no app to maintain across thousands of phone models and no login screens to support.

Every new screen, tool or platform you add is one more thing that can fail. So the first question should be where your people already spend their day, and whether you can build there.

2. We limited growth on purpose

When we opened the beta, we capped it at 50,000 users. For a startup that wants big numbers, turning people away feels wrong.

It was the right call. A cap lets you watch how the system behaves under real use while the cost of a mistake is still small. You find the weak points with thousands of users instead of hundreds of thousands.

Businesses rarely do this with automation. They build a new workflow and switch it on for the whole company on a Monday. Run it with one team first, see what goes wrong, fix it, then widen it.

3. We planned for things going wrong

People lose phones. They change numbers. They get locked out of accounts. With money involved, each of those is a crisis for the user.

So recovery was part of the product from the start. A user who lost their device, their WhatsApp account or their phone number could still get their funds back. We also built a way to resolve disputes between users.

None of that shows up in a demo, but it decides whether a system survives real life. When you automate a process, spend as much time on the question "what happens when this fails?" as on the happy path. Decide who gets alerted, who steps in, and how the work continues by hand if it has to.

4. We kept it small enough to explain in one sentence

To send money, a user types "Send", a name and an amount. To ask for money, they type "Request" instead. That is most of the product.

A small surface is easier to keep working. It is easier to test, easier to support and easier for users to trust. Every extra feature we could have added would have brought new ways to fail.

The same goes for internal systems. If your team needs a training course to use a new tool, the tool is too complicated. The best automation I have seen in businesses does one job, and everyone can describe that job in a sentence.

What this means for a business of 40 people

You are not building a wallet for 240,000 users. The rules still apply at your size.

Build inside the tools your team already uses. Start with one team before the whole company. Plan for failure before you switch anything on. Keep each system small enough to explain in a sentence.

When automation projects fail, the technology is rarely the cause. They usually fail because nobody looked at how the business really works before building. That is why we start every project at GWAI Studio with an audit.

If you want to see where your business would hold and where it would crack, get your business X-rayed.