Are you sure you’re ready with your WebRTC product launch?
Here’s the thing. If you want to have a successful launch at the end of the project, you should focus on the planning phase in the beginning. Oh – and your plan should be different if you are going to self develop it all in-house or have the communication parts of it outsourced to external vendors.
Too often people contact me when they have already budgeted the project, spent the money, have a “product” in hand but it is lacking.
Two extreme cases recently:
- A startup hired a development company who said they know WebRTC. They were so good that they said there is no need to use a media server for 8 participants in a session unless the session is being recorded (if you think that way too, then you are more than welcome to take my WebRTC course)
- Another startup got delivered a finished product. Just to find out it didn’t even come with a TURN server
We see this even more at testRTC, where I am a co-founder. Companies come to us because they think the product a third party developed for them doesn’t work as expected, and too often it breaks in ways that are unacceptable (like stressing the service with 20 browsers).
The problem is finding these issues too late in the game, and paying dearly for them.
There are lots and lots of images out there that illustrate the issue. I’ll use the one from Raygun:
We can dispute the multipliers. They don’t really matter. But here’s how a typical WebRTC product with outsourced development takes place:
- Someone writes down the requirements (amount of detail varies wildly here, and of course, you can use my requirements template)
- He sends a few development companies the RFP. Mostly, these will be sent to local developers, but sometimes to other vendors as well
- Once responses are back, he will pick one. Almost at random… (I know it isn’t random, but it will mostly lean towards cost, as the one in charge knows little in this domain anyway)
- Now we wait. Just like placing a cake in the oven and waiting for it to cook. Once the big day arrives, the customer plays with what he gets back and finds out there are some holes in it. Areas left uncovered, or just an impression of poor media quality
Here’s the problem. Steps (1), (2) and (3) are the Design phase. And no one took any real ownership of it in this scenario.
Step (4) is probably Development,Testing and Staging. And they were all left to an outsourcing vendor. Who is most likely looking at this project from a cost perspective as well – but he doesn’t really care if this gets launched or not. Not really.
The customer got to step (5) immediately. With no milestones along the way. No checkpoints to see if everything is done correctly.
And please don’t sell me the story of agile development and how that will save the day for this customer. With agile he sees the “results” every week or two. In every sprint. But does he really know if that first Design phase was done properly?
Do you think you are getting a stable product that can scale to the millions (or even thousands) of users you plan on having? Are you sure your contractor feels the same way and didn’t build you a proof of concept instead?
Two things to do NOW about your WebRTC project:
#1 – Make sure you have a solid WebRTC architecture
Do you trust your vendor to build you the architecture you need?
Don’t.
You should do your homework or bring someone on “your side” that knows what he is doing.
Go now and look at the architecture you’ve been promised.
Take that architecture you’ve been given by the vendor and get a second opinion. It will be worth the time and effort.
#2 – Register to this free webinar
At testRTC we’ve decided to host a free webinar that deals with these issues exactly. And me? I decided to announce it here as well because I think it fits my readers AND it gets more people to know about testRTC, which is another thing I am a part of.
WebRTC: How NOT to Fail in Your BIG Launch
The webinar will take place on July 25 at 14:30 EDT.
It will be recorded and available for playback, so register now.
See you then!
I am surprised that you miss one of the most important steps:
Five weeks later Chrome rolls out with a breaking change. The customer is woefully unaware until their users report it.
That’s assuming you got to that point successfully 🙂