Choosing the right tool to build your chat app


When it comes to building chat for your app, choosing between build and buy is a tricky decision. What if there was a best of both worlds?


An essential feature for all apps

When it comes to customer support, live chat has long been a standard for websites and mobile apps. Chat functionality is now a staple feature for all platforms and industries. From support for marketplace and on-demand services to group and individual channels for gaming and social apps, users want and need tools for communication with your business and with other users. As developers race to keep up with users’ expectations of communication features, they’re also taking advantage of benefits like boost in user engagement and ability to interact with customers directly.

Today, it’s a no-brainer to add the chat feature, but how? Should you build your own chat app from scratch or choose an off-the-shelf API?

It can be a tricky decision which can result in you having to make the choice between committing to a lengthy and costly build, or relinquishing some of the control you need over your database.

But what if there was another way? Let’s take a look at some of the options available, and the repercussions of making those choices.

Setting yourself up for success

Before starting development, you’ll want to create a clear specification with user workflow and some level of mock-up screens. Creating a detailed specification will allow you to have total clarity on what you need.

Chat apps vary drastically depending on whether they are built for groups, community, customer support, or live stream commentary.

The most common uses for in-app chat include:

  • Community building, for interactions among app users
  • Commentary on live streaming or shared events, so that users can enjoy and share commentary in a live room while enjoying a live experience
  • Collaboration, for example, in business applications where people are creating projects together
  • Customer support, either for the app itself, or for the organization associated with the app (for example, a food delivery service that allows users to chat to support about problems with their order)

Once you have a specification, you’ll need to consider additional features which users of your chat will expect.

A comprehensive chat app would include any or all of these different features:

  • Read receipts: an indication of who has read a message.
  • Auto-responders when participants are not available for the chat.
  • Conversion of chat conversations to email records.
  • Control of private and public rooms and different levels of administrator privileges.
  • Rich messages with the ability to add files, images, videos, GIFs and emojis.
  • Typing indicators to know when someone is responding to a message.
  • Presence indicators: so users know when participants are online and offline.
  • Jump to last read item or read cursors, so that each individual can see where they last left off the conversation and catch up easily.
  • Notifications for direct messages, mentions in a chat, etc.
  • Provisioning and permissions to create different levels of users for chat rooms and groups.
  • Push notifications for the app owner to keep conversations going, send out updates, and automate aspects of the conversation.

In order to remain competitive and provide the best user experience, you would need to individually develop each one of these features.

Making chat work for your existing infrastructure

Some teams choose to create their own in-app chat so that they can keep control over their database of customer conversations. User data is also subject to legislative requirements, and while many providers offer solutions to deal with this, nothing is better than having your data somewhere where you are in full control.

Another benefit is being able to implement your own business logic, although without experience, handling the message delivery mechanism can get messy and ultimately slow down the rate of deployment.

The costs of building from scratch

Commitment to and cost of external components

One of the biggest pitfalls to avoid when building your chat app is to underestimate the amount of time and effort it will take. Yes, there are open source libraries you can build on, but then you lose some control of the code. You’ll also need to consider the implications of needing to provide support to your users for a component you might not understand in real life, because you don’t have the benefit of having written it yourself.

Let’s say you have 3-4 full-time salaried programmers available to dedicate to the build. Development could take up to 15 months. Building your own chat application entirely from scratch typically requires the following components:

ComponentRequirementEstimated build time
Elastic infrastructure

Building the backend infrastructure to handle tens of thousands of simultaneous chats.


2 months
Elastic data storage

Chats accumulate a large amount of persistent state data which needs to be hosted. It is possible to do this part fairly quickly, but you will have ongoing cloud hosting costs.


1-4 weeks
Realtime infrastructure

It often comes as a surprise how much time is required to sustain realtime chats on mobile. Because this is somewhat straightforward on web infrastructure, most teams underestimate the complexity of maintaining realtime connections for mobile applications. This requires not just time, but the appropriate expertise.


2 months
Seamlessness and integration

The realtime systems and persistent systems need to work together seamlessly. The complexity of getting these systems to work together can be daunting because of their distributed nature.


2 months
Realtime features

Only after doing all of the infrastructure above, can the team focus on building the app according to those specifications you wrote in the last section. Not only will it take a few months to implement these features, but when it’s your proprietary software you have the ongoing maintenance to be accountable for.


6 months (plus new features as the need arises)
Client state management

Finally, it’s necessary to manage the client state and manage the data consistency and relevance of the data to each client.


2 months

That’s an estimated cost of $500,000, just on people power and before considering any backend service costs and ongoing maintenance.

Total Cost of Ownership

Total Cost of Ownership (TCO) is always a concern when you are building your app features from the ground up. First of all, you’ll have ever-increasing cloud provider costs as your app gains traction and you expand your operations.

Secondly, your development team will need to maintain the code closely. As you already know, there are ongoing security updates and changes to the operating system to take into consideration. Maintenance costs will vary, but any issues or bugs will be your problem, not to mention scalability. Chat is intrinsically designed to increase the usage time of your app, so it’s fair to expect that your user base and needs will grow.

Security updates, added features, and keeping up with developments and changes in the source app are also necessary.

Time to market

Not only does this commitment mean significant resource costs, but accepting the obstruction to your speed to market. In the best case, it takes between a year and 18 months for the average team to build a fully-featured chat app for scaled usage.

Let’s face it: today’s users don’t want to wait 18 seconds, much less 18 months for new features. And if your competition already has built-in chat, you really can’t afford to wait.

The build vs buy dilemma

The attraction of the ready-made style solution for chat is that it is designed to do all of the heavy lifting for you. While this is can be a good way to demonstrate how chat can work for you and your users (especially for quick prototyping), there are some things you’re losing out on:

1. Control over the conversation database

2. Flexibility to use your own business logic

The best of both worlds

So what about a solution which provides a significant foundation for the realtime messaging infrastructure; reducing costs and time commitment for your team, while giving you more flexibility and full ownership of your database?

Using a hosted pub/sub API like Pusher Channels to manage all of your long-lived connections removes one of the most difficult parts of chat development from your build: with a ready-made realtime messaging infrastructure, you could be up and running quickly, saving months of time and serious build costs, and lowering the risk of development.

This best of both worlds option also lets you lean on the experience of a team who are used to handling realtime connections on a daily basis. In the long run, and as you see adoption grow, a reliable infrastructure provider can save you major headaches. The Channels API is designed for simplicity and scalability, and our team has worked with thousands of global developers, from one-person startups to global giants with high throughput proven time and again.

Our extensive experience with channels, distributed databases and channel bus systems sets us apart. You can be confident that your app will run quickly and consistently, with no downtime and lightning-fast messaging for your end users. Pusher is trusted by thousands of developers worldwide, and we have valuable experience helping users to build all of the realtime features their customers need. With our resources, a fully-featured chat can be set up in a matter of days, not months.

Using Channels will also allow you to keep full control of your database, and our end-to-end encryption feature means data payloads aren’t available to Pusher or our infrastructure providers when passing through our systems.

Adding chat to a mobile app doesn’t have to be time-consuming or costly, nor do you have to lose control of your code. To find out more about building live chat with Pusher Channels, check out more resources on the Channels page, or in our docs and tutorials.