How to build a white label chat app
This article aims to provide a list of all the important elements to consider before getting started building a custom app: features, platforms, supporting software, required skills and more. If you’re thinking about or just getting started creating your own private chat app, read on.
Table of contents
Introduction
Checklist
Tools
Yet another private texting app
In 2017, the mobile chat app business is still highly dominated by WhatsApp, Facebook Messenger, QQ Mobile and WeChat. Nevertheless, I do believe there is still room for many more instant messaging apps, either dedicated to niche markets (think Nextdoor), or offering a unique twist to the way people communicate (think SnapChat).
There is a high demand for different instant messaging solutions, which has to do with a big change in our communication culture: today, people want to exchange in the easiest and quickest possible way, but at the same time, they value their privacy and want full control over their data.
This article aims to cover the most important elements to take into account while creating a white label chat app.
What are the most relevant features of my chat app?
In 10 years of working on online and mobile products, I have seen the same mistake being made again and again: a brilliant product idea that seems too thin gets diluted into too many features, resulting in confused end users. The same mistake is even more damaging when building mobile apps; with such a tiny screen to work with, it is absolutely essential to choose a small amount of features for your chat app, and keep a laser focus on them.
The following tables provide a first categorization of features commonly seen in instant messaging apps. You can use them as a starting point to clarify your ideas and identify the most important features for your messaging app. We provide an Excel version of the tables, available for download.
There are 8 main categories listed below. Each category has its own table, made of 2 rows:
- The first row is composed of “feature cells”. Each feature cell shows the possible options associated with the category.
- The second row is for ranking: compare the feature cells and either rank them or select the ones that are the most relevant to you. Some feature cells may not be applicable for your specific business case. In that case, add a “N/A” in the ranking cell.
Ready? Get set, go!
1. Access
Depending on the kind of chat app you’re building, access to its content may require some special permissions. It is important to have a clear idea of who is allowed to get in.
Select the feature cells below that make the most sense for your business case.
| Feature: | Invitation-only | Open access | Admin-verified access |
|---|---|---|---|
| or |
2. Subscription
The first thing your users see once they download your app is the signup form. This is a very delicate part, because it is obviously important to gather some data from the new users, but at the same time, not to freak them out with a lengthy form to fill out.
Rank the following feature cells from 1 being of the utmost importance to 6 being optional or not required at all.
|Feature: |Sign up with email |Sign up with Facebook |Sign up with phone number |Custom sign up fields* |Sign up linked to my own database |Bulk import |
|—|—|—|—|—|—|—|—|
|Rank (1-6) | | | | | | | |
* for niche markets, you may want very specific information upon sign up, e.g., job title, membership number, etc.
3. Notifications
This table shows what kind of notifications can be used to draw users back into your messaging app.
Rank the following feature cells from 1 being of the utmost importance to 5 being optional or not required at all.
|Feature: |Push |Email |SMS |Email digest |Custom triggers* |
|—|—|—|—|—|—|—|
|Rank (1-5) | | | | | | |
* deciding and updating when notifications are sent.
4. Messaging
This table shows what features specific to chat might be required depending on the target audience.
Rank the following feature cells from 1 being of the utmost importance to 5 being optional or not required at all.
|Feature: |Private messages |Group messages |Polls |Chatbot |Levels of publication rights* |
|—|—|—|—|—|—|—|
|Rank (1-5) | | | | | | |
* customizing who can post and moderate content
5. Groups
Most chat apps feature groups, but there are many different ways to configure them, depending on how much control you want to give to your users.
If you need a group messaging option, select the feature cells below that make the most sense for your business case.
|Feature: |Anyone can create groups |Only admins can create groups |Users can view and ask to join a group |Users cannot see groups they are not part of |
|—|—|—|—|—|—|
| or | | | | | |
6. Sharing
Every mobile app builder needs to know which use cases he addresses and provide the features accordingly. For instance, a business chat app will absolutely need document sharing, whereas the best social networking apps cannot do without picture and video sharing.
Rank the following feature cells from 1 being of the utmost importance to 5 being optional or not required at all.
|Feature: |Document sharing |Audio sharing |Picture sharing |Video sharing |Live streaming |
|—|—|—|—|—|—|—|
|Rank (1-5) | | | | | | |
7. Monetization
If the goal of your messaging app is to monetize in some way, even at a later stage, it’s important to know how it’s going to happen beforehand, so that you can lay the right foundations while building your own app. It’s also important to know that any business model involving charging users to use an app or some of its features necessarily imply a cut on all purchases of approximately 30% for Apple and Android.
Select the feature cells below that make the most sense for your business case.
|Feature: |Entirely free |Pay to download |In-app purchases to access content |In-app purchase of unrelated goods* |
|—|—|—|—|—|—|
| or | | | | | |
* for instance, purchasing tickets for an event.
8. Member directory
Creating a mobile chat app often requires to build a directory of all its members. Once again, deciding what is displayed and what should not is entirely depending on the type of app you’re building.
Rank the following feature cells from 1 being of the utmost importance to 5 being optional or not required at all.
|Feature: |Keep anonymity |Users have a profile page |Directory has a search tool |Directory lists only user’s contacts |Directory lists all app members |
|—|—|—|—|—|—|—|
|Rank (1-5) | | | | | | |
Related articles:
On which platform should I build my app?
Choosing between iOS and Android mostly depends on 2 elements:
Your target group, e.g. demographics and geolocalization characteristics.
Several studies performed in the past years have shown that there is a demographic difference between iPhone and Android users. As of 2016, Android had the largest market share, especially in developing countries with relatively lower income (ref. James Vincent, theverge.com). It makes sense, since most Android devices are cheaper than iPhones - although the recent launch of Google Pixel may indicate they’d like to address the higher end too. The platform developed by Google is also more open for developers and businessmen: it’s easier to distribute an app to end users, either through the official Google Play Store, alternative app stores, or even on your own website.
On the other hand, iPhone users are more likely to have a higher income and be younger (ref. Benjamin Travis, comscore.com). They also tend to engage more frequently by, for example, purchasing more products on their phones. If you think about whether you should monetize your app or not, keep in mind that iPhone users, having usually higher incomes, will be willing to spend more on apps and their associated products than Android users.
Your own preferences, namely the devices or programming languages that you are more comfortable with.
If you are a Samsung or Sony fan, opt for Android. But if you love Apple products, iOS is probably best. Trying to create a mobile app for a platform you’re not familiar with is risky, as the 2 operating systems offer very different experiences to their users. You may make choices based on your own experience on one platform that are not adequate for the other platform.
| Android | Apple | |
|---|---|---|
| Market share (2016) | 81.7% | 17.9% |
| Demographics | Developing countries (Russia, Asia, Africa, Central and South America | Developed countries (North America, Western Europe, Australia) |
| User persona | Slightly older, lower income, buys cheaper products | Slightly younger, higher income, buys more expensive products |
| App store release timelines | Google Play Store - releases an app a few hours after submission | Apple store - releases an app 24 to 48 hours after submission |
| Distribution | Many alternatives to Google Play Store | No alternative |
| Native language | Java | Objective-C and Swift |
Related articles:
What about a web app?
Depending on the target audience, offering a web version of an app may push users to remain on it for longer periods of time. If a web version is required, it is very important to take that into account while selecting tools to build your own app, or it may cost you an arm and a leg later on.
An interesting example of such a mobile-first instant messaging app expanding to the web at a later stage is WhatsApp and its WhatsApp Web. Originally only available on mobile phones, WhatsApp launched its web version after 6 long years, in early 2015. Their web version is an extension of the mobile version and only works if your phone is nearby. I can only imagine it took WhatsApp so many years to get there for technical reasons. Hence the need to make sure you plan ahead if you want your app to run on the web too in the long run.
Why a web version? There are several obvious reasons which make this choice worth thinking about for a moment: more comfort for people - like me - sitting in front of their computer the whole day, saving a user’s precious phone battery, and the ability to share documents straight from the hard drive of a computer.
A word about instant apps
Instant apps are a functionality released by Google in June 2017. It allows a user to use a single functionality of an app without having to download the entire app. The goal is obviously to save precious storage space on our devices: only the necessary files are downloaded to use the required functionality, and they are discarded once the user is done with them.
From what I have read so far, if you’re a developer, you need to think ahead of time about how you will modularize your app to fit the “instant app” requirements. One major limitation: instant apps are meant for Android devices only, and only run on Android version 6.0 or higher.
As this just came out, if you’re not a developer, you’ll have to wait a bit of time until app makers and builders out there offer ready-made white label instant apps.
Related articles:
White label to what extent?
From my perspective, a white label app is an app that displays your own brand instead of the one of its original creator. It means that the creator of the app, whether it is an app builder, a freelance developer, or a third party company, waives its rights to claim your app as the result of its hard work. If you look at it the other way around, it means that you, as a client, legally have the right to freely boast about having built this app yourself without any outside help.
Unfortunately, after many years spent in this business, I can tell for sure: there are as many definitions of “white label apps” as there are days in a year. Consequently, it’s important to make sure you and your provider are on the same page when you start building your white label app. First, take some time to evaluate the level of branding you require. You can use the list of questions below to help you. Then, and only then, choose the mobile app builder that can offer you this level of branding.
Use the list of questions below to help you assess the level of branding you need. Additionally, keep an eye on the associated cost chart: the more “yeses” you collect, the more pricey your app becomes. Ultimately, if you want to be the owner of your app’s source code, you need your own a development team and prices skyrocket.
- Do I need my own app name and logo?
- Do I need transactional emails of the app to be sent from my own domain name?
- Do I need my own name as the developer of the app on the app stores?
- Do I need the app to be entirely void of any mention of the app builder?
- Do I need my own terms of use and privacy policy?
- Do I need to own the source code of the app?
I am a developer, what tools can I use to help me build an app?
As a developer, the first question that you need to answer is: should I develop my app in a native or hybrid language? The answer to that question depends on 3 elements: the platforms you are targeting, the number of developers you have working with you, and the programming languages you’re comfortable with.
Developing an app: native or hybrid
If you are targeting a single platform, or if you have a couple of developers working with you, each comfortable with one of the native languages, I would advise you to go for each platform’s own native language, i.e: Java for Android and Objective-C / Swift for iOS. The advantages of opting for the platform’s native language, as opposed to using a hybrid solution, is that your app will run faster on your users’ phones and you will have access to all the facilities Google and Apple provide to help their developers, typically: all the user interface elements of that specific platform.
If you are alone, targeting both Android and iOS, or if it’s very important for you to have a web version of your app too, I would recommend to opt for a hybrid app: the base code is the same for all platforms and the programming languages are none others than the usual suspects: Javascript, HTML and CSS. There are some very well developed and maintained libraries that can help you run your code base on the web, Android, and iOS, just as if you had developed each app individually in its native language. The advantages are numerous: only one code base to maintain, the programming languages are well known by all, and of course, you can target all platforms at once.
App builder tools
There are many excellent libraries out there that can help you build your chat app. Beware and don’t randomly select them though; once you choose one or a couple you like, you’ll have to stick with them in the long run, as it is quite complicated, sometimes impossible, to switch from one solution to another.
Back-end
Firebase is a solution built by Google. They offer several SDKs to make it possible for you to code in the language you’re the most comfortable with, while still targeting all 3 platforms. Firebase is very simple to use and provides many facilities like secure authentication system, analytics dashboard, and a scalable server-side code to handle many users. Unless you’re willing to pay though, you will have to deal with several limitations in terms of number of users, transactions, and storage space. It is also important to note that once you’re hooked with Firebase, it is difficult to switch to another backend, so be ready to stay with them, come rain or shine.
Deployd is a library based on NodeJS and MongoDB that helps you build and run your app API. It implements websockets so that the server can listen to the client changes in real-time, and provides an out-of-the-box Users collection to simplify processes like authentication. The library is open-source and entirely free under the Apache license.
Mixed
DerbyJS is a full-stack JavaScript MVC (Model-View-Controller) framework built on top of several NodeJS modules. It allows you to share the same code across servers and clients. The major advantage of this framework is that you can bind your front-end elements directly with your back-end and database, which makes everything run very quickly. It also means you cannot build an API for third-party users to interact with your back-end. The framework is open-source and completely free, licensed under MIT.
Meteor is an open-source platform somewhat similar to DerbyJS and Deployed, as it mostly provides the same features. One main advantage is that they also offer their own custom hosting and deployment solution, named Galaxy, which will take care of all the devops for you at a decent price.
Sendbird is a solution expressly developed for chat apps. It provides all you need to deploy a messaging system into your app, from the chat API on the back-end, to the chat user interface on the front-end. It also offers several useful tools specific to chat applications, like smart throttling, or read receipts.
Front-End
Cordova is the oldest and de-facto library to build a hybrid app. It provides the much needed black box that bundles and displays your JavaScript/HTML/CSS code on a webview inside a native iOS or Android app. Developed and maintained by Apache, it is open source and completely free. The main advantage of Cordova is that with the same code base, you can develop for all platforms.
Ionic and Ionic2 both are hybrid frameworks that work on top of Cordova. They are purely built to fulfil your front-end needs by providing plugins to bridge the gap between your user interface and the device’s native functionalities (like Bluetooth, Keyboard, Finger Print Auth, etc). Ionic2 is not an update of Ionic, it’s a completely new toolkit based on Angular2 that is more performant and less complex to use than its elder brother. It is however still in alpha, so you may want to opt for Ionic if you need something more robust. For now.
React Native, unlike Cordova and Ionic, uses the native views of each platform: it embeds a JavaScript engine and interprets the code at run-time to control these native elements. The advantages are that each platform renders its own native UI, thus providing the users a more familiar experience on their phone. It als runs faster than an app built on top of Cordova. The main drawback of React Native is that the code base requires some changes for the iOS and Android versions (about 10-20% of the code has to be rewritten for each platform), and it requires a completely different code base on the web. If the web version of your app is important for you, you should rather opt for the Cordova/Ionic option.
There are many more solutions out there, but this list contains the most famous ones and constitutes a good basis for you to get started.
Related articles:
I am not a developer; who can create a white label messaging app for me?
There are many app developers out there offering white label app templates for different purposes without requiring a single line of code from you. Companies with expertise in white label instant messaging solutions however, are not so highly represented. We’ve short-listed 3 complementary chat app builders that each offer amazing white label solutions.
Minsh
Our goal is primarily to help private organizations communicate more efficiently with their members. We’ve been developing white label chat apps for over 5 years and use our strong expertise to provide our clients with a top-notch support. We can deliver a completely white labelled app on iOS, Android and the web within 48 hours for US$ 289 per month and up to 3,000 users.
Features: public chat, private messages, groups, searchable member directory with user profile, push and email notifications, event calendar, all of them customizable to a certain degree, bulk import, etc.
What’s cool? Our prices don’t rely on the number of users; we perform custom developments based on your needs.
Mighty Networks PRO
Their goal is to assist community managers by automatically pushing members of a social network to meet other people with similar interests. The PRO plan offers white label networking apps that include enterprise features like custom integrations and SLAs. Due to the high amount of customization each enterprise app may require, there is no clear pricing range available on their website, but one can infer it must be in the thousands-of-dollars-per-month range.
Features: public chat, private messages, articles, topics, polls, groups, searchable member directory, member profile page, single sign-on, enterprise security, enterprise data integration, uptime SLAs, etc.
What’s cool? Their unique discovery feature helps members to meet each other, thus encouraging more conversations.
Buildfire
Their goal is to provide white label mobile apps that become a source of revenue for their owner in the long run. Their platform offers “app templates” - restaurant app, charity app, corporate app, etc. - that can be customized with individual plugins, e.g., chat, picture gallery, text editor, online ordering, and many more. Their chat plugin is an integration of Smooch Chat. Pricing starts at US$ 59 and increases with the number of users and push notifications.
Features: many plugins available beyond chat
What’s cool? Their online platform allows you to quickly configure your app and test it directly on the web.
Related articles:
Conclusion
There are many elements to keep in mind when building private chat apps. Although it looks like a long journey to finalize who your target segment is, what your exact requirements are, which features you need most, and on which platforms you want to deploy your white label app, you can take comfort in the knowledge that it is very fast, easy and mostly cheap to get started with one of the solutions we present here. Nothing prevents you from testing out different options even if you do not have all the answers yet.