In-App Chat for Product Teams: What to Ship, What to Skip, What to Buy

Chat is what almost any application needs – it provides support, community building, team collaboration, or customer communication. It can dramatically impact user engagement and retention and can boost conversions by up to 40%. But when you start mapping what features your chat needs, it often becomes a mini-product with its own roadmap.

To stay on schedule, you need to decide upfront what features your chat needs, and not to start this conversation six weeks into the project. Otherwise, it will push everything back by months. 

In this guide, we’ll talk about what to include in v1, what features to ship yourself, and which ones to buy. It will help you make a scoped decision before the sprint starts, not rationalize one after it goes sideways. 

In this article

• What in-app chat actually is 
• When it earns its place – and when it doesn’t 
• 5 verticals where chat moves the metric 
• Feature checklist: v1, v2, v3 
• Build vs buy: the realistic math 
• Mistakes that make chat fail 
• Ethora: modular, BYO LLM, flat pricing

What in-app chat actually is

The simple version: a real-time conversation surface inside your product, not a separate app on the user’s home screen. Users don’t leave WhatsApp or email – they message from within whatever they were already doing.

There are two distinct shapes, and they share infrastructure but have different product priorities:

User-to-user chat is two end users talking inside your platform – buyer and seller on a marketplace, patient and doctor in a telehealth app, classmates in an edtech product, players in a game. The product goals here are trust, conversion, and retention. The engineering risks are moderation and data compliance.

User-to-business chat is a user talking to your team or your AI agent – support, in-product sales, an AI assistant that answers questions about how to use the product. The product goals are resolution speed and deflection rate. The engineering risks are routing logic and the handover between the bot and the human.

Most products eventually want both. The mistake is trying to build both at once in v1. Pick the mode your product actually needs right now.

When In-App Chat Earns Its Place – and When It Doesn’t

Chat only creates value when there’s a real conversation your users need to have and can’t have today through your product. If that conversation doesn’t exist, chat adds complexity and moderation burden without a corresponding business outcome.

It earns its place when trust between two users is the gating step before a transaction – buyers want to ask about conditions before paying, a telehealth app where a quick question can prevent a missed appointment, a freelance platform where scope needs to be agreed before work starts. It earns its place when the ongoing relationship is part of the product value – a coaching app where the coach-client conversation is literally what users are paying for. And it earns its place in engagement-driven products – communities, games, social apps – where the conversation loop is what brings users back.

It does not earn its place when your product is a one-shot transaction with no natural conversation – a utility app, a calculator, a ticket purchase with no question to ask. It also doesn’t earn its place when your team can’t moderate it. Unmoderated user-to-user chat in a product with any audience will produce abuse, harassment, or off-platform leakage within weeks. 

5 Verticals Where In-App Chat Moves the Metric

Before scoping chat, run this one-sentence test: “What conversation do users need to have here that they can’t have today?” If you can’t answer in one sentence – a specific conversation between specific user types for a specific reason – don’t ship it yet. 

Here are the five industries in which chat impacts their performance.

Marketplaces

KPI: Listing-to-transaction conversion rate

Buyer questions before payment are the most common reason listings don’t convert – condition queries, shipping questions, custom variations. Chat closes that gap without routing the buyer to email, where response times collapse. Vinted, OfferUp, Etsy, and Faire all rely on in-app messaging as a core transaction tool. 

The conversion lift from in-app messaging versus external contact has been measured in the range of 15-30% by several marketplace operators (directional, based on publicly reported case studies from OfferUp and Etsy seller community data).

What’s required for it to work: in-thread offer cards, some form of payment-in-chat where regulation allows, and scam/fraud detection. The watch-out is off-platform leakage – the moment two parties have exchanged contact information, they’ll move to WhatsApp. Your chat needs to be easier than WhatsApp for the length of conversation they’re having, which is a product bar many teams may underestimate.

Telehealth 

KPI: Patient adherence rate and async visit volume

The doctor-patient interaction does not end with the 15-minute consultation session. Messaging allows for continuous interaction between consultations without the necessity to schedule consultations for basic questions. Moreover, it improves medication adherence. The most immediate impact from the product side is increased retention since patients who can contact their doctor keep using the service.

