Stop Building Chat. It's a Trap.
There's a moment in every product team's life. The roadmap's open, someone's had too much coffee, and from across the table come those five fateful words:
"What if we added chat?"
The room nods. It feels obvious. It feels modern. Nobody asks why. Nobody does the math. The ticket gets created, the estimate gets wildly undershot, and six months later a senior dev is debugging why messages arrive out of order for users in Southeast Asia at 2am.
This post is an intervention.
Chat Looks Simple. Chat Is Not Simple.
The cruel trick of chat is that the demo takes about four hours. WebSockets, a text input, a message list—boom, you're basically WhatsApp. Ship it.
Then your first real user shows up.
Suddenly you need:
Message delivery guarantees: Did it actually arrive, or did the socket drop silently? Now you're building acknowledgment logic, handling retries, preventing duplicates. Users don't love getting "hey are you free?" four times.
Message ordering: Two users send messages simultaneously. Whose arrives first? Distributed clocks disagree more than you'd expect. Congratulations, you've stumbled into vector clocks and Lamport timestamps, and you did not pack for this trip.
Presence state: "Is this person online?" sounds like one database column. It's actually distributed state synchronisation that has made grown engineers weep.
Read receipts: Those two checkmarks? Each one is a fan-out write to every conversation participant. At scale, this gets spicy fast.
Notifications: Push, email fallbacks, in-app badges, do-not-disturb windows, per-conversation preferences. This is its own product.
Message history: How far back do you store? How do you paginate efficiently? What happens when someone scrolls through 50,000 messages? Your database will have opinions.
Moderation: Someone will say something terrible. What's your plan? Who sees flagged messages? Can you delete from all clients simultaneously? Can you audit it?
Attachments: "Can we send files?" Cool, now you've also built file storage, media preview, and malware scanning. Congrats.
The admin dashboard nobody warned you about: The moment chat exists, management wants to see it. Who's messaging whom? Can we flag conversations? Pull reports? Suspend users mid-chat? What started as a feature request just spawned an entirely separate internal tool. That's two products for the price of one sprint estimate.
And this is before the product complexity: group chats, threads, reactions, editing, search, slash commands, bots.
The iceberg doesn't even show you its bottom.
It's Literally One Google Search Away
Here's what stings: this isn't obscure knowledge. You don't need three chat systems under your belt to know what you're walking into. Just type "chat application architecture diagram" or "WebSocket client vs server architecture" into a search bar and spend fifteen minutes reading.
The tradeoffs are documented. The war stories are public. Engineers have been writing about WebSocket pitfalls, message ordering nightmares, and presence system complexity for years. Stack Overflow threads, engineering blogs from Slack, Discord, Telegram—all out there, all findable in under a minute.
Yet somehow, leads will sit in planning meetings, confidently wave away engineering concerns, and greenlight chat with a two-week estimate without doing that one search. Not because they're malicious. Because the decision felt obvious, and obvious decisions don't feel like they need research.
This frustrates engineers most: the hard problems were completely avoidable with minimal due diligence. When you raise concerns and get "I think you're overcomplicating it" from someone who's never implemented fan-out writes at 3am, something inside you dies.
So if you're a lead: before greenlighting real-time features, spend fifteen minutes googling. Not to become an expert. Just to respect what you're asking your team to build. Your engineers will notice.
Why Teams Default to Chat Anyway
"Our competitors have it." Your competitors also have years of infrastructure investment, dedicated teams, and scar tissue from when it broke. You have a sprint and a prayer.
"Users expect it." Sometimes true. Usually a projection. Have you asked users? Or did you assume they'd want it because you use Slack?
"It'll increase engagement." It will increase something, yes. Mostly support tickets and infrastructure costs.
"It can't be that hard." Reader, it was that hard.
What You Probably Actually Need
Underneath every "let's add chat" request is a real product problem. The question is whether chat actually solves it.
Customer support? You don't need to build this. Intercom, Crisp, Zendesk, Freshchat exist. Integrate one in a day and ship literally anything else.
Async team collaboration? Unless communication tooling is your product, you're about to build a worse Slack inside your app. Users already have Slack open.
Real-time multiplayer or collaboration? (Think Google Docs-style, or games) This is one of the few cases where building real-time infrastructure is genuinely core. Go for it, but allocate real engineering time.
Notifications or status updates? You almost certainly want a notification feed, not chat. Much simpler data model, no two-way communication complexity, still feels interactive.
The Three Questions Worth Asking First
Before writing a single line of WebSocket code:
What specific behaviour changes for users who have chat vs. those who don't? If you can't answer with a concrete user story, you don't have a product reason. You have a feature hunch.
What's the cheapest non-chat solution? Could an email thread solve it? A comment section? A shared document? A third-party embed? If something simpler solves 80% of the problem, that's probably the right call.
Can your product survive chat being broken for 24 hours? If chat becomes core infrastructure and it goes down, what's the blast radius? Real-time systems fail in ways batch systems don't.
When You Should Build Chat
Some teams absolutely should build chat. If real-time communication is your core value prop, if users come because of messaging, then yes—invest properly, staff appropriately, and build it right.
But if you're a SaaS tool, a marketplace, or a content platform thinking "chat would be nice to have," the answer is almost always: no, it wouldn't. It would be expensive, distracting, and poorly executed because it's not your core business.
The best chat system is the one you didn't build.
Use the engineering time on something that actually matters to your product. Your future self—and your on-call engineers—will thank you.