Deep dive
Who actually needs a new messenger?
Consumer messaging is dominated by a few apps with network effects that are very hard to beat. New messengers succeed when they serve a group with needs the big apps do not meet: companies that need data residency, audit and admin control; hospitals and clinics that must keep patient conversations in a compliant system; schools and coaching institutes that need moderated parent and student channels; or communities that want privacy and features tailored to them.
If your goal is to talk to customers who already use WhatsApp, build on the WhatsApp Business Platform instead. A chatbot, broadcast campaigns and a shared team inbox are faster and cheaper than a new app, and customers do not need to install anything. Our guide to the WhatsApp Business API and NexChat cover that route.
How message delivery works
Each device keeps a persistent connection to the messaging server. When you send a message, the app writes it to a local outbox with a unique ID, encrypts it for each recipient device and sends it. The server stores the encrypted payload until the recipient's device acknowledges it, then deletes it. If the recipient is offline, a push notification wakes the app to fetch pending messages.
Receipts travel the same way: delivered when the recipient device stores the message, read when the conversation is opened. Because every message has an ID, retries never create duplicates, and the app can rebuild order from timestamps and sequence numbers even after long offline periods.
- Design the protocol so the server never needs to read message content.
- Keep messages on the server only until delivery, then delete them.
- Test with flaky networks, airplane mode and reinstalls, not just office Wi-Fi.
End-to-end encryption in practice
The Signal Protocol, which WhatsApp and Signal use, combines long-term identity keys, one-time pre-keys and a ratchet that changes keys with every message, so a compromised key does not expose past or future conversations. The open-source libsignal library implements it; your job is integrating it correctly, protecting keys with the platform keystore and giving users a way to verify each other.
Encryption changes other features. Backups must be encrypted with a key the user controls. Search runs on the device, not the server. Moderation cannot scan message content, so abuse detection relies on reports, metadata and behaviour. Multi-device support means each device has its own keys and messages are encrypted separately for each, which is why it sits in the scale tier.
Calls, groups and the growth tier
Voice and video calls use WebRTC. Two devices try to connect directly; when firewalls or carrier networks block that, traffic is relayed through TURN servers, which cost bandwidth. Group calls usually route through a selective forwarding unit such as LiveKit rather than full mesh connections. Native call screens through CallKit on iOS and the Telecom framework on Android make incoming calls feel like phone calls.
Large groups change the economics of encryption, because a message must be encrypted for every member device. Sender keys solve this for groups, at the cost of more complex key distribution when members join or leave. Admin roles, invite links and announcement-only groups round out the growth tier.
Compliance, privacy and running costs
Privacy laws such as the GDPR and India's DPDP Act apply to contact uploads, phone numbers and metadata even when content is encrypted. Ask for consent before contact discovery, hash numbers where possible and keep metadata retention short. Regulated sectors may also need archiving or lawful access processes, which conflict with end-to-end encryption and must be decided up front.
Running costs are modest per user but add up: SMS verification, push services, TURN bandwidth for calls, media storage and the servers holding open connections. Maintenance is typically 15-20% of the build cost per year, and messaging apps need prompt updates whenever Android or iOS change background or notification rules.