No, You Shouldn't Build Integrations

The 2015 version of Intercom’s Platform Team was a lean machine. When I joined, in October of that year, the team consisted of three engineers… and me. They already owned and managed a vast range of services, from developer-facing APIs, to early integrations with Slack, GitHub, Jira, and Stripe. I was beyond impressed.

Yet, despite their success, I felt a sense of frustration building within the team.

Integrations were the problem.

Intercom had 8,000 customers at the time, and was growing quickly. The volume of data these customers generated grew by the hour. Much of that volume was ingested through 10 integrations the team had built to that point - with Zendesk, Salesforce, Zapier, HipChat, Segment, Mixpanel, and MailChimp also in the mix.

Proactively reactive

Integrations solved problems for customers, but also created problems for the team. Breaking changes. Scaling issues. Bugs. One day our Salesforce integration suddenly didn’t work with new versions of their Platform.

Reactive mode was starting to become a default for the team. It often felt impossible to carve out time to push the Platform forward - to release new APIs, improve our developer documentation, optimize our core services, and build table-stakes features like the first version of the Intercom App Store.

All the while, customers - the ones we had, and the ones we wanted - demanded more and more integrations.

Yet, for better or for worse - and in service of our customers - the team ploughed ahead and built world-class integrations with Facebook Messenger, Twitter, Shopify - making Intercom an “omnichannel” for the first time.

They built a new Developer Hub, an Integrations Hub (now known as the “App Store”) and launched developers.intercom.com. All while launching and maintaining a growing API surface area.

I’m still in awe of them. I have no idea how they did it.

But it could have been so much easier.

No more work-work

Today, almost a decade later, Platform teams shouldn’t be building integrations. Why? They don’t need to.

Thanks (ironically) to a vast and growing catalogue of developer-friendly APIs, a new wave of products and services have emerged, each eliminating work-work from the process of building and maintaining integrations. They typically fall into three categories: iPaaS, Integrations-as-a-Service, and Universal Integration Frameworks.

iPaaS

Also known as Integration Platform as a Service, iPaaS providers like TIBCO, Mulesoft and Workato emerged in the 2010s, offering “low code” alternatives to building custom integrations between B2B and consumer Platforms.

Driven by the the “Web 2.0” era of developer-friendly REST APIs and increasingly open Platform access, iPaaS solutions allowed in-house development teams to eliminate work-work and move fast.

On the downside they were typically “enterprise” products with high annual costs, and were too expensive for most startups . Plus, their customers still required in-house developers to build and maintain integrations.

Integrations-as-a-Service

Over the past few years companies like Pandium and Left Hook built on the momentum of early iPaaS providers, offering a new type of service to startups and enterprise customers alike: Integrations-as-a-Service.

Leaning on a mix of their own proprietary technology and open source solutions, Integrations-as-a-Service providers do the work for you, usually at a fixed or close to fixed cost per integration built. They also offer ongoing maintenance services to ensure your integrations stay up to date.

On the downside, these upfront costs can still be prohibitive for some early stage startups, especially those dipping a toe in the “integrations” water. That said, still a far more cost efficient route than building in-house.

Universal Integration Frameworks

Powered by a new wave of AI capabilities and the emergence of front-end frameworks like React, Universal Integration Frameworks (often referred to as “Universal APIs”) offer products that help in-house teams build native integrations - without really building them at all.

Companies like integration.app and APIDeck offer mostly “no-code” products that enable customers build similar integrations with multiple Platforms - like Zoho, HubSpot, and Pipedrive - in clicks rather than code.

One integration pattern can be mapped and applied to multiple Platforms at once. Ready-made components and SDKs make integrating customer-facing flows a copy/paste affair.

On the downside, some customers will still lack technical proficiency to build these integrations on their own, and integrating components and SDKs within their products will still require engineering effort. Still, a million times better than building them in-house.

More (good) integrations is better

APIs and integrations are still one of the top requirements for SaaS buyers. In a new world of LLMs, agents, and other “AI” capabilities, APIs and integrations will soon become the top requirement for them.

A new, younger SaaS buyer is [becoming integration-first](https://www.canalys.com/insights/transitioning-from-a-channel-chief. They’ve grown up in world of integrated products and services in their personal lives, and now expect the same in the world of work. Not just table stakes.

Integrations are a non-negotiable.

It’s never been easier to build the integrations these buyers need - without building any at all.