Building a 'customer chat page' software solution

Digital_Guy

I am wondering whether the following would be complex to set up. The idea is basically a chat page for businesses, where any business can set up a page and start interacting with customers / site visitors. Not a chat popup, but an actual URL / page, where the business can link to their own page from anywhere (their website, social media, business cards, flyers, etc).

Anyway, the other aspect to it is that I’d like incoming messages to be directed to the business owner / manager’s phone or WhatsApp, instead of or in addition to the actual chat page. So you could choose whether to only interact via the web app itself, and / or via your phone.

Wondering whether this type of product is complex to implement, or because they are so prevalent maybe it is relatively straightforward once you can pay for the developer time! I am also seeing some open source solutions that could be used.

Any and all advice appreciated. Similar solutions for comparison are frontdoor.im and klets.com.

Thanks

awec

Wouldn't be hard to dev it.

What's the goal? Profit? Unlikely IMO.

Digital_Guy

OSI wrote: »

This part already says you're severely underestimating the level of effort something like this would take to be remotely successful. For something like this to be attractive to customers, it'll require constant software and infrastructure engineering effort. Look at Intercom. They do something very similar to what you're suggesting, but very feature packed. They have a staff of over 100 people and after 5 years still haven't turned a profit.

That's why I am asking this very question - I don't think I am underestimating anything because I don't know what is involved technically I am guessing it would require fairly significant time, but with have the most minimal features, as opposed to Intercom which is all singing, all dancing.

The idea would be to start MVP, then go from there. Again though it's a case of gauging the time required to deliver the specific features in my OP.

Digital_Guy

awec wrote: »

Wouldn't be hard to dev it.

What's the goal? Profit? Unlikely IMO.

That's great to hear...

It would be firmly a side project to start, and self-funded (if that is possible). Start MVP, test with a small number of customers, iterate from there...

Of course I realise that to make a profit I would need the revenue from paying customers to exceed the costs involved in building and maintaining, but again the approach would be MVP and go from there..

Digital_Guy

And if people like the idea / think it's a strong one, then feel free to let me know - all constructive feedback welcome

Talisman

Getting a MVP up and running won't be a problem. Integration with Slack, HipChat, Telegram and Whatsapp could be a accomplished via their APIs.

As a selling point, providing your clients with their own desktop and mobile applications would be no major task if your developer is comfortable with JavaScript/TypeScript and Node.js. Desktop, mobile and web applications could share a large chunk of the code.

The Slack Desktop application is built with Electron. Electron allows you to create cross platform (Linux, OS X, Windows) desktop applications with HTML, CSS and JavaScript.

For mobile devices there are a few frameworks worth considering: Ionic, NativeScript, and React Native. Ionic and NativeScript applications are written using Google's Angular framework. NativeScript and React Native both create native applications so will deliver better performance than Ionic which creates a hybrid mobile application.

The server implementation is where you are most likely to encounter issues, if you were to make some well informed decisions you could potentially get more mileage out of your MVP because scalability costs money.

The WebSocket protocol is the key aspect of the implementation. There are several implementations available to choose from so look for the most performant one. uWebSockets claims to be the best available, WebSocket++ and libwebsockets are also worth looking at. Each concurrent connection to the server comes with a cost because they use RAM and CPU cycles. This means that there is a limit on the amount of connections your server will handle. Throwing more CPUs and RAM at the problem will get you so far. Ultimately you will discover that the server's operating system is the bottleneck and needs to be eliminated.

This is where those that have gone before you have failed, they have built their applications on a legacy of software that wasn't designed to massively scale. Less than ten years ago it wasn't possible to have 10,000 concurrent connections on a stock web server, the problem was solved by removing the limitation present in the operating system kernel. Now it should be possible to build a server that can handle 10,000,000 concurrent connections. The hardware is capable however the software, or specifically the operating system is not. If you solve this issue early in the development of your product, you can grow the business without the pain.

I wouldn't let the fact that Intercom isn't profitable deter you - all that means is that they have made some poor choices. For example, like Twitter they initially built their application on Ruby on Rails - easy to develop a MVP but scalability is a problem. First lesson - stay away from RoR!

In 2015, they discovered the WebSocket protocol and implemented real-time messaging. Up to that point they were posting messages between clients via their RoR application, the solution to the issue existed before Intercom was formed but they had not thought to implement it. To put it in context, WhatsApp was passing real-time messages between over 2 million concurrent clients using a single server in 2011.

Intercom also discovered Docker, Node.js and Golang and adopted them into their stack relatively recently - essentially they have jumped on the bandwagon when there was a buzz about the technologies. For a company that has been reported to dedicate half of it's staff to research and development they have been behind the trend rather than pushing the envelope in terms of the technology stack.

You can draw your own conclusions but to me it suggests they settle for a good enough solution over the best or most efficient - their blog has reinforced this belief.

So if you were to adopt a technology today that Intercom may discover in 2020 or beyond you may win without the need to find over €100M in funding...

OS-less VMs have been a reality for quite a few years now - for example Erlang and Haskell VMs can run on the Xen hypervisor which is the power behind the likes of Amazon and Rackspace. Those stacks can perform like Docker on steroids because there is no OS to contend with.

To get up and running I would use Node.js with uWebSockets and when the money starts to roll in migrate the backend to Erlang.

witnessmenow

Whatsapp have no API you can use.

Take a look at this:
https://integram.org/

