Building a Privacy-First Messaging App with Invite-Only Contacts
BlabBlab is a product I built. I am including it because it shows how I handle real-time features, media, and privacy-sensitive design in a mobile application.
The problem
Most messaging apps build their contact model around your phone's address book. Install the app, hand over your contacts, and anyone holding your number can reach you. That is convenient, and it is also the reason unwanted contact is so easy on those platforms.
I wanted a messenger where being reachable is something you grant rather than something you leak.
What I built
BlabBlab is built around invite-only contacts. You are added by scanning a QR code in person or by accepting a unique invitation link. There is no directory to search and no way to reach someone because you happen to know their number.
On top of that model sits a full messaging feature set: text, group chats, voice and video calling, file and photo sharing, status updates, and shared moments. The goal was that choosing a more private contact model should not mean giving up the features people expect.
Safety features
The app includes an SOS alert that notifies a user's chosen contacts with their current location and a pre-saved message in a single action. Designing this well meant thinking carefully about failure cases: it needs to work quickly, it needs to be hard to trigger accidentally, and it needs to degrade sensibly when location data is unavailable.
There is also a classifieds feature for buying and selling within a trusted group of contacts, which follows the same principle as the rest of the app: the audience is people you have already accepted, not the general public.
Engineering notes
Real-time messaging and calling are the parts of a mobile app that are easy to demo and hard to make reliable. Connection state, message ordering, delivery under poor network conditions, and media handling on constrained devices are all problems that only appear properly once real people use the app on real networks.
Media sharing in particular forces early decisions about compression, upload behaviour on mobile data, and how much to trade quality against speed. Video calling raises the same question again with a much tighter latency budget.
Design decisions worth noting
The invite-only contact model is a deliberate trade-off. It makes growth slower, because there is no address-book import to bootstrap a user's network, and it makes onboarding a two-person action rather than a one-person one. In exchange it removes an entire category of unwanted contact by design rather than by moderation.
That is the kind of decision worth being explicit about with clients: the privacy-preserving option and the growth-optimised option frequently point in opposite directions, and the right answer depends on what the product is actually for.
Stack
- Native mobile application
- Real-time messaging with delivery and presence handling
- Voice and video calling
- Media upload, compression, and file sharing
- Location services for SOS alerts
- QR code and deep-link based contact invitations
Outcome
BlabBlab is live, with messaging, calling, media sharing, and safety features running on an invite-only contact model. The transferable engineering here is real-time infrastructure, mobile media handling, and privacy-sensitive product design, which are the same problems that show up in client apps involving chat, notifications, or location.