For a custom app that needs chat, how much more does building it yourself cost than buying an off-the-shelf IM service?

For a custom-developed app that needs a chat feature, here is the conclusion first: if chat is only an auxiliary channel such as customer service Q&A or order communication, integrating a third-party IM service is usually more cost-effective; only when chat itself is the core business—such as social relationship chains or transaction matching—or when messages must go into your own business database to participate in risk control and settlement, is self-development more worthwhile. The dividing line is not whether the technology is difficult, but whether chat data needs to enter your core business loop. Based on 2026 project delivery experience, integrating a third-party IM from activation to getting it working typically takes one to two weeks; self-developing a launch-ready basic IM version usually has an experience range of one and a half to three months, with upfront labor investment typically ranging from 80,000 to 200,000 RMB.

1. First break “chat” into four categories so the budget matches the engineering effort

When many people say “add chat,” they may actually mean several very different things: one-on-one customer service chat, group collaboration chat, stranger social chat, and system notifications. These four categories differ greatly in concurrency, message reliability, history storage, and compliance requirements. Only after the type is defined does the later solution comparison become meaningful; otherwise it is easy to budget for one-on-one chat but end up with the engineering scope of group chat.

For example, one-on-one chat between a user and customer service typically peaks at tens to hundreds of concurrent connections, and occasional delayed message resending has little impact; stranger social chat, however, must handle conversation lists, unread counts, offline push, and content moderation, with volume and complexity on a completely different order of magnitude. Even though both are called chat, it is not uncommon for the costs of two projects to differ by several times.

• One-on-one customer service chat: aimed at solving specific problems, with low conversation volume; the focus is message deliverability and agent assignment.
• Group collaboration chat: must handle member changes, message roaming, and read receipts, placing higher demands on server stability.
• Stranger social chat: involves relationship chains, recommendations, risk control, and content moderation, so the proportion of self-development is clearly higher.
• System notifications and in-app messages: essentially one-way messages; most scenarios do not need a full IM solution.

2. This decision is easily underestimated because there are three pieces of invisible work

Chat may look like just adding a page and an input box, but behind it are three pieces of work that are not easily written into a quotation: persistent connections and heartbeats, offline push channels, and message storage and compliance retention. If any one of these is not thought through, after launch you will get feedback such as messages delayed by a few seconds, messages not received when the app is in the background, and chat history disappearing after switching phones—and the rework often exceeds expectations.

The cost structure is also different. The expense for a third-party solution is integration labor plus an annual fee or usage-based billing, while the expense for self-development is one-time development plus long-term server and labor maintenance. Based on delivery experience, the upfront investment in self-developed IM may look controllable, but when first-year servers, bandwidth, push, and operations labor are added together, the typical range is on the same order of magnitude as the third-party annual fee, and for some projects it is even higher.

• Persistent connections: reconnection after disconnection and weak-network compensation on mobile networks are where self-development feedback tends to concentrate.
• Push channels: iOS and various Android vendor channels must be configured separately, which is real cross-platform work.
• Data retention: chat history is user data, so retention periods and export capabilities must be agreed in advance.
• Compliance: content moderation, sensitive words, reporting, and banning processes are unavoidable in social scenarios.

3. Self-development vs. third-party integration: a verifiable comparison across four dimensions

The comparison below is the framework used in real projects to align with business stakeholders. It is not meant to decide which is better, but to let both sides settle the account on the same sheet first. Each dimension should be reduced to a range as much as possible, rather than being brushed aside with “about the same.”

• Launch timeline: third-party IM integration typically takes one to two weeks; a self-developed basic usable version has an experience range of one and a half to three months, including testing and getting push working.
• Upfront investment: third-party mainly involves a few days to two weeks of integration labor; self-development is calculated in person-months, with a typical range of 80,000 to 200,000 RMB, fluctuating depending on feature scope.
• Long-term spending: third-party commonly charges annually or by usage, with an annual fee experience range of a few thousand to tens of thousands of RMB; self-development involves servers, bandwidth, push, and operations labor, accumulating year by year.
• Controllability: self-development offers greater control over the message pipeline, data structures, and risk control rules; third-party is limited by the provider's capabilities and API boundaries, and deep customization often requires extra development.

It is worth noting that among these four dimensions, “controllability” is easily overemphasized. Unless chat data is meant to participate in core business decisions, such as risk scoring or matching ranking, self-development purely for the sake of controllability usually does not offer good value for money.

4. Have the business side answer these five questions first

