%20(1).png)
The way companies are building customer-facing integrations is changing. Recent technological advancements, increasingly competitive market conditions, and the growing importance of connecting SaaS tools have led to a fundamental shift in the embedded integrations space. New and innovative integration service providers, called native integrations platforms, are beginning to replace old and antiquated ways of building user-facing integrations with embedded workflow platforms.
Native integration platforms are unique in that they help you build and maintain integrations entirely in your code, allowing for an unparalleled level of depth and scale. In this way, native integration platforms are a lot more like popular developer frameworks, such as Vercel and Temporal, than traditional embedded integration platforms.
.png)
This is in contrast to incumbent embedded integration solutions such as workflow platforms. These tools are designed for non-technical users and allow you to build integration use cases using action building blocks in a no-code UI. Many of these providers have been around for over a decade and you’ve likely heard of the most popular of these such as Zapier and Workato.
.png)
You can read our previous article if you’re interested in a more thorough explanation and comparison of the types of embedded integration solutions.
In this article, we’ll explore what factors make now a uniquely perfect time for the rise of native integration platforms and why so many companies are switching to them from embedded workflow platforms.
Before we dive into the specifics of why companies are switching to native integration platforms, let’s take a second to explore their advantages and disadvantages.
There are many advantages to using a native integrations platform, but we’ll cover the three most important ones below.
Since native integration platforms expose interfaces for connecting directly to the downstream integration’s APIs, developers have access to all of the functionality provided by an integration. When you use a no-code workflow UI, you’re working with building blocks that offer a layer of abstraction above the native integration’s APIs. While this may be helpful for simple use cases, it means you don’t have access to all of the power of the downstream integration. Native integration platforms like Vessel also provide further useful features on top of the downstream APIs like filtering, schema unification, and automatic retries.
Setting up a traditional no-code workflow platform means learning an entirely new domain and way of building customer-facing integrations. For technical users and developers, this can be a significant hassle since it takes them out of their typical workflows and forces them to learn a new skill set. Since native integration platforms are set up in code, going live is as simple as installing an NPM package and reading some API documentation. This keeps your engineers in the workflows they’re familiar with and allows them to leverage developer-specific technology like Github CoPilot. Additionally, developers can use code to programmatically scale your company's integration breadth; for example, by writing a script that automatically generates the scaffolding for adding a new integration. In contrast, workflow platforms force you to spin up a new workflow every time you want to add a new integration, significantly slowing down the implementation time and creating new management overhead.
Native integration platforms offer a level of flexibility that’s simply unachievable with an embedded workflow platform. Since they’re set up in code and controlled via APIs, native integration platforms provide more programmatic configuration. Additionally, many native integration platforms are OSS so they can be entirely forked and modified to the specific needs of your organization.
Given the strong advantages of native integrations platforms, you might very reasonably be asking yourself: why hasn’t everyone already switched? The answer is, of course, that there are tradeoffs.
Here are a few historical disadvantages to using native integration platforms that have pushed teams toward workflow solutions in the past.
By virtue of being used in code, native integration platforms need to be maintained and used solely by engineers. This is, of course, by design since they’re usually OSS and marketed as developer-first. On the other hand, This typically isn’t an issue with a workflow solution since they’re mostly controlled through a no-code UI. Since code is expensive to write and deploy, it’s easier for a developer or even a non-developer to add new integration features by extending a no-code workflow than by adding new lines of code to a code base.
Native integration platforms are a new way of building user-interfacing integrations. Because they’re new, they also come with several disadvantages that older providers don’t have:
Given the disadvantages above, you may be skeptical of why companies are switching to native integration platforms. After all, it’s pretty clear how existing workflow solutions would help solve some of the aforementioned issues.
However, recent technological advancements and shifting market conditions have created the perfect storm for native integration platforms to disrupt the incumbent workflow solutions.
First, a few key technologies now exist that did not when major workflow solutions like Zapier and Workato were built. Primarily, AI-assisted development means software engineers are at an all-time high for productivity.
At Vessel, we’ve seen firsthand how these changes are erasing the two major disadvantages of using a native integration platform.
The promise of saving on developer time by using an embedded workflow platform is a false one. Even though these platforms offer a no-code workflow builder, your developers still need to add API calls in-code to kick off the workflows. This means not only do developers have to be involved in the integration development process, but they often have to have knowledge of how the no-code platforms work and what each workflow does so that they know when it should be triggered from the code. We’ve seen this further escalate into developers owning the entire integration development process end to end; meaning they have to jump back and forth from the code to a no-code UI to build integration features. With native integration platforms, developers don’t have to leave their usual workflows and can use tools they’re familiar with. This leads to significant improvements in developer velocity and greatly shortens the time it takes your team to launch new integrations and features.
This is especially true with the rise of AI-assisted development which has made software engineers more productive than ever. What used to take developers weeks to build is now taking hours and the more developers can do in-code, the more they can benefit from these AI productivity boosters.
.png)
At Vessel, we’ve also consciously built our API to be better leveraged by AI. For example, we have extensive comments in our SDKs to help LLVMs like Github CoPilot better infer what each method is doing and how it should be used.
Workflow integration platforms aren’t at an advantage because they’re older, they’re at a significant disadvantage. In order to allow your users to fully reap the benefits of an in-code developer-first platform, you need to build your company around it. This means:
Several recent studies (one, two) on SaaS industry trends mention the increasing importance of offering robust customer-facing integration capabilities as a core component of your SaaS offering. This isn’t a coincidence, companies are using more SaaS tools than they ever have before which has led to the continual rise of SaaS sprawl - the phenomenon wherein a single company uses an unmanageably large number of SaaS tools.
In essence, there are just more SaaS tools out there today being used than ever before. If your product doesn’t fit seamlessly in with the existing tool stack a company uses, then your tool is not going to be adopted. Supporting customer-facing integrations provides the best way for your tool to coexist with your customer’s hundreds of other SaaS products. This has led to integrations becoming more important today than they’ve ever been in the past and has skyrocketed the need and demand for integration platforms.
Having a large breadth of customer-facing integrations has become table stakes and is no longer a significant competitive advantage. Instead, companies are beginning to evaluate solutions by the depth of the integrations they provide. We’ve heard from several of our customers about how they’ve managed to win deals over larger incumbents by providing advanced integration functionality that their competitors couldn’t support. No matter how great your product is, if it doesn’t interface deeply with your customer’s other tools, then it’s not competitive.
The only way to achieve the level of depth necessary to beat your competitors is to invest in native integrations. These integrations are done in-code either through the integration’s APIs directly or a native integration platform like Vessel and allow you to access functionality that would never be available through a no-code UI workflow platform.
If you’ve made it to this point, you’ve likely recognized the advantages of using a native integrations platform for your user-facing integrations, but you may be skeptical of switching due to development and logistical costs. Thankfully, switching is likely far easier than you’d think.
When my co-founder and I were developers, we hated setting up developer tools and frameworks that had overly complex onboarding. That’s why we’ve purpose-built our onboarding process for ease and speed of setup. Everything from the self-serve API key issuing to the shape of our RESTful APIs is designed to be familiar and easy and Vessel is often set up end-to-end by a single developer in an afternoon. Here’s a quick rundown of the steps:
No talking to sales, no learning some no-code UI, no infrastructure to set up - just install a few npm packages, read one page of documentation, and start supporting deep user-facing integrations in a matter of minutes.
If you’re interested, feel free to get started by making an account on our website or reach out at zach@vessel.dev