Building Bots: native or cross-platform?

blog

Beerud

By Beerud Sheth

Founder & CEO | gupshup.io

April 5, 2016

Messaging apps are the platform now — and bots are the new apps. Developers are starting to build these new messaging bots to solve a wide variety of problems. As they do so, these pioneering developers are faced with multiple choices. One of the most critical choices is which platform(s) to build their bot for (e.g. Telegram, WeChat, Slack, Twitter, Kik, or another)?

Should they build their bots for one messaging platform or multiple platforms? If they’re building for multiple platforms, should they build separate bots for each one (let’s call this the “native” approach), or should they design a common bot they can “write once and run anywhere” (cross-platform)? Developers are having to give serious thought to these choices. This initial decision will have substantial consequences down the road.

The earliest messaging platforms to open up APIs for programmatic interaction have been Telegram, Kik, Slack, Hipchat, Twitter and SMS. Other messaging platforms have either already announced these kinds of APIs or will do so soon.

The messaging space is indeed highly fragmented: There are roughly a dozen messengers with over a 100 million users . Counts vary depending on what you think is a messenger (are Twitter, Instagram, LinkedIn or Pinterest messengers?), but for our purposes any service with a large user base and widely-used messaging features is a messenger.

Most startups — consumer or B2B — find that their target users range across multiple platforms. If bot developers wish to leave no user behind, they have to think seriously about a multi-platform approach. Which immediately leads to the question of building multiple native bots versus a cross-platform bot. In this post, we’ll review the pros and cons of each.

While the bulk of the features are common across messaging platforms, there are many distinctions.Message-rendering capabilities vary across platforms; this can range from an ability to display plain-text messages of any length, to rich media to hyperlinks, to so-called “smart messages”. The bot API’s vary too. For example, Slack’s app directory and bot API’s behave much differently than Telegram’s APIs and Storebot. .

Native Approach

There are many benefits here. Building bots specifically for each platform ensures that the bot can optimize its user experience to the fullest extent enabled by platform API’s. Also, native bots can keep pace with new features periodically launched by each platform. Platforms are also likely to promote bots in their “bot stores” so the platform can leverage the newest features.

However, the native approach imposes several major costs. The development effort of building, upgrading and maintaining multiple bots simultaneously is not only high but it increases continuously. Since each bot has different capabilities and uses different APIs, the developer will require parallel development tracks, perhaps even multiple teams. Release cycles are longer since each new feature has to be developed and tested separately for each bot. Another challenge is that the user experience is fragmented. Different users will experience the same product differently on every platform.

Building bots using cross-platform APIs address many of these challenges — but at the cost of native optimization.

Cross-platform Approach

Cross-platform bots can be written once, and run anywhere that a cross-platform API can support it. Cross-platform bots are easier to build, upgrade, and maintain. They offer a consistent, uniform user experience across different platforms. Cross-platform bots automatically start working on new channels as their API’s are opened up (if the underlying platform takes care to do so) without requiring any extra development work.

The cross-platform API’s insulate a developer from issues related to platform integration and authentication. This frees developers to focus on their core products rather than worrying about platform integrations. However, in ensuring a consistent user experience there may be some compromise on native optimization on individual platforms.

Cross-platform tools have always been around to make lives easy for developers. In the desktop era, Java was created primarily as a cross-platform “write once run anywhere” tool. In the mobile world, Phonegap, Ionic and React Native make it easy for developers to build apps across multiple platforms.The messaging space is very fragmented, far more than either the desktop or mobile spaces were. This new space has more than 12 major messaging platforms — desktop or mobile spaces never included more than 5 (and that’s being generous).

Here is a demo of a cross-platform bot: the pizza ordering bot. This bot was built using the cross-platform API for building bots, developed by my company Gupshup. The same bot can be used via SMS, Twitter, Slack, Telegram etc.

As more messaging platforms expose APIs, as developers build more bots, the balance will inevitably shift towards cross-platform bots. It’s important that bot developers think long-term before diving into bot development.

You may also like

Leave a Reply

Your email address will not be published. Required fields are marked *