An innovative new product idea can be genuinely exciting but it’s the execution that delivers value. How fast you can get a product or feature to market can be the difference between a solid return on investment or missing the moment because someone else got there first.
With realtime experiences as a core part of almost every web and mobile based app, how well and how quickly you can deliver realtime infrastructure is a core factor in your time to market. Will building your own or buying an external solution help you serve customers sooner?
This is the last post in our build vs buy blog series. In previous posts, we’ve covered:
- Realtime experience capabilities and use cases
- The costs and challenges of building realtime infrastructure
- How to reduce the risks of delivering realtime experiences
- How to reduce the cost of delivering realtime experiences
Why does the time-to-market of your realtime experiences matter?
Research by McKinsey shows that shipping a product six months late can reduce profitability by a third. But why?
If yours is the first product to solve a particular problem, you’ll enjoy a period of monopoly. The later you are to deliver, the less time you have to exploit the lack of competition. If you’re entering a relatively mature market, being late means the functionality gap between your product and the incumbents’ will grow.
When it comes to delivering new functionality, rather than an entirely new product, the situation can be even worse. B2B customer loyalty is lower than ever. A classic recent example is the design software Sketch. Having won the affections of designers around the world, it seemed that Sketch was unassailable. But its developers missed two important customer needs: developing for Windows, and building in multiplayer collaborative features.
As a native Mac app, Sketch cut out the vastly larger group of Windows users who were more likely to be product owners, developers, or other potential collaborators for the designers. But more importantly, Sketch missed the multiplayer revolution.
That provided an opportunity for Figma to take over the market with a cross-platform product that focused on realtime multiplayer collaboration – and left Sketch fighting to keep up.
A survey in late 2021, after the launch of Sketch’s realtime collaborative features, showed that only 12% of designers used Sketch as their primary design tool compared to 63% who used Figma. Being second to market with realtime functionality seems to have permanently damaged Sketch’s business, while Adobe recently bought Figma for $60 billion. During the time that the Sketch team debated how to insert multiplayer collaboration into their product, Figma went ahead and took the market from underneath them.
How long does it take to build realtime infrastructure and capabilities in-house?
Building in-house can seem like the right choice. The idea is that you get a perfect match for your use case and total control. Let’s assume for a moment that’s true. What would the commitment look like?
In research we conducted for the State of Serverless Websocket Infrastructure report, we discovered that the typical self-build realtime infrastructure project takes 10.2 person-months. And the complexity of the engineering challenge caused significant resourcing, project management, and quality issues.
Significantly, 46% of respondents said that costs escalated during development, presenting a threat to the project’s success. That’s largely because staffing realtime projects takes a substantial amount of engineering resources, with 93% of projects requiring between four and ten or more engineers. When it comes to timelines, 41% of respondents report missed deadlines, with 69% of projects lasting for three months or more and 21% taking six months or more to complete.
If you’re looking for more detail on how long it takes to build realtime infrastructure in-house, take a look at part four of this series.
What factors impact the delivery timeline for realtime experiences?
One reason that it’s hard to plan accurately for realtime engineering projects is that the problem itself is a hard one to solve. Expectations are high, with little room for failure. Another is that many of the complexities become apparent only once engineering work begins.
Building realtime infrastructure and capabilities is challenging
Realtime is hard. And that’s not to question anyone’s skill as an engineer. It’s just that the problem space itself is complex. When you set out to build realtime infrastructure for the first time, you’re switching from a relatively sedate programming model where the order of operations is dictated by the code. An event driven architecture, on the other hand, requires acting immediately on new data with little to no foresight of ordering.
Get that right and the next challenge is to make all those moving parts work in concert reliably, predictably, and at scale. The knowledge of how to architect that usually comes only with practice. And it matters because every delayed message, every minute of service degradation, and any moment of downtime directly impact end user experience. Realtime sets high expectations.
“We spoke to engineers at LinkedIn, Slack, and Box who had already built realtime infrastructure themselves - they told us it would take non-trivial upfront engineering with significant operating costs to build and operate this in-house.”
Pato Echague, CTO, Split Software
The time and resources required is often underestimated
Hand in hand with the complexity of building realtime infrastructure is just how difficult it is to estimate the resources and time required. Project managers responding to our survey reported that their initial deadlines proved inaccurate, while their expectations around resourcing had to be revised upward as the true complexity of their projects became apparent. Specifically, 52% of projects needed more developers than expected and 53% took more time.
For 16% of projects that overran, estimates were so far out that they required at least three to six months of unplanned engineering time and up to three additional engineers.
Overrunning by months is potentially fatal for a software engineering project. But even smaller setbacks impact time to market negatively. On top of that, 46% of respondents said that overall cost of the project posed a major challenge, while 41% reported that they missed deadlines. Less than a tenth of respondents said that building their realtime WebSockets infrastructure was problem free.
Gain a competitive edge - use a realtime PaaS provider
The alternative to building your realtime infrastructure and features is to take advantage of the expertise and infrastructure provided by a realtime platform as a service (PaaS) provider. Crucially, buying infrastructure in this way, rather than building it in-house, frees engineering teams to focus on building the project’s strategic functionality. In fact, 55% of respondents to our survey cited that as a reason for using a realtime PaaS.
Overall, the top three reasons engineers gave for preferring a serverless realtime platform for their live engagement products were to:
- Deliver more stable, reliable infrastructure.
- Focus engineering headcount on functionality that directly solves end user problems.
- Reduce risk when bringing realtime functionality to market.
Each of those reasons reflects the reality of the risks of building realtime infrastructure in-house. Even once the project is delivered, every new product feature request will require additional engineering work to ensure the infrastructure can cope. Similarly, as uptake grows then the non-trivial task of scaling the platform will lead to opportunity cost as engineers are diverted away from feature work. Rather than pushing the product forward, developers will be running to stand still.
Choosing a realtime PaaS such as Ably allows your engineers to bring innovation to market quickly, knowing that the underlying infrastructure will:
- Scale on demand
- Require no ongoing maintenance
- Benefit from new functionality as soon as it is available in the PaaS.
Companies who choose Ably on average benefit from:
- $938k return on investment in the first year
- Three times faster go-to-market
- Two months to break even on the costs of using and integrating with the realtime PaaS.
Realtime experience platform Mentimeter has used Ably to deliver an improved user experience to market in less than a month.
“Our real time engagement platform requires instant audience feedback at scale. Ably seamlessly absorbs sudden bursts in load during unexpected client events. The integration was easy and we were live in under a month.”
Johan Bengtsson, CTO, Mentimeter
Start building with Ably for free to see just how easily it integrates with all major tech stacks and how it can help you deliver functionality faster.
