6 Questions to Ask Yourself BEFORE Hiring a WebRTC Outsourcing Vendor

How do you find good WebRTC outsourcing talent?

At least once a week. That's about the current rate in which I bump into a hiring or talent question related to WebRTC. Recently, I got a few calls with companies that went through the process of working with an outsourcing vendor who developed their app and got stuck. Sometimes it was due to bad blood going between the two companies. But more often than not it was because the company that approached me wasn't happy with the delivered results. The application that was developed just didn't really work as expected. Looking at some of these apps, it was easily apparent to see that the developers were clueless about WebRTC. Things like wrong NAT traversal configurations (or none at all), or the use of mesh media delivery for large multiparty video sessions are the most obvious warning signs here. If I had to think why this is so, my guess it boils down to three reasons:

1. WebRTC is still rather new. 5 years. So there's still not enough mileage on it for most developers
2. It isn't Web and it isn't VoIP. But it is also Web and VoIP together. Which means many seem to misunderstand it
3. Skilled WebRTC developers are hard to find. Less than 12,000 profiles with that term on LinkedIn's now 500 million profiles

When you go and ask from an outsourcing vendor to build you a service, the answer you will get is "sure thing". And then a price and a timeline. That's their business, and most would often use that project as their jumping board towards another domain of expertise for them. Many of these outsourcing vendors won't invest in learning new technologies without a customer paying for that investment. This means that a lot of the market for WebRTC outsourcing is a market of lemons. Which is why it is so important you check and validate your prospective WebRTC outsourcing vendor before signing an agreement with him. Here are 6 questions to ask yourself before you hire a WebRTC outsourcing vendor.

#1 - Do I know my own requirements?

There are two parts to knowing your requirements from the product:

1. Knowing and understanding your business and the interactions you want for it
2. Understanding what's realistic for you with WebRTC to set your expectations accordingly - this also means understanding the costs of certain features versus how important they are for you

For that, I suggest you use something like my WebRTC requirements template.

#2 - Am I their first WebRTC customer?

This is a biggie. Try. Not. To be. Their FIRST. Customer. That does. WebRTC. Don't be their first customer doing WebRTC. Make sure you're not the first one they build a WebRTC product for. Their first WebRTC project? You shouldn't be the one they do it for. Got the point? One more time if you missed it: I knew that picture (and font) would come in handy some day.

#3 - Has the team who will be working for me built a WebRTC product before?

This one is somewhat tricky, and I must say - a bit new in my list of top questions to a WebRTC outsourcing vendor. If you've been reading this from the start instead of skimming through, you might have seen the number 12,000. This number is higher than the number of profiles in LinkedIn that have the term WebRTC in them anywhere. It means that with some of these WebRTC outsourcing vendors, the people put in place on your project might not be the ones who know WebRTC - these are already fully booked by other clients - or they might have gone elsewhere (with the demand of WebRTC developers, I wouldn't be surprised to see them learn the trade in one vendor and move on to the next). I've seen it happen once or twice before. So make sure that not only does the vendor knows WebRTC well - he is also placing the right people on your project. And understand that there are times when not the whole team must know WebRTC to develop a successful project.

#4 - Can I validate what they build for me?

Developers who don't know and understand WebRTC won't be able to deliver a commercial product for you. If they don't understand the server side of WebRTC and its implications (check my free mini course on WebRTC server side), then the end result will run great between you and your pal sitting next to you, but when you take it to production it will fail spectacularly. Things to look for:

1. Not configuring NAT traversal properly (public STUN servers, no TURN servers, no TCP or TLS configurations for TURN)
2. Using mesh instead of mixing or routing the media (see here) - in plain English, not using a media server in scenarios that beg for it to be used
3. Not testing for scale (see here)
4. Not checking the result in varying network conditions

While some of these can be solved just by more testing (and focused testing - one where the tester actually knows what to look for), there are times when the architecture selected for the product is just all wrong. It should have been apparent from the get go that it won't hold water. But anyways - make sure you've got a plan in place on what and how to test to validate that that thing that was given to you as the finished good is actually the finished good and not finished for good.

#5 - Should I ask for something On Premise or CPaaS based?

This goes back to #1, but slightly different. Probably should have placed it as #2. Developing your own product from scratch will be more expensive than using a CPaaS vendor. CPaaS vendors are those vendors that take the whole hassle of real time communications, wrap it with their nice API and manage it all for you (and yes, I wrote a report about them). Whenever I sit down with an entrepreneur that wants a product I start there when it comes to vendor and technology stack selections. Trying to understand his restrictions and requirements. Oftentimes, entrepreneurs are deterred by the seemingly high pricing of CPaaS vendors. Especially at the beginning - when they believe they will get to a million monthly active subscribers within a month. Well... it won't happen to you. And if it does, a VC or two will probably be happy to foot that bill, understanding you probably found a real boon. What should you do?

1. Read this one. And then read this one from Chris Kranky
2. Make your  decision on that build vs buy decision (in both you will be building - don't worry)
3. Revisit your initial requirements
4. Revisit that vendor you plan on working with

#6 - Who is the owner of this project on my end?

Someone needs to be the owner of this project on your end. Yes. You have a WebRTC outsourcing vendor developing this thing for you, but you need someone to have that vendor behave and deliver. That someone needs to understand WebRTC well enough to handle the requirements, the discussions with the vendor for all the issues that will arise along the way. I'd also recommend having that someone on the payroll and not external. If you don't have such a someone then you effectively selected you for that job. Congrats!

Do Your Homework

If you plan on starting a project that makes use of WebRTC, and you plan on using a WebRTC outsourcing vendor for it, start by doing your homework. Make sure you have the answers to the questions above. And if you need help along the way - with the requirements, the architecture, the vendor to select, the process - you know where to find me.