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 where your users message each other, see read receipts, and get push notifications when they are 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 being a separate app your users have to switch to. It covers direct messages between two users, group threads for several, the real-time delivery that makes a message appear without a refresh, and the supporting features, read receipts, typing indicators, push notifications, that make a chat feel alive rather than like a slow form.
When you need it (and when you do not)
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, and routing that conversation out to WhatsApp or email loses context and control. A marketplace where buyers message sellers, a coaching or service platform where clients talk to providers, or a community product where direct messages are a stated feature all justify a real build.
You do not need this if your product’s “messaging” is really a support inbox, a single conversation between a user and your team, not between users, which is a simpler and 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 and your users do not care where the infrastructure lives.
How we build it
The backend runs on Python/FastAPI or Node/TypeScript, with PostgreSQL storing conversations and message metadata and Redis handling 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, read receipts, typing indicators, media sharing with size and type limits, message search with pagination, come as a baseline. Push notifications fire through APNs and FCM when a user is away from the app, with a clear policy for 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, the same model behind our own secure messenger prototype, so message content is never readable server-side even by us. This is a meaningfully heavier build than standard transit encryption and worth scoping carefully against your actual threat model before committing to it.
What to watch
Real-time connection infrastructure has a cost curve that is easy to underestimate: a WebSocket held open per active user costs more at scale than a typical stateless web request, and 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, but the policy for who gets banned and why is yours to define, and 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.
Related
Pairs with community platform and forum when direct messages sit alongside public discussion, and 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 have built from the cryptography up, see the secure messenger prototype case study and the closed B2B social network case study, which ported the 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 because 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 and are fine with a recurring per-user fee and your message data living in their infrastructure. We build on your own stack when you want to own the data, control the cost curve as you scale, or need a feature, a custom moderation rule, a specific encryption model, those SDKs do not offer.
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, so 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 and 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 is a policy decision we implement to your spec: full deletion, soft deletion with a tombstone message, or retention for a compliance period, whichever your product and your jurisdiction require.