We were each asked to come up with an Idea of a project we would like to build. I have always wondered what the tech behind messaging platforms is like, so for me it was easy. Build a secure messaging platform. After a bit of research, I thought I understood what that meant. After the past three weeks, having built something I'm really proud of, I can tell you that I had no idea what I was getting into. Not in a bad way, but in a way that meant I was bound to learn.
This is the story of how a team of four backend developers built a real-time, end-to-end encrypted messaging platform with WebSocket messaging, media sharing, push notifications, and a functioning encryption layer.
Where We Started
The idea was initially simple; build something like WhatsApp, but with privacy as the foundation. Messages had to be encrypted on the sender's device and decrypted only on the recipient's. So not even our servers could reach the messages.
That last requirement changed everything about how my vision for the system looked. Building a simple CRUD app is relatively easy, REST APIs, maybe a real-time feature here and there. E2EE is a different ball game entirely. It forces you to think about different boundaries, what does the server know? What should it know? And what is off limit?
Before we started actually coding, we spent time on three questions: what were we actually building, what did each piece of the stack need to do, and what were the dependencies between them?
The Tech Stack and Why We Chose It
We landed on Node.js, TypeScript, Express, PostgreSQL, Redis, and Socket.io for the backend.
TypeScript with strict mode was non-negotiable. With four people writing backend code simultaneously as well as working on the frontend, type safety is what keeps everyone honest. Every API response shape, every socket event payload, every database model is fully typed. When a response shape changes the frontend catches it at compile time.
Express.js was a deliberate choice. We considered other choices - briefly, but Express felt like the obvious choice: every developer on the team already knows it - for one. We built a clean middleware stack on top of it — validation, JWT auth, error handling and request logging.
PostgreSQL and Knex because relational data fits our domain. Users, conversations, members, messages — these have clear relationships and constraints. Knex gave us type-safe migrations and query building without the magic of a full ORM. We wrote our migrations in dependency order and never had a schema conflict.
Socket.io with Redis adapter for real-time messaging. Socket.io's room abstraction maps perfectly to chat conversations — a socket joins the conversation room, messages are emitted to the room, everyone in it receives them. The Redis adapter is what allows this to scale: when you have multiple server instances, a message arriving at server A needs to reach a user connected to server B. Redis pub/sub is the channel between them.
BullMQ for offline message delivery. When a recipient is offline, the message queues. A background worker processes the queue and triggers push notifications. Jobs retry automatically with exponential backoff. This is the kind of infrastructure that feels like overkill until the day it saves you.
Firebase for three separate things: Authentication through firebase phone verification. Cloud Messaging handles push notifications. We originally planned to use Firebase Storage for media but switched to Cloudinary midway through because of its built-in transformation pipeline.
The Architecture Decision That Defined Everything
Early in week one we made a decision that shaped everything that followed: the server would store ciphertext and nothing else.
This sounds obvious for an E2EE app but the implications run deep. It means:
- The backend has no business logic that depends on message content
- Encryption and decryption happen entirely on the client
- If our database is breached, the attacker gets encrypted blobs they cannot read
- The server cannot comply with a request to hand over message contents because it genuinely does not have them
We used the Web Crypto API on the frontend — ECDH for key agreement and AES-256-GCM for symmetric encryption. Private keys are stored in IndexedDB as non-extractable CryptoKey objects. So even JavaScript cannot read them back out. They can only be used to perform cryptographic operations.
Here is what that looks like in practice. When a user sends a message:
- The frontend fetches the recipient's public key from the backend
- An ephemeral key pair is generated for this specific message
- ECDH key agreement derives a shared secret using the ephemeral private key and the recipient's public key
- The message is encrypted with AES-256-GCM using that shared secret
- The encrypted blob is sent to the backend
- The backend stores it without reading it
- The recipient's frontend receives the blob, derives the same shared secret from the other side, and decrypts locally
We originally planned to use the Signal Protocol library on both frontend and backend. We ran into a hard wall, which was that libsignal is a Node.js library with native bindings that does not run in the browser. The frontend had to use a different approach. We chose the Web Crypto API — it's built into every modern browser, has no dependencies, and the non-extractable key storage in IndexedDB was more secure than what most apps do.
The 3-Week Sprint
We split the work across four backend developers with clear ownership each week.
Week one was foundation — Express scaffold, TypeScript config, database migrations, Firebase Auth integration, JWT session management, and the encryption key management infrastructure. The primary thing in week one was to get the auth middleware right. Everything else depended on it. We used Firebase Auth for phone number verification and OTP, then exchanged the Firebase ID token for our own internal JWT pair. Fifteen-minute access tokens, thirty-day refresh tokens and silent renewal on 401 responses.
Week two was the core product — Socket.io server with Redis adapter, message routing, message persistence, delivery status tracking, group messaging, media pipeline, and push notifications. This was the hardest week. Getting real-time messaging right requires thinking about state in multiple places simultaneously: the socket connection registry in Redis, the message status in PostgreSQL, the optimistic UI on the frontend, the BullMQ queue for offline delivery. We had moments where all four of us were debugging the same flow from different angles.
Week three was integration. The frontend and backend had been built largely side by side and week three was where we wired them. This is where the choice to use TypeScript paid off most visibly — the type definitions meant most things just worked, and where they didn't the errors were specific, easy to trace and fixable.
What Actually Went Wrong
I want to be honest about the things that did not go smoothly.
The authentication flow this wasn't much of an issue but we most definitely struggled with finalizing and understanding the authentication flow on registration, and how to properly integrate firebase auth into the mix.
The libsignal mismatch cost us a lot of time. We had built the backend key validation assuming the frontend would use Signal Protocol. When we discovered libsignal doesn't run in browsers we had to strip the validation out of the keys routes and rethink the frontend encryption approach. The lesson: validate your stack choices before you build anything on top of them.
Route ordering in Express this one hurt a bit, and genuinely had me thinking I was losing it. In reality, it is a genuinely easy mistake to make and we made it. Parameterised routes like /:id will swallow everything that comes after them if registered in the wrong order. GET /users/level-up must come before GET /users/:id or search is unreachable — Express matches top to bottom and has no way to know that search is not a UUID. We caught this problem during integration and it was quite mind boggling, one of those mistakes I most definitely won't be making again.
What I Would Do Differently
Start with a shared Type contract. A shared type contract would have helped avoid some of the issues we faced while building and integrating the front and backend, as it ensures both sides are always on the same page about how data is sent and received.
Do a dependency audit before starting. Know which tasks are truly parallel and which are blocked.
Proper research on stack choice. This is definitely a hard check for me from now on, even when it feels like you're using the industry standard. It's always best to ensure what you go with aligns perfectly with your goals and works properly with all other tools being used in the project.
What I'm Most Proud Of
Building this in three weeks, with four developers on a project of this complexity, We pushed to see it through and it most definitely wasn't smooth sailing all through but we were able to pull it off.
The Stack in One Place
For anyone who wants the full picture of our full tech stack, this is what it looked like:
Backend: Node.js, TypeScript, Express.js, PostgreSQL, Knex, Redis, Socket.io, BullMQ, Firebase Admin SDK, Cloudinary, Zod, jose, Multer
Frontend: React, TypeScript, Web Crypto API, IndexedDB, Socket.io client, Firebase Auth SDK, Axios
Infrastructure: Redis Cloud, Cloudinary, Firebase (Auth + FCM), PostgreSQL
What's Next
The backend is built to support Android — the API doesn't care whether the client is a browser or a mobile app. React Native is next.
Voice and video calls are Phase 2. WebRTC for peer-to-peer, our signalling server already handles the connection infrastructure.
Full Signal Protocol on the frontend is something I want to revisit. The Web Crypto API approach works and is genuinely secure but Signal's Double Ratchet algorithm provides forward secrecy that our current implementation lacks — if a key is compromised, past messages should remain safe. That's the next cryptographic milestone.
If you're thinking about building something similar, my advice is this: make the hard architectural decisions first. For us, the decision that the server would never read message content was not a negotiable. Everything else followed from it. Start with your constraints, not your components.
The code is messy in places, some corners were cut, and the UI could definitely do with some improvement. But it works, and messages encrypted on one device are being decrypted on another without our server ever knowing what was said.
That's the thing we set out to build. That's the thing we built.
I am a fullstack developer who built the backend architecture (alongside my team) and the frontend for Culver as part of a 3-week mentorship project. These are the repo links, Backend, Frontend.