It is important to remember that patient-doctor messaging will require full HIPAA compliance. This includes having a signed BAA with all vendors involved in the conversation, end-to-end encrypted messages, encrypted attachments for labs and imaging, and an audit log that is good enough to survive discovery.

Dating

KPI: Match-to-message conversion rate 

On dating platforms, the match-to-message rate is the number that determines whether the product feels alive or empty. Users who match but don’t message churn fast. Keeping the conversation inside the app – rather than watching users immediately ask for Instagram or phone numbers – means your moderation, safety reporting, and image scanning can actually run on the content. That matters because image-based abuse and unsolicited content are consistent problems on every dating product at any scale. 

Required features include image scanning before images become visible, intent classification for escalating patterns, and a blocking and reporting flow that users can access in one tap. Optional but increasingly expected: consent-first features like image hold-back, where a recipient explicitly accepts before an image renders.

EdTech 

KPI: Course completion rate

Learners who can ask questions mid-lesson or in a cohort thread complete courses at meaningfully higher rates than those who can’t. The social accountability of a group chat has a measurable effect on completion – social learning approaches have been associated with completion rate improvements of 25–60% in various eLearning contexts, though results vary significantly by product type and learner population. Instructor 1:1 is the high-value tier; group cohort chat is the scalable version. 

For any product with under-13 users, COPPA and FERPA requirements are not optional additions – they’re prerequisites. Pre-moderation for U13 content, parental dashboards with visibility into conversations, and the ability to disable certain features by age tier all have to be in the design before launch. Schools and districts will ask for documentation before they sign.

Gaming and Community

KPI: day-7 and day-30 retention 

The social loop is the retention loop in games. Players who have friends or clan members in a title return at measurably higher rates than those playing solo. Chat is the infrastructure that makes a relationship real – clan channels, lobby voice, guild coordination, post-match review. For community products more broadly, the conversation is the product; everything else is scaffolding around it. 

The hard part in gaming is moderation. Text toxicity classification is table stakes; voice toxicity is genuinely the harder problem. Real-time voice transcription and classification, slur evasion detection, and COPPA workflows for under-13 titles all need to be in scope before you launch a title with public communication features. Regulators are paying attention to this now in ways they weren’t three years ago.

Feature Checklist: v1, v2, v3

It is quite a common mistake to treat v3 as v1 scope. This table is the scope conversation to have before any sprint starts.

v1 – Ship this first	v2 – After v1 proves retention	v3 – Scale or vertical requirement
1:1 text messaging	Group chat	Voice and video calls
Message history	Threads / replies	Live transcription
Read / delivery receipts	Reactions	AI assistant in chat
Push notifications	Typing and presence indicators	Broadcast channels
Blocklist + report button	File attachments	Real-time translation
Single attachment type (image)	Full-text message search	Advanced moderation (voice, per-channel)
Auth tied to your user system	Multi-device sync	Audit log + compliance reporting
Basic text moderation	Custom message types (offer, booking)	End-to-end encryption where regulated
—	AI text moderation	Multi-tenant if you serve other businesses

Some features like message edit history, reactions, or dark mode may seem important, yet they’re not what should be implemented in the very first version of your chat app. None of these affect whether chat succeeds or fails in your product. 

The E2EE trade-off 

End-to-end encryption is the right call for healthcare, legal, and some fintech contexts. It is the wrong call if you need server-side AI moderation, message search that doesn’t run entirely on-device, or AI features that analyze content to improve the experience. Adding E2EE later is technically possible but requires rearchitecting key management. Decide early based on what your product actually needs.

Build vs Buy: The Realistic Math 

The 3х underestimation of in-house chat build timelines is consistent enough that it’s worth naming directly. Teams consistently scope “add chat” as a 4-6 week project and land at 4-6 months, because the initial estimate covers the happy path and the actual work covers everything else: reconnection on dropped connections, offline message delivery, multi-device sync, push notification routing across APNs and FCM, message persistence that handles ordering under load, moderation hooks, and the operational burden of running the whole thing. 