Rather than debating the technical route, it is better to answer five questions first. If two or more answers are “yes,” the rationale for self-development rises significantly; if they are mostly “no,” integrating a third-party is usually safer, and this is faster than making a decision off the top of your head.

1. Does chat history need to enter your business database and participate in orders, risk control, or settlement?
2. Do you need custom message types, such as order cards, location, or approval flows, integrated with existing systems?
3. Are there clear compliance and data localization requirements that rule out third-party hosting?
4. Could conversation scale exceed tens of thousands of DAU in the short term, making usage-based billing uneconomical?
5. Does the team have someone who can maintain persistent connections, push, and message storage over the long term?

Here is a reverse judgment that is often overlooked: if the team lacks experience in long-term mobile and server-side maintenance, the hidden costs of self-developed IM will surface in the second year. Before delivery, confirming “who will maintain it” is often more important than confirming “how many features there are.”

5. Applicable and non-applicable boundaries

The cases suitable for third-party IM integration are fairly clear: chat is only an auxiliary feature, launch time is tight, the team is small, and the business needs rapid validation. Such projects get better returns by focusing energy on the main business flow. The cases suitable for self-development are equally clear: chat itself is the product core, messages must be strongly tied to business data, or there are hard requirements on data hosting.

The cases that are not suitable for a full IM implementation are also worth spelling out: if you only want users to leave a message, a form plus message notification is enough; if you only send announcements, in-app messages or push are enough; if you only do customer service, many customer service systems already include conversation capabilities, so there is no need to build another chat module. Piling on a chat module just to look feature-complete is usually a waste of budget.

• Worth implementing: chat directly generates transaction or service value, and there are operations staff to follow up continuously.
• Not worth implementing: chat is only a display feature, no one responds after launch, and it actually lowers the overall experience.
• Boundary statement: whether messages enter the core business loop is exactly the line between self-development and third-party integration.

6. Delivery scene: a rework caused by an undefined chat type

A fairly typical set of constraints: the business side verbally said to “add chat,” the budget was estimated based on one-on-one chat, the timeline was only four weeks, and the message fields and assets had not yet been defined. The only approach was to fill in the checklist while developing, and midway it was confirmed that they wanted group chat, read receipts, and message recall; the message module was revised repeatedly, the overall launch was delayed by two to three weeks, and the rework labor exceeded the original estimate by about 30%.

A more reliable approach is to write the message types, conversation limits, and recall time limits into an acceptance checklist during the requirements phase, and then decide which parts to hand to a third party and which to build in-house. Another common pitfall is push: treating self-built persistent connections as a replacement for push leads to obvious message delays after the app goes to the background, and in the end you still have to add vendor channels. The account system is the same: IM accounts usually need to be mapped once to the existing user system, and if the user ID rules are not unified, subsequent synchronization will keep having problems. In projects handled by Xiyue Company, such mapping rules are generally finalized before work begins.

Frequently Asked Questions

If we integrate a third-party IM, where exactly is chat history stored?

The usual practice is to store it on the provider's side, with only an index or conversation ID kept in your business database; if you want full records, you need to confirm before integration whether synchronization back to your side is supported, which is easily overlooked.

Roughly how many people are needed for self-developed IM?

The experience range is one to two backend engineers and one mobile engineer for one and a half to three months; if group chat and content moderation are included, more people are needed, fluctuating depending on feature scope.

What compliance points should usually be noted for chat features?

Social scenarios generally require content moderation, a reporting entry point, and banning capabilities. Check the specific requirements against each app marketplace's rules and official documentation; it is not advisable to wait until just before release to add them.

If we later switch from third-party to self-developed, can historical messages be migrated?

Most providers support exporting historical messages, but the formats are not uniform, so migration often requires writing conversion scripts; the experience range is one to three weeks. During migration, it is not advisable to switch services.

If we only do customer service conversations, is separate custom development necessary?

Usually not. Off-the-shelf customer service systems already include conversations, agents, and statistics; custom development is more cost-effective only when deep integration with your own orders and tickets is needed.

In terms of action, it is recommended to first write three things into one-sentence conclusions: which category chat belongs to, whether messages should enter the business database, and who will maintain it long-term; then decide whether to self-develop or integrate a third party based on that, and reserve a 20% to 30% buffer in budget and timeline against the experience range. If the needs are only customer service and notifications, self-development is usually unnecessary. The above judgments apply to common small and medium-sized business scenarios in 2026; very large-scale social scenarios or scenarios with strong data localization requirements need separate evaluation.