Developing any kind of feature or functionality is a use of internal resources that can’t be recovered & has a high opportunity cost. You could be building any kind of feature, but how do you know that this is the most impactful feature for you? I’ll cover all the aspects to build an email and calendar integration internally. This blog will guide you on analyzing your best choice between building or buying for any type of integration, too.
There’s always a trade-off between priorities for engineers & product teams:
Is this functionality that fundamentally solves problems that our prospects and customers have, so we can capture a piece of that value in the form of revenue & grow the business?
Does it actually work?
Engineers can build practically anything, and have a natural bias towards building rather than buying. In our prior blog post we covered the Hidden costs of infrastructure, which covers building an email integration in the right way – now we explore the costs of building directly vs. buying an API.
There are four components to understanding revenue impact, and a few ways to identify those figures. It’s a matter of how much more you can make (incremental revenue), how much you can save (reducing churn), how much you can grow (increasing upsells), and how soon you can offer it (GTM speed).
Ideally your sales team uses a CRM, and ideally they’re capturing lost deals and the reason why they’re lost. Incomplete or missing functionality as the primary or secondary reason should be captured here – you could look across the prior 12 or 24 months of lost deals to identify total missed revenue. If your sales team can bring those deals into their pipeline, only to lose them due to the missing functionality, it’s reasonable to assume that they can bring in new pipeline and that your team can re-engage some of those lost deals.
Customer success teams are fantastic at assessing risk for renewals and capturing customer feedback. What does your upcoming 1-2-3 years of renewals look like, and what deals are at risk because of your missing functionality? If a key customer is planning to leave, or at least raising risk to uncomfortable levels, then this is direct pressure to prioritize building sooner rather than later.
It’s 5x harder to get revenue from new business than it is to get it from existing customers (not to mention your sunk costs for acquisition, marketing, and support). Is this going to be a new feature that you charge for, or will it be bundled into existing plans? Bundling leads to higher adoption, more value generation, and more opportunity for price increases down the track, but upsells get you revenue faster. This is a tradeoff that historically we’ve seen lean more towards bundling, especially if points #1 and #2 are compelling already.
If your customers in point #2 are churning in the next 6 months, then I have bad news for building internally – it’s going to take longer than that. We have customers that have reported spending 24+ months building internally, only to look for another alternative in the space because they couldn’t reach a stable & comprehensive integration. The sooner you can impact revenue with your feature, the faster you can start making payback & reaching a positive return on investment. Often this tilts the scale towards buying an API rather than starting from scratch.
Email, calendar, and contact integrations require infrastructure to run on, but that infrastructure isn’t just spinning up AWS or Azure instances – it’s a framework that supports a successful integration, and supports all of the other teams in your business.
Your support team can’t help customers when they don’t have visibility into logs or internal tools to debug issues (we use Retool and OpenTelemetry extensively for this). Your application may onboard bad actors through free trials or customers who don’t follow email best practices. You’ll receive spam reports, have to manage blocklists, all while building a scalable backend that can support many thousands or millions of users. These are fun challenges for some engineers, is your team prepared to have to hire additional engineers to manage this in the long term?
Infrastructure is an often forgotten component of building direct integrations, and it only gets you to the starting line for building a successful integration. Even if you only want to build directly to a small handful of the most popular providers, it needs to be taken into account.
Estimate: 36 weeks of work, plus an ongoing 0.5 FTE Site Reliability Engineer (SRE) resource
Account management is more straightforward for large providers like Google or Microsoft Office365, but it rapidly gets complicated as you expand to the long tail of IMAP providers.
Some providers are easier than others, but all providers need:
The time estimates here are for each provider to account for their own complexities, so there’s an element of deciding who you want to support at launch.
The intersection of what providers you want to support, with the feature set your use case needs, determines the level of resourcing you need. This heatmap highlights core functionality for email, calendar, and contact integrations for every provider (where available).
Resourcing has to take into account variations in provider behavior, the research required to understand these nuances, and coding, testing, and deploying features. Some providers, like Google and Office365, are straightforward for certain use cases but we’ve found that this rapidly increases in complexity with more ‘complete’ functionality. Even adding providers later in the roadmap (like expanding from Office365 to Microsoft Exchange) requires significant adaptation because of differences between data models and backend behavior.
Some providers are easier to build with than others, but your customer base likely doesn’t only use Google. If we take Google and Office365 as an example, though, let’s see the intersection of time & cost.
This can be added up for infrastructure and for each provider to give us a full view of both time and cost.
Now we know how much we can make for building this functionality, and how much it’ll cost to build it in-house. We know that it’ll take much longer to build internally, and your timeline would optimistically look something like this for the first 12 months.
Launching with a reduced scope is a good way to get customers & revenue over the line, but it prevents the full opportunity of your email, calendar, and contact integration from being realized – you may be building into year 2, or even year 3 if maintenance ends up being a larger challenge than expected.
Salesloft offers a sales engagement platform for sales teams. Email is a fundamental tool for sales teams to grow their business, Salesloft knew that they would need to eventually expand to more than just Gmail. This is where Nylas resonated to them; to support multiple email and calendar providers. Using Nylas allowed their engineering team to bring their Microsoft Exchange integration to market faster, and without needing to hire an additional 10 engineers to support the maintenance of their integrations.
“Without Nylas, our channel health team—which monitors the overall health of all of the channels we support in Salesloft, including email, messaging, and calls—would need to reallocate 25% of its resources towards resolving issues with Exchange,” remarks Mitchell.
“Additionally, we’d need almost a full year’s worth of resources from a team of developers for continual troubleshooting and maintenance. Between our channel health team and resources for maintenance, we would need an additional 10 full-time engineers working to ensure high-quality email connectivity to our users. If we had built and managed a Microsoft Exchange integration ourselves, our staffing needs would be significantly larger.”
Read the full case study here.
Looking back at our initial revenue assumptions, there are three factors within your control:
The easiest things to control here are around how feature complete your launch is – prioritizing just Gmail users prevents your customer success team from retaining Office365 users. Prioritizing email over calendar won’t close deals that want a calendar scheduler for appointment booking.
Launching incomplete features sooner is risky, and might actually increase your overall risk in your customer base. The sooner you can launch, though, is sooner that your team can capture revenue. Speed for go-to-market (GTM) is key.
Developers love solving complicated problems, but email, calendar, and contract integrations are established & solved problems with Nylas. Connectivity is table-stakes for products like a CRM or ATS, so is it the best use of their time & cost to the business to rebuild existing functionality?
With Nylas’ communication and scheduling platform, you can gain a competitive differentiation by unlocking new functionality, accelerating your go-to-market speed,, while increasing revenue growth.
How? Nylas developer platform enables companies – like yours – to integrate email, calendar, and contacts functionality into your application, empowering your technical teams (developers) to focus on innovating your own use cases and services.
Embedding Nylas into your own applications not only improves your customer experience, also saves your organization time and money, letting your product teams focus on building your competitive advantages rather than working on tablestakes functionality. Resulting in lower development costs and accelerated time-to-market, while addressing your security and compliance requirements.
Looking to learn more about how Nylas and connectivity can change your business? Try Nylas now.
Dive into the world of smart Web Components for advanced API integration solutions. Design elegant, customizable elements to elevate user experiences.
The Nylas Apex SDK gives systems integrators a toolkit to develop email, calendar, and contacts integrations in Salesforce fast.
Nylas ExtractAI launches today for e-Commerce extraction in five markets, with support for over 30,000+ e-commerce merchants.
Nick is our Product Marketing Manager for the AI & Intelligence products at Nylas. Hailing from New Zealand and based in Chicago, IL, Nick spends his free time hiking, cooking pasta, and riding his spin bike.
Email API
Calendar API
Contacts API
ExtractAI
Salesforce email integration
Google email & calendar integration
Outlook email & calendar integration
IMAP integration
Calendar management
Embedded contextual email
Scheduling automation
Automated outreach
Intelligent data extraction
Ecommerce
Telehealth
Real estate
Financial technology
Educational technology
Expense management
Customer relationship management
Applicant tracking system
Communications platform
Marketplaces
Document management
Docs
SDKs
Tutorials
API status
Changelog
Support
Blog
Events
Guides
Inspiration gallery
Partners
Build vs. buy
Customer stories
Security & Compliance
Why Nylas
Newsroom