Building a chat app – Reinventing the wheel?

Should we Build or Buy?

Team-based chat apps are so en vogue right now.

There are numerous established players such as the popular Hipchat, exciting new-comer Slack, the venerable Campfire and the near-ubiquitous Google Chat Hangouts. Why would we build something from scratch rather than purchase one of these excellent services?

Well actually, this organization started with something off-the-shelf. First they used an internal XMPP server that was built into their mail server. It was ok, but became unwieldy as the organization grew, and there never was a particularly great client (like any of the above) available. Additionally there was balkanization: the field reps adopted a mobile app since they were never at a computer anyway, and the IT team adopted something entirely different because of the previously mentioned XMPP client shortcomings.

We chose to build

But the main drivers for Building rather than Buying came down to this:

  • The chat app needed to serve the entire company user-base, which at the time the project started was above 750 people, and growing
  • The chat app should tightly integrate into the enterprise, to minimize IT overhead of account provisioning and to maximize the communication integration
  • This particular organization already had a strong development team and an in-house tool with a very rich API and lots of proprietary, contextual data – none of which could be easily applied to an external service

One of the biggest challenges was dealing with the large population with diverse needs and use-cases. This will be the focus of future articles.

Adopting and Adapting Open Source

After looking at several options, we decided to use Candy as the base for our chat client. Candy is actually an acronym: Chats Are Not Dead Yet. How appropriate. Candy was selected because it has a very active community, a library of plugins, pretty great documentation, and, of course, for being open source. As we have been working on this project, the documentation and the flexibility provided by the plugin system have proven to be incredibly important in the success of reaching the goals we set. It has given us the opportunity to contribute some new plugins to the community, as well as implement our own in-house features easily and cleanly. The maintainers, especially Michael Weibel have been very helpful with getting our changes merged and providing guidance on applying Candy.

So with a good start to the project underway, we’re starting to learn some lessons. More on that soon.

Subscribe to our mailing list

* indicates required
I want to read about...
Email Format

2 thoughts on “Building a chat app – Reinventing the wheel?

  1. Interesting article. I am facing a similar problem right now and it is interesting to see your opinion. Still, I don’t understand why couldn’t you achieve the same 3 goals you stated with a chat app which has a good API: HipChat, for instance.

    • Thanks for your question. You’re right that HipChat provides a nice API, but it wasn’t enough for what we wanted to do. For example, we wanted to create in-line previews whenever someone referenced a CRM object. So if I were to say something like “Customer #1234” it will actually render a thumbnail with information about that customer. Additionally, the customer’s record in the CRM will contain a link back to this chat history, so someone looking at this customer in the future can see the conversation where the mention occurred.

      We also wanted to link the voice+video services into their existing video conference equipment that is installed at the various locations around the country. By using WebRTC and taking advantage of the user’s already established identity, we can enable calling directly between users, or directly between the conference room A/V systems and the web browser.

What do you think?