Why In-House Communications API Integration Projects Fail
Learn about the common challenges of building your own communications API integrations and how you can avoid these issues with Nylas.
Andrew Slate | February 25, 2022
So you’ve decided to put a team of developers to work building integrations, features, or infrastructure between your product and any number of communications providers.
Fast forward six months and your project is out of scope and over budget. Your team is still spending resources resolving bugs and accounting for endless customer edge cases. The reality is that, even after you 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.
Want a PDF of this article?
Share it with a friend or save it for later reading.
Creating your own integrated communications platform can place a heavy burden on your budget, your engineering staff, and your company’s overall competitiveness. Building communications API integrations in-house is incredibly inefficient and distracts your technical talent from critical work. And when these projects stall or fail altogether, they can also cause significant delays that slow your time to market. In this article, we’ll explore the main reasons why most in-house builds fail and what you can do to avoid these pitfalls.
Integration Complexity Across Different Service Providers
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 with. From Gmail to Microsoft 365—they all have their own schema. The more providers you’re working with, the more nuances you 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:
- Authentication – Creating and configuring the infrastructure required to allow users to securely grant your application access to their data
- Email synchronization – Building functionality that allows for push notifications, attachment storage and handling, encryption, and HTML normalization and must also include edge cases
- Calendar synchronization – Managing time zones, invitation responses, and recurring events
- Contact synchronization – Developing the architecture to communicate with each provider’s contact APIs
- Email tracking – Supporting open tracking, link tracking, reply tracking, and search support
- Inbox parsing – Extracting reliable, high-quality data from email.
- Provider-agnostic tasks – Carrying out tasks like maintenance and support, security, synchronization speed, synchronization infrastructure, storage layer, administration user interface, and logging
API Integration is More Costly Than You Think
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 ongoing.
The Ongoing Cost of Integration Maintenance
Inevitably, most in-house integration projects will require ongoing maintenance that taxes your developer resources. Your developers will need to deal with ongoing maintenance issues and the inevitable bugs that your end users will likely uncover—resulting in a poor user experience. This maintenance will lead to delays and your engineers to ask as full-time integration experts, which will prove to be 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.
All the while, you’re losing out to your competitors that have opted for pre-built communication solutions, so their developers have more time to spend on R&D opportunities and innovation. 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 helping your organization achieve its business goals.
The Risk of Tribal Knowledge
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 complexity 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.
Deliver Communications Features Quickly and Efficiently with Nylas
If you choose to build in-house, understand that these initiatives are an ongoing investment that will distract your dev 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. For more information on how you can save time and money by investing in pre-built solutions, click here.