All product teams eventually have this conversation. Users want to talk to each other. It is not a new feature request, and it has been brought up repeatedly. Someone suggests building a chat. The engineering lead estimates the scope, the room goes silent and someone defers the item to next quarter.
That cycle repeats itself more than most teams would like to admit. And while the slowness comes off as a resource issue, it’s often something much deeper: a fundamental misunderstanding of what it really costs to build an in-app community from the ground up vs. bringing in one that already exists.
What It Actually Means To “Build It In-House”
Building chat seems so doable, on the surface. A message input, a feed, some user handles. Most engineers can sketch out the basic architecture in an afternoon.
The real problem is everything below that sketch:
- Reliable message delivery in real-time under load
- How to handle connection when users drop off & then back in
- Message history, large scale storage and retrieval
- Push notifications across platforms
- Resources to moderate the space and keep it safe
- A UI that feels native to the brand, not like an imported widget
- Ongoing maintenance while developing the product
Those are projects all on their own. As a group, they signify months of engineering time not being devoted to the core product. And once you build it, someone has to maintain and update it and fix anything that breaks at 2am on a Saturday during a high-traffic event.
The Opportunity Cost that No One Ever Puts on the Spreadsheet
The immediate cost of building chat in-house is clear: engineering hours, infrastructure, QA. The indirect cost is harder to quantify but typically of larger magnitude.
Every sprint focused on chat infra is a sprint not spent on product differentiation/features. In the case of a sports platform, sluggish repairs to the match experience. For a streamer, it could mean harder-to-find content. Eventually the chat feature ships, but the product trails in ways that matter to acquisition.
There’s also the risk of building the wrong thing. Getting the details right on a community product — how moderation scales, what to do when toxicity spikes during peak events, meaningful controls you can give users without breaking their experience — isn’t something that comes about by chance but takes deep and relevant experience. Missing those elements isn’t just a UX problem. It can damage the brand and drive users away from the very tool that was meant to keep them engaged.
What a Ready-Made Layer Actually Gives You
The other approach is not a compromise. A solid community layer that integrates into an existing product gives you the same result — users talking to each other within the app — without having to rebuild from scratch.
The practical differences are significant:
- Weeks rather than months of integration and not touching the core codebase
- Built-in, validated at scale moderation infrastructure
- UI components which can be styled to match the host product
- Updates and new features ship without an app store release
- A team focused 100% on the community layer, not a side responsibility for an already busy engineering squad
For platforms that have a big moment pending — a tournament season, the launch of a product, or a content drop that will lead to spikes in traffic — speed advantage can be decisive. The community layer is live before the moment arrives, not six months later.
Where the Decision Typically Goes Awry
Building in-house is often not the right thing to do but most teams end up building in-house because the decision is taken by the wrong people at the wrong time. Engineering estimates the build cost. No one factors in the cost of ongoing maintenance. No one considers what features will go unbuilt while chat gets built. And no one asks whether it would have been half the time with an off-the-shelf solution.
The honest accounting is not, “What does it cost to build chat,” but, rather, “What’s the total cost of owning chat over the next three years and what are we trading off in order to do it.”
That calculation is pretty unambiguous for most digital products.