Build vs Buy: Creating realtime network infrastructure for your apps

Modern users expect realtime features

App consumers have become accustomed to expecting realtime features in almost every service they use. From remote collaboration to dashboards, gaming, polls, live location, chat and more, the use cases for realtime features are immense, and it’s without question that realtime access to data is a game changer when it comes to user value and convenience. These features help to boost engagement, collaboration and retention.

But when it comes to creating the infrastructure for realtime features in your app, should you build your own in house, or choose an off-the-shelf API to do the heavy lifting for you? Part of our job when we speak to new customers is to help them make an educated decision about the payoffs of each option.

Build vs Buy

Some developers choose to start from scratch, or to use an open source tool (like Socket.io) and their own expertise to build, deploy, maintain and scale a solution. This may allow you a greater level of flexibility than you would have with an API, but comes with its own problems; including commitment to maintenance, security, reliability, tooling and analytics, as well as implications for the costs and time to market for your app.

Hosted APIs offer a faster ready made solution, and depending on the provider you choose will take care of many of the operations associated with your infrastructure. After deciding on a provider you can purchase and install a simple SDK for your preferred stack and leave the complicated infrastructure commitments to be taken care of for you.

What does it really cost to build?

If you decide to build your infrastructure in-house, there are three costs you’ll need to consider: the time your team spends building the infrastructure, the annual maintenance, and the missed revenue from any delay caused to the development of your core product.

One of the biggest pitfalls to avoid when building your realtime infrastructure is to underestimate the amount of time and effort it will take. You’ll also need to consider the implications of providing support for a component you might not understand in production, because you don’t have the benefit of having written it yourself.

In the best case, let’s assume it takes 20 weeks to build and integrate your feature. The model below compares how that might look in terms of cost. Even if you are considering building in-house, it might make sense to temporarily include an add-in. Let’s face it: today’s users don’t want to wait 20 seconds, much less 20 weeks for new features. And if your competition already has these built in, you really can’t afford to wait.

So if you decided to build, you would spend $35,000 to save $300 per month. That’s the equivalent cost of a Pusher business account for 9.5 years. If you examine this model over time, the off-the-shelf service option still remains the least expensive option.

But that’s not even the biggest cost associated with building over buying. With your engineers focused on building realtime infrastructure, they didn’t spend time building the realtime feature that will make your product better.

If your recurring revenue is growing at a healthy 10%, but the features you delayed by building infrastructure instead would have increased growth to 11% then the true cost of building is hundreds of thousands, or even millions, in missed revenue depending on your multiplier. Ouch.

Ongoing maintenance

Total cost of ownership (TCO) is always a concern when you are building yourself. First of all, you’ll have ever-increasing cloud provider costs as your app gains traction and you expand your operations.

Secondly, your development team will need to maintain the code. Maintenance costs will vary, but any issues or bugs will be your problem, not to mention scalability.

Choosing an API with proven high throughput will save you the headaches of dealing with scalability as your app adoption increases. Realtime features are intrinsically designed to increase the engagement of your app, so it’s predictable that your needs will grow.

Scaling realtime infrastructure

There are lots of open source tools available for delivering realtime data with WebSockets, and even some language frameworks with native support for doing just that. But delivering a realtime experience at scale is tough.

Holding an open connection between your service and a client over a WebSocket is relatively easy, but as you scale from one device to thousands or even millions, you not only have to keep these connections open, but you need to deliver a throughput of millions of messages per second. This is a problem which expert hosted APIs like Pusher Channels have a wealth of experience with, and have solved for you.

Adding realtime features to an app doesn’t have to be a time-consuming or costly process. You can have API-based infrastructure ready in a matter of a couple of weeks. Pusher Channels has been proven by our thousands of developers, with trillions of messages sent during our 10 years of operations. Not only will using an off-the-shelf API save you time and money, it will lower the risk of development and allow you to lean on our expertise. Channels was built out of our own need for a simple solution to realtime features, so we understand the struggle that comes with starting out from scratch.

It’s still important to create a basic specification and needs definition before choosing the API that’s right for you, and a big part of that is taking time for DIY experimentation, but in almost every case, you can find options that will be faster, cheaper, and risk-optimized compared to in-house development.