The 3 Schools of Thought for Creating a WebRTC App

February 13, 2017

Different people think differently when it comes to creating WebRTC apps (obvious? maybe).

I’ve seen it all. I talk almost daily with different stakeholders in companies that end up adopting WebRTC. A developer here. An enterpreneur there. A product manager. A marketing lady. A PR agency guy who knows shit about what he is promoting. A test engineer. An architect. The sales guy. You name it.

There’s a HUGE discount on my Choosing a WebRTC API Platform report now. And it is valid only until the end of this month. Why not grab your own copy of it?

If you go and ask the average Joe who is doing something with WebRTC how exactly does creating a WebRTC app, you’ll get one of 3 different answers. You see, at the end of the day, our small market can probably be pushed into 3 neat drawers, each representing a different school of thought. 3 different set of values and world views.

These worldviews can be found within the same industry niche, serving the same customer base, using similar business processes and user experiences, and yet each vendor will explain in detail why his way of creating that WebRTC app makes the most sense. And it does. It truely does.

I mostly agree with my buddy Chris Kranky who wrote about build vs buy of WebRTC apps last week. His approach is simple – why invest in your own infrastructure to cut down ridiculously low monthly plans of a CPaaS vendor? I see it as well with those approaching us at testRTC and then running away with cold sweat because they need to pay a 3 digits figure to stress test their product. But I digress.

Back to the schools of thought.

I think it is important to understand your own behavior and that of your team before moving fotward, as this may hinder your decision – or at the very least explain it. What you want to aim at here is to find a good match between your strategy and your team but also between your team and what you are trying to achieve. In many cases, I’ve seen failed attempts and increased risk because the choices made just didn’t make sense with the market realities.

It is similar to my article recently on a development path in WebRTC just looking at it from a slightly different angle.

Let’s see what these alternatives are:

#1 – The Tinkerers

“Look what I found in the Chromium Issue Tracker”

When it comes to WebRTC bugs, Tinkerers know the current bug status in the Chrome Issue Tracker by heart.

They want to build stuff with their own bare hands, sometimes forgoing even open source frameworks and doing things from scratch. Our industry has a few of these and their names are quite known (Fippo anyone?)

If you’ve got a real Tinkerer in your team, then you’re in great luck. There are few of them out there – and even fewer who understand what they talk about and how to make real use of WebRTC.

The main challenge here is that you need to have more than a single Tinkerer. If she leaves to work someplace else – what are you to do then?

There are teams of Tinkerers out there building great products with WebRTC. What is interesting, is that these are the teams that get acquired for the technology they end up with. These are AddLive, Screenhero, BlueJimp and to some extent even Beam.

#2 – The Owners

“How can I rely on someone else with my infrastructure? I must own it to be able to resolve issues and control my own destiny”

And still you go place your service in AWS.

Owners like to own stuff. They need control over it. They are just fine paying others to build it, but they want to own and control the finished product.

While I value ownership, I think it is something that needs to be questioned each and every time. Is that piece of technology really core to the business? Is it where innovation and barriers of entry to your market is found? If not, then you should probably rent and not own.

On the other end, ownership is sometimes necessary, and the reasons vary from case to case. Here are a few good ones I’ve heard:

  • No CPaaS vendor covers our geography
  • Regulation in our industry mandates it. Our own customers are “Owners” themselves
  • We have this critical feature no one has that forced us into building our own infrastructure
  • Our industry is crowded and competitive. We need any advantage we can get

#3 – The Dreamers

“Collectors of wood art need a place to meet”

I have a dream. And in my dream, I see an untapped market. A need that isn’t answered. I am clueless about the technology that gets me there, but I am sure that will solve itself.

Many of these around. Especially now that WebRTC is with us. The reason? WebRTC lowers the barrier of entry for new players. And the best way of getting there fast is by employing CPaaS.

The Dreamers focus on their target audience. That niche market, where a problem needs to be solved. In many cases, they come from that market.

A dancer with cancer, trying to find a place for women suffering from cancer to dance from home.

Psychologists building an online group therapy service.

Teachers building education services for a very specific target audience.

You’ll find these in the verticals – places where communications is a part of the service – a feature within another service.

To You Now

Did you find yourself in that list somewhere?

Are you a Dreamer trapped inside an Owner school of thought because of the limitations of CPaaS vendors?

Are you striving to be a Tinkerer but don’t have the workforce for it?

How are your intents and company DNA match with your school of thought?

I am seriously interested in it, so leave a commend or email me about it.

Can’t decide which  CPaaS vendor to use? Check out my CPaaS vendor selection matrix:


You may also like

Comment​

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

  1. Great short read Tsahi – Thank you.

    I guess I represent a little of each at some level.

    – As a tinkerer: I need to deliver an end product
    – As a dreamer: I need to get practical
    – As an owner: I need to leverage and delegate more

    Great article to put things in perspective.

    Thanks
    Peter

    * NOTE: website in progress

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}