A chat tab that is not a third-party widget:
part of the product, not bolted on
A support widget in the corner of a page is a different product from a real chat system. There, your users message each other, see read receipts, and get push notifications when they're away. We build the second kind, owned by you, not rented from a widget vendor.
What it is
In-app chat is a messaging system that lives inside your product, instead of a separate app your users have to switch to. It covers direct messages between two users, group threads for several, and the real-time delivery that makes a message appear without a refresh. It also covers the supporting features, read receipts, typing indicators, push notifications, that make a chat feel alive rather than like a slow form.
When you need this (and when you don’t)
You need this when conversation between your users, buyer and seller, coach and client, team members, is a core part of what your product does. Routing that conversation out to WhatsApp or email loses context and control. A marketplace where buyers message sellers justifies a real build. So does a coaching or service platform where clients talk to providers, or a community product where direct messages are a stated feature.
You don’t need this if your product’s “messaging” is really a support inbox: a single conversation between a user and your team, not between users. That’s a simpler, different build, see our help desk and ticketing page. You also may not need a custom build if a third-party chat SDK’s pricing and data-residency terms are genuinely fine for your scale. Your users might just not care where the infrastructure lives.
How we build it
The backend runs on Python/FastAPI or Node/TypeScript. PostgreSQL stores conversations and message metadata. Redis handles the WebSocket connection layer and online presence, so the system scales past a single server holding every connection in memory. The client ships on Next.js for web and React Native for mobile, sharing the same message model and real-time connection logic.
Standard features come as a baseline: read receipts, typing indicators, media sharing with size and type limits, message search with pagination. Push notifications fire through APNs and FCM when a user is away from the app. A clear policy decides what gets bundled into one notification versus sent immediately.
For products that need it, we build end-to-end encryption using the Signal Protocol, X3DH for key exchange and the Double Ratchet for forward secrecy. It’s the same model behind our own secure messenger prototype, where message content is never readable server-side, even by us. This is a meaningfully heavier build than standard transit encryption, worth scoping carefully against your actual threat model before committing to it.
What to watch
Real-time connection infrastructure has a cost curve that’s easy to underestimate. A WebSocket held open per active user costs more at scale than a typical stateless web request. The Redis layer that fans out messages across server instances needs capacity planning before a launch, not after it slows down.
End-to-end encryption, if you choose it, closes off some conveniences other products take for granted. Server-side search across message content, for instance, becomes impossible by design, since the server never sees the plaintext. Decide this trade-off deliberately, not by default.
Moderation needs a plan independent of the technology. Block, report, mute and delete are features we build. The policy for who gets banned and why is yours to define. We build the hooks to enforce whatever policy you land on.
Price and timeline
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| Standard chat | from $3,000 | Direct messages, group threads, push, media, read receipts | 4 to 6 weeks |
| End-to-end encrypted | from $7,000 | Signal Protocol encryption, key management, forward secrecy | 6 to 10 weeks |
Running cost is usually $20 to $150 a month in WebSocket and push infrastructure, depending on active user count.
What this pairs with
Pairs with community platform and forum when direct messages sit alongside public discussion. It also pairs with helpdesk and ticketing system when what you actually need is a support inbox rather than peer messaging. See the development service page for full details. For messaging infrastructure we’ve built from the cryptography up, see the secure messenger prototype case study. The closed B2B social network case study ported that same encrypted messaging layer into a broader product.
Need users to talk to each other without leaving your product? Get in touch and we will scope the right level of chat for what you are building.
FAQ
How much does an in-app chat feature cost?
From $3,000 for direct messages and group threads with push notifications and media sharing, integrated into an existing app. A build with end-to-end encryption, like our own Signal Protocol-based messenger prototype, runs $7,000 to $14,000. The cryptography and key management add real engineering time.
Why not just use a chat SDK like Stream or Sendbird?
Those SDKs are a reasonable choice when you want to move fast. You just have to accept a recurring per-user fee, with your message data living in their infrastructure. We build on your own stack when you want to own the data, or control the cost curve as you scale. The same goes when you need a feature those SDKs don't offer, a custom moderation rule or a specific encryption model, say.
Can the chat work across web and mobile?
Yes. The same backend serves a Next.js web client and a React Native mobile app, with the same WebSocket connection model and the same message history. A user can start a conversation on one and continue on the other.
Do we need end-to-end encryption?
Only if the conversations are genuinely sensitive, health, legal, financial, or your users expect it as a trust signal. For most products, encryption in transit (standard TLS) plus access control is sufficient. It's also considerably cheaper to build and maintain than true end-to-end encryption with key management.
What happens to messages if a user deletes their account?
That's a policy decision we implement to your spec. Full deletion, soft deletion with a tombstone message, or retention for a compliance period, whatever your product and your jurisdiction require.