Calendar management
Embedded contextual email
Scheduling automation
Automated outreach
Telehealth
Marketplaces
Recruiting
Document management
Real estate
Communications software
Docs
SDKs
Tutorials
API status
Changelog
Support
Blog
Events
Guides
Newsroom
Partners
Build vs. buy
Customer stories
Trust & security
Why NylasWhy Integrating Communications In-House Is a Losing Battle
Learn about the common challenges associated with building your own communications integrations and how Nylas can help you avoid them.
Learn about the common challenges associated with building your own communications integrations and how Nylas can help you avoid them.
So, you’ve decided to put a team of developers to work building integrations, features, or infrastructure between your product and a number of communications providers.
Fast forward six months and your project is out of scope and over budget. Your team is still pouring resources into resolving bugs and accounting for endless customer edge cases. Then comes the reality that, even after you eventually launch your integration, the work doesn’t stop there. Your team needs to regularly maintain and update it, which will prevent them from working on projects that drive business value.
The truth is, building communications API integrations in-house is incredibly inefficient and distracts your developers from critical work. By spending more time on backend integration infrastructure and less time on the front-end features your customers actually use, you’re risking poor engagement rates and high customer churn. And when these projects stall or fail altogether, they can also cause significant delays that slow your time to market, allowing your competition to launch faster.
In this article, we’ll explore the main reasons why most in-house builds fail and what you can do to avoid these pitfalls.
As you build communications integrations, features, and infrastructure across different channels, you will need to take a different approach for every service provider you’re working with. From Gmail to Microsoft 365, each provider has their own schema. The more providers you’re working with, the more nuances you’ll need to deal with for every integration.
Let’s take Microsoft Graph API as an example. At first glance, it looks like a standard REST API, but working with it means your developers need to learn OData. This protocol comes with its own challenges, such as arbitrary format requirements, lack of time zone standardization, and notoriously unhelpful error messages (such as “Invalid OData query filter”).
Different service providers have varying technical requirements that your team must handle. Some of these tasks may include:
A common misconception among managers and engineering leaders is that in-house integration projects are a one-time investment with relatively finite costs. In reality, both the costs and the time your developers invest into these projects are robust and ongoing.
Inevitably, most in-house integration projects will require ongoing maintenance that taxes your developer resources. Your developers will need to deal with these issues and the inevitable bugs that your end users will likely uncover. This maintenance will lead to delays and require you to task your engineers as full-time integration experts, which will prove costly.
These issues and delays can slow down your time to market, preventing you from acquiring new customers and limiting your market share. Rushing your launch will likely leave you with hidden technical debt to deal with further down the line. Your team will become inundated with fixing bugs that are negatively affecting the customer experience rather than innovating new features that will delight customers.
A recent study by McKinsey found that software engineers dedicate as much as half their time to ongoing maintenance and issues when working on projects that create large amounts of technical debt. This time could be better spent on R&D opportunities and helping your organization achieve its business goals.
If and when the engineers that work on a given integration leave your organization, they take all of their domain knowledge with them. That means having to find another set of integration experts to take their place and bringing them up to speed—a costly proposition.
In this case, your replacement developers would also need to fill in as integration experts. You’ll need to invest additional resources to retrain them. And if the engineers who previously worked on these integrations didn’t diligently document all the variables and unexpected complexities they encountered, your new hires may need to start from scratch.
All this change and uncertainty can lead to a poor user experience. As your customers uncover all the bugs and gaps that your team missed, they become far more likely to churn or seek an alternative solution.
If you choose to build in-house, understand that these initiatives are an ongoing investment that will distract your developer resources from other critical work. Alternatively, you can choose Nylas to quickly and efficiently deliver communications features and solutions using a single, easy-to-use interface. Below are some notable highlights from companies that took this route:
For more information on the hidden costs of building your own communications features, sign up for a live demo here.
Please enter your email address and receive the latest updates.
Andrew is a Product Marketing Manager at Nylas who covers topics ranging from productivity APIs to data analytics. He's passionate about digital and film photography, camping, and backpacking.