It uses something called Telegram, which is a chat client very like whats app.

Everything you want to achieve could be done using a modified version of this.

Code is available here:
https://github.com/requilence/integram/

Digital_Guy

Talisman wrote: »

Getting a MVP up and running won't be a problem. Integration with Slack, HipChat, Telegram and Whatsapp could be a accomplished via their APIs.

As a selling point, providing your clients with their own desktop and mobile applications would be no major task if your developer is comfortable with JavaScript/TypeScript and Node.js. Desktop, mobile and web applications could share a large chunk of the code.

The Slack Desktop application is built with Electron. Electron allows you to create cross platform (Linux, OS X, Windows) desktop applications with HTML, CSS and JavaScript.

For mobile devices there are a few frameworks worth considering: Ionic, NativeScript, and React Native. Ionic and NativeScript applications are written using Google's Angular framework. NativeScript and React Native both create native applications so will deliver better performance than Ionic which creates a hybrid mobile application.

The server implementation is where you are most likely to encounter issues, if you were to make some well informed decisions you could potentially get more mileage out of your MVP because scalability costs money.

The WebSocket protocol is the key aspect of the implementation. There are several implementations available to choose from so look for the most performant one. uWebSockets claims to be the best available, WebSocket++ and libwebsockets are also worth looking at. Each concurrent connection to the server comes with a cost because they use RAM and CPU cycles. This means that there is a limit on the amount of connections your server will handle. Throwing more CPUs and RAM at the problem will get you so far. Ultimately you will discover that the server's operating system is the bottleneck and needs to be eliminated.

This is where those that have gone before you have failed, they have built their applications on a legacy of software that wasn't designed to massively scale. Less than ten years ago it wasn't possible to have 10,000 concurrent connections on a stock web server, the problem was solved by removing the limitation present in the operating system kernel. Now it should be possible to build a server that can handle 10,000,000 concurrent connections. The hardware is capable however the software, or specifically the operating system is not. If you solve this issue early in the development of your product, you can grow the business without the pain.

I wouldn't let the fact that Intercom isn't profitable deter you - all that means is that they have made some poor choices. For example, like Twitter they initially built their application on Ruby on Rails - easy to develop a MVP but scalability is a problem. First lesson - stay away from RoR!

In 2015, they discovered the WebSocket protocol and implemented real-time messaging. Up to that point they were posting messages between clients via their RoR application, the solution to the issue existed before Intercom was formed but they had not thought to implement it. To put it in context, WhatsApp was passing real-time messages between over 2 million concurrent clients using a single server in 2011.

Intercom also discovered Docker, Node.js and Golang and adopted them into their stack relatively recently - essentially they have jumped on the bandwagon when there was a buzz about the technologies. For a company that has been reported to dedicate half of it's staff to research and development they have been behind the trend rather than pushing the envelope in terms of the technology stack.

You can draw your own conclusions but to me it suggests they settle for a good enough solution over the best or most efficient - their blog has reinforced this belief.

So if you were to adopt a technology today that Intercom may discover in 2020 or beyond you may win without the need to find over €100M in funding...

OS-less VMs have been a reality for quite a few years now - for example Erlang and Haskell VMs can run on the Xen hypervisor which is the power behind the likes of Amazon and Rackspace. Those stacks can perform like Docker on steroids because there is no OS to contend with.

To get up and running I would use Node.js with uWebSockets and when the money starts to roll in migrate the backend to Erlang.

Wow, thanks for taking the time to provide all that detail! What Intercom (and Twitter) have done is exactly what you want to avoid - scaling up to a very high level in terms of users (cost), whilst making no money at all.

Not that I am at all familiar with Node.js (although I heard of it), or uWebSockets, but are there many developers globally who would be?

Any idea on prospective costs for an MVP (completely ballpark even?).

Digital_Guy

witnessmenow wrote: »

Whatsapp have no API you can use.

Take a look at this:
https://integram.org/

It uses something called Telegram, which is a chat client very like whats app.

Everything you want to achieve could be done using a modified version of this.

Code is available here:
https://github.com/requilence/integram/

Thanks! However, does that mean it would only work for people with Telegram? The only thing then is, what if Telegram also restrict access to their API at some point.

I think it could still work really well with email / in-chat, and then phone could be an add-on / also included as an option. But email and in-chat could be the primary channels, just like current live chat solutions.

Talisman

witnessmenow wrote: »

Whatsapp have no API you can use.

There isn't an official API but there have been a few unofficial ones developed, one of them was developed by a couple of Facebook's engineers.

Talisman

Digital_Guy wrote: »

Wow, thanks for taking the time to provide all that detail! What Intercom (and Twitter) have done is exactly what you want to avoid - scaling up to a very high level in terms of users (cost), whilst making no money at all.

Not that I am at all familiar with Node.js (although I heard of it), or uWebSockets, but are there many developers globally who would be?

Any idea on prospective costs for an MVP (completely ballpark even?).

uWebSockets is simply a library, it can be used as a drop in replacement for the default WebSockets library. There are a few compatibility issues that can be resolved by implementing some wrapper functions but it's not rocket science.

Implementing a chat client in Node.js is not a difficult task.

As for costs it's a how long is a piece of string question. A sweat shop in Malaysia could build it for €250, an agency in Ireland would easily charge you 50-100 times that. You need to know your requirements and be able to describe in minute detail how the system should work.