Innovators want to bring their ideas to market very quickly. They want to fail fast and iterate, using customer feedback. If their prototype is successful, they need to scale fast too. How can they make this process less risky, especially in a hyper-connected world?
Whether your new business is based on your website or an app, or a Facebook page, your customers expect you to be available 24 x 7 on the channel they prefer: chat, SMS, or video calls. So getting the communications infrastructure up and running in your prototype is critical.
If you execute this the traditional way: you would create a business model, predict future usage patterns and future returns and create a prototype, and build a communications infrastructure to cater to that.
Building the infrastructure to handle a global customer base would be a nightmare. Consider carrier contracts, network protocols, and global regulations. Hardware and software costs. Custom code to add Messaging, Voice, Video, and Authentication capability to your apps and keeping them scalable and up all the time. Building all this on your own is costly and risky. And if predictions go awry you have to start everything over.
Contrast that with a “consume” model for setting up communications: using a ready-made communications platform that handles everything, so you can focus on building your business. You can pay for what you use, and can hook up to it simply via APIs. Your task is limited to coding your website or app.
Such platforms, like Twilio, can help you bypass many hurdles and reach the market very quickly with your idea.
With their APIs, you can send an SMS, make a call or handle a chat from your app or website by writing just a few lines of code. With “pay per use”, you can start small and try out your idea without sinking a fortune into it.
Build vs Consume
Adding video calling capacity in an app with Open Source technology vs with Twilio APIs
Adding Video Capability to an app using WebRTC
Integrating Twilio APIs into a React Native App for adding Video Calls
|WebRTC lets you add real-time communication capabilities to your application that works on top of an open standard.||Twilio allows software developers to programmatically make and receive phone calls, send and receive text messages, and perform other communication functions using its web service APIs.|
|With WebRTC you need to do your own coding for:
– User management, session, connection start and end management
– Notifications management
– Concurrency management/ room management (most important; you have to check for uniqueness of room (chat and video))
– WebRTC chat management is only text, no graphics or video
– Chat storage: WebRTC doesn’t support any storage or chat archive
– Video storage: WebRTC doesn’t support any storage, you will have to write separate code and storage
– Authentication: You have to create your own authentication code.
– Encryption across the boundary: You can use 128- bit only encryption. For anything more than that you need a separate certificate from the US government.
– Infrastructure: You would need your own server as well, with high costs.
– Coding: You need to write your own APIs to get data from the server, etc
You need to set up your own turn server (a must for cross-boundary and long-distance calls)
WebRTC development cost and time taken is very high.
Internally Twilio uses socket IO (or WebRTC) but provides a wrapper for all listed functions for use via its APIs.
Twilio provides you an encryption license even if you want to use more than 128-bit encryption.
We had implemented a Twilio chat for web application successfully and found many advantages.
We plan to implement video capabilities in a React Native app using Twilio and will keep you posted.