What is in-app messaging / chat?
In-app chat is a real-time messaging system built directly into your product. Users send and receive text messages (and often files, images, or structured cards) without leaving the app. Messages appear instantly, like a WhatsApp or Slack conversation — no page refreshes, no email threads.
It's distinct from a support chat widget (like Intercom or Crisp) that's bolted onto an existing website. In-app chat is a first-class feature of the product itself — it's how your users communicate with each other, or with your team, as part of their core workflow.
Common examples: a marketplace where buyers and sellers message each other, a field service app where office staff communicate with technicians, a telehealth platform where patients message their practitioner.
When does your app need it?
- Your users need to communicate with each other — buyer/seller, patient/provider, worker/manager
- You're replacing email or phone tag with in-context, in-app conversation
- The conversation is part of the transaction — job instructions, approval requests, delivery updates
- You're building a marketplace, platform, or two-sided service
- You want all communication about a project, job, or order to be stored in one place
- Push notifications for new messages are part of the experience
How much does it cost?
Adding in-app messaging typically adds 11–21 hours of development — roughly $2,000–$5,000 AUD.
Lower end: One-to-one text messaging, basic conversation list, unread indicators. Clean and functional.
Higher end: Group conversations, file and image sharing, message search, read receipts, typing indicators, message reactions, and deep integration with your app's data model (e.g. messages linked to a specific job or order).
Some teams use a managed chat service like Stream Chat or Sendbird, which provides much of the infrastructure out of the box. This can reduce build time significantly but adds an ongoing subscription cost (~$500–$1,500/month at scale). For lower-volume apps, building on top of Firebase Realtime Database or Supabase Realtime is cheaper and simpler.
How it's typically built
Real-time messaging requires persistent connections — when a new message arrives, it should appear immediately without the recipient polling the server. This is achieved via WebSockets (a persistent two-way connection between the client and server) or a managed pub/sub service.
A basic chat system stores messages in a database, opens WebSocket connections for active participants, and pushes new messages as they're sent. More sophisticated implementations add message threading, delivery receipts (sent → delivered → read), and push notifications for users who are offline.
For push notifications when the app is in the background, integration with APNs (Apple Push Notification service) and FCM (Firebase Cloud Messaging for Android) is required.
Questions to ask your developer
- Is this build-from-scratch or a managed service? Each is valid — understand the trade-off between build cost and ongoing operational cost.
- How are messages stored and for how long? If messages have a legal or compliance dimension (e.g. financial advice, healthcare), retention policy matters.
- Does it support file and image sharing? If yes, those files need to be stored somewhere — typically S3 or equivalent — and served securely.
- How do push notifications work when the app is in the background? This is separate from in-app display and requires its own setup.
- How does it scale? 10 concurrent users is trivial. 10,000 is a different architecture — understand what the solution handles and when it would need revisiting.
See also: Push notifications · Video calling · App cost calculator