A realistic in-house build for a production-grade chat backend – sockets, offline queue, push, persistence, search hooks, moderation integration, audit logging – takes 4-9 months with a specialist team. Then add ongoing on-call coverage, scaling work, and feature parity with what the market expects. This is justified when chat is genuinely the core product – when the messaging infrastructure is the differentiator. It is not justified when chat is a feature that exists to close marketplace transactions or extend telehealth visits.

Path	Time to v1	12-month cost (100K MAU)	Ongoing ops
Build in-house	4-9 months	$500K-800K all-in (engineering time)	Full team ownership forever
Per-MAU SDK (Sendbird, Stream)	1-4 weeks	$30K-100K at 100K MAU depending on tier and add-ons	Vendor handles infra; you handle integration
Flat-tier SDK (Ethora)	1-4 weeks	~$2.4K base (flat, not per-MAU)	Self-host or cloud; vendor handles core infra
Open-source self-host	2-6 weeks (for embedded product chat)	$5K-30K in infra + DevOps time	Full ops responsibility on your team

The decision rule that holds up: buy unless chat is your core differentiator. Even if it is, buy the commodity parts – sockets, push delivery, offline queuing, search indexing – and build only the layer that’s unique to your product on top. Nobody has ever won in a marketplace because they built their own WebSocket reconnection logic.

Mistakes That Make In-App Chat Fail

Now let’s consider the most common mistakes teams make when building a chat. Avoid them, and it will save you from wasted time and resources, and costly rework later.

Shipping v2 and v3 scope as v1. Reactions, voice notes, advanced threading, custom emoji – none of these belong in the first launch. They delay the ship date and don’t move the core metric. The v1 hypothesis is whether users will have the conversation inside your product at all. Answer that question first. 

Skipping moderation in v1. The first toxic incident after launch – a hate message, an image-based abuse report, a harassment complaint that surfaces on social media – will consume more engineering and leadership time than building moderation before launch would have. A basic blocklist and report button are not hard to ship. The absence of one when something goes wrong is very hard to explain.

No analytics on the chat feature. If you can’t measure whether chat is moving the KPI you added it for – conversion rate, retention, session depth – you can’t make an informed decision about v2 scope. Instrument chat from day one. Track message send rate, conversation start rate, and the KPI you care about in the same cohort analysis.

Building chat user identity separately from product identity. A chat system where users have a separate ID, separate auth, and a separate profile from your main user system becomes a maintenance nightmare the first time a user changes their username or deletes their account. Tie chat identity to your existing user system on day one. Retrofitting this after launch is a much larger project than doing it right at the start.

Treating push notifications as optional. Push is the re-engagement loop for in-app chat. Without it, users receive a message while away from the app and never see it – the conversation dies, and the retention value of chat disappears. The notification configuration – APNs, FCM, background delivery limits on both platforms – takes time to get right. Don’t leave it for after launch.

Signing a per-MAU contract without modeling scale. Per-MAU pricing looks cheap at 5,000 users and uncomfortable at 50,000. Model 12 months of your projected growth trajectory before committing – not just at current users. The billing surprise at a growth inflection is a painful moment to negotiate a contract change.

Leaving compliance until after launch. HIPAA for healthcare, GDPR for European users, and COPPA for under-13 are critical architectural requirements – they can’t be configured later. The data flow, the encryption model, the audit trail, and the vendor relationships all have to be correct from day one.

Ethora: Modular In-App Chat With BYO LLM and Flat Pricing

The per-MAU pricing problem is the one that brings most teams to a switching conversation around month 18. Chat that was affordable at launch has become one of the top-line items in the infrastructure budget, and the features that would help – AI moderation, advanced analytics, voice – each cost extra. The math that made sense at 10,000 users no longer makes sense at 100,000.

Ethora’s in-app chat SDK is modular and flat-priced – install the modules you need (chat engine, AI bots, video, RAG crawler, marketplace integration), and the monthly cost doesn’t change as MAU grows. Self-hosting is a default feature, and HIPAA- and GDPR-compliance are built-in. If you need an embeddable chat system for an existing web portal, the same stack drops in with a script tag.

Whether you’re building an MVP or a big enterprise project, Ethora has everything you need. If you’d like to learn more about how we can help you, drop us a line.