Building a business entirely on top of someone else's is usually a bad idea
After last week's news on Beeper, the Android app that plans to unify native cross-platform messaging in one single application, that Apple cut their access to iMessage, I reflected on my time at oratio where we built our own WhatsApp Business API years before Facebook/Meta released their official API to give businesses access to WhatsApp.
It was a wonderful exercise to think of new ways to build something people really wanted – a method for businesses to better connect with their customers through messaging.
And we were able to give it to them.
The positive aspect of building your product within an existing eco-system is that you can quickly release it to users and gain momentum. If it addresses a real problem, it can catch on fast, as distribution becomes less of a challenge.
However, the downside is that you end up relinquishing control over many important aspects of your product to the platform operator, who may have their own interests.
In fact, we've recently seen the negative consequences of this when X, the company formerly known as Twitter, made API access so expensive that many third-party developers were forced to shut down.
In my opinion, finding a compromise between tapping into existing eco-systems and maintaining independence is key to building a successful, long-lasting business.
See below the post that first appeared on my LinkedIn profile.
📲 Did you know that in 2015 we built our own WhatsApp Business API?
Last week, Beeper – the company behind Pebble founder Eric Migicovsky - released a native app that would bring Apple iMessage to Android (the famous "blue bubbles"). To achieve this, they reverse engineered the iMessage protocol. Only a few days later, Apple cut access to Beeper.
To me, this does not come as a surprise 😉
I’m closely following the messaging industry and this recent event reminded me of when we built our own WhatsApp Business API years before Facebook/Meta provided one. However, instead of reverse engineering the protocol, we emulated end-user devices.
A few insights:
- We used 100+ virtual Android devices on over a dozen Hetzner servers
- We remote controlled them via QA testing apps and a custom CLI tool
- Virtual phone numbers were not allowed, so we bought a total of 120 physical SIM cards at supermarkets
- It worked extremely well and was at times the most reliable WhatsApp Business API on the market with on average only <2 seconds message delay
- We never got caught by WhatsApp, but with dozens of businesses signing up every week, we had troubles scaling the service
It was an amazing time 🌟
We hacked together this product and worked with partners such as Uber in all of Latin America, Danone in UK & Ireland, Bohoo/Pretty Little Thing in the UK, the United Nations in Switzerland and many more.
However, one of my take-aways is that when you build a product on top of someone else’s product and infrastructure, you eventually give up all of your control.
We learned this the hard way when – to no one's surprise – WhatsApp eventually started working on a Business API which in my opinion is still inferior to what we built ourselves almost nine years ago.
S/O to the former oratio engineering team David Pichsenmeister René Tanczos Piotr Galar