Native Integration: A Guide to Building vs Buying Native Integrations
Native integrations improve the customer experience for B2B software companies. Should you build integrations in-house, or buy an embedded integration platform?
Download the Build vs Buy Guide
Get a copy of this guide to save for later or share with your SaaS team.
Building or buying to add functionality to your SaaS product is an evergreen question. You have undoubtedly answered the question several times in the last few years. Your answer may not have been the same every time, for a good reason. You're trying to stay on track with an approach that allows you to keep building the functionality that differentiates your company. Determining how to support your customers' integrations is vital to that strategy.
When it comes to integrations, things have never been busier. The market is moving too fast for your app not to have native integrations with your customers' other apps. The question is not if your customers need integrations but what strategy you will use to build them. Will you build those integrations and the required integration tooling using internal resources?
Or will you leverage an embedded iPaaS with a purpose-built integration marketplace? Put another way, what's the best way for you to streamline workflow automations for your customers and enhance their user experience?
An integration is a connection between two apps or systems to exchange data. A native integration extends an app so that users cannot tell where the app stops and the integration starts.
Some define native integrations as only those built in or on your app using your internal development resources. Others define them as those integrations which connect two APIs. But whether you use internal resources, external resources, APIs, or something else is unimportant. The customer considers the native integration a feature of your app.
Native integrations are terrific features for your app, but they can have some negatives:
- It is time-consuming to build the UI and functionality that dovetails with your core app.
- Native integrations often need investment in further infrastructure and tooling.
- Since your customers use many different apps, you must keep building once you do one native integration.
- Changes to integrations may drive changes to your core app or API.
On the positive side of native integrations:
- You can control the integration quality and associated customer experience, including customer support.
- Every native integration your customers rely on makes your app stickier and the customer more unlikely to churn.
- Native integrations increase product value for your customers, allowing them to do more with your app.
- Since native integrations are first-class app features, you can charge for the value they provide.
An embedded integration platform, or embedded iPaaS, is a set of tools that enables software companies to build reusable, configurable, native integrations and deliver them to your customers as a seamless part of your application.
A comprehensive embedded iPaaS includes:
✓ A low-code integration designer that empowers non-developers to build productized integration workflows that can be configured and deployed to multiple customers.
✓ A library of built-in components that reduces the effort of building integrations by providing connectivity to many common SaaS apps and standard integration logic functions without the need to write code.
✓ An integration marketplace that teams can white-label and embed in their product to provide a self-activated, in-app integration experience for end users.
✓ An embedded designer that enables customers to build their own integrations between a software company's B2B SaaS product and the customers' other apps.
✓ Integration deployment and support tools that enable customer-facing teams to configure, deploy, monitor, and troubleshoot customers' integrations without engineering involvement.
✓ A cloud infrastructure that runs integrations and handles scalability, security, and compliance concerns.
There are times when building integration functionality for your B2B software in-house is the correct answer. Here are some scenarios:
You are working with a small number of native integrations. Building out the functionality you need with internal resources does not require a significant investment.
Your customer integrations are straightforward. For example, you send a notification email when a user flags a record as "urgent" in your application. As a result, handling this integration yourself does not cost much.
Your product is the integration. The integration is the fundamental purpose your product serves for your users and sits at the heart of your value proposition. In that case, building the complete integration experience yourself makes sense.
If all integrations were simple, and we only had a few of them, embedded iPaaS wouldn't exist. Here are a few scenarios where buying an embedded iPaaS is better than building a SaaS integration platform in-house:
You need to support integrations that are both standard and bespoke. You have simple integrations (for example, you send a Slack notification every time your app creates a new customer account). But you also need to support integrations whose requirements change based on real-time data logic. Sourcing native integrations like this in-house requires extra short-term and long-term engineering resources.
"All the complexities with security/token management are handled for you and there is a great user interface to populate customer-specific configurations."
Anonymous G2 Reviewer
You had your approach to customer integrations working well enough. However, as your market expands and you reach scale, you have identified many long-tail integrations. Or perhaps your product is new to the market, and you've learned that native integrations are more important than anticipated. Still, you prefer not to slow the core product development team or hire more devs to build integrations.
"Allows us to integrate with many systems and allows each of our customers to easily authenticate to bring in their data."
Joe H., Software Engineer
Your integration experience needs to be a first-class part of your product. This allows your team and customer users to perform setup, configuration, testing, deployment, and support tasks. At the same time, native integrations have become table stakes. Your customers expect you to have them and that they will work: every time. To ensure the best user experience, you cannot afford for the integrations to seem like a product afterthought.
"The embeddable marketplace and user configuration wizard offers an enhanced user experience that we cannot deliver ourselves."
Justin B., G2 Reviewer
Perhaps one or more of these "why buy" factors applies to your situation. As a product leader, you may have a few concerns to address before you go with an embedded iPaaS:
Question: What will an embedded iPaaS do to the speed at which you develop and release new functionality?
Answer: Redirecting integration development to non-developers will likely enhance your time-to-market, particularly for integrations. You can release them on a flexible schedule instead of waiting for primary product releases. Developers are free to dedicate their efforts to core product functionality.
Question: Using a third-party tool that lives in the cloud might carry some security risks. How does an integration platform vendor handle security and compliance?
Answer: Integration platform vendors understand that your customers' sensitive data flows through your integrations. An embedded iPaaS vendor scans, audits, and updates cloud servers and ensures that integrations run in secure, isolated environments. Also, the vendor should encrypt everything (both in transit and at rest) and handle auth. And the integration platform vendor should be SOC2 certified.
Question: There are several vendors in the embedded iPaaS space. How do you pick one that will be around for the long haul?
Answer: It should have a single focus on native integrations rather than it being peripheral to the vendor's core business. It should have an API and other tools to ensure that code is easily accessible and exportable for use elsewhere. Code generated by the embedded iPaaS should be in a standard format, making it easier to move to another platform. Finally, the integration platform vendor should be as up-front as possible about its market position and plans.
You are not the only one who has concerns. Your engineering team will ensure that your integration approach will work. Developers live to fix problems, so it is no surprise that they are also pretty good at identifying them. Here are a few questions they may have:
Question: Many developers are skeptical of the usefulness of low-code tools. Will an embedded iPaaS strand developers 90% of the way to a solution but make the last 10% nearly impossible?
Answer: There is infinite variety in the world of integrations, and low-code has limits. An embedded iPaaS should recognize this and make it easy for developers to write code for that last 10%. The software platform must be flexible enough to support your dev team.
Question: Your engineering team has likely spent years fleshing out the development ecosystem with its tools and processes. How will an embedded iPaaS fit into that ecosystem?
Answer: An embedded iPaaS should be straightforward to incorporate into your ecosystem and allow you to store the code for custom components in your source control. This supports routine unit testing and deployment for integration code. The embedded iPaaS should stream integration logs and metrics to a log service and send issues to notification systems.
Question: Your developers might have had painful experiences building native integrations. They know that solving integration issues is hard. How will someone who is not familiar with your domain be able to come in and figure things out quickly?
Answer: The key is that the integration platform vendor does not need to know your domain – you are the expert on that – but it does need to know the world of integrations. There are noticeable business differences between verticals and much variety across integrations. As a result, there is a real benefit to working with an integration solution vendor with broad market experience. Often, the vendor will have solved integration issues your team has yet to address.
Question: Finally, if you were to ask your developers if they could build the needed native integrations and integration tooling for your customers, the answer would almost certainly be "Yes." They might ask, "why do we need a third party?"
Answer: Given proper time and resources, your engineering team could most certainly build an embedded iPaaS. But is using your team to create your SaaS integration platform the best use of dev skills? Would it not be better if you could keep your developers focused on the stand-out features of your app? If you create an integration platform in-house, will the engineers who wrote the system be around in five years?
On the face of it, building out your B2B application to support native integrations seems straightforward. After all, an integration moves data from A to B, right?
Building a handful of native integrations is easy enough, but building dozens or scores of them for hundreds of customers? Creating the framework that makes it all work together flawlessly? Setting up infrastructure that does its job perfectly in the background? Making configuration and troubleshooting as accessible as possible for the customers?
A mature embedded iPaaS should allow you to stop spending time on integration infrastructure and tooling and start delivering the best possible integration experience to your customers.
An embedded integration platform comes with what you need to get up and running with integrations immediately. From an intuitive integration designer, to pre-built integration components, to the integration marketplace, to built-in auth handling, to the scalable infrastructure – everything is ready for your customer-facing teams to implement native integrations in days rather than weeks or months.
Time-to-market for new features/functions often makes the difference between your sales team reaching sales goals and exceeding them. Using a native integration solution can substantially increase your integration deployment velocity.
Integration projects are often challenging to define well. Your customer or the integration partner may change requirements at any time. An embedded iPaaS allows you to iterate rapidly to meet these needs. Instead of rebuilding a native integration from scratch, your team can easily swap out components and retest everything in seconds with the built-in testing tools.
You need to know where your resources will do your business the most good. When your developers spend considerable effort on native integrations, that can slow down time-to-market for your app's core features.
One benefit of an embedded iPaaS is that your customer-facing teams can do much of the integration work (such as onboarding and support). This ensures that when questions arise about integrations, the first people to be notified are the ones who can answer the questions. Most of the time, there is no need to get engineering involved.
It is not uncommon for someone to say, "but what if we get more customers than we are expecting?" with an answer of "that's a good problem to have, but we'll deal with it when we get there." Such success can be crippling in the short term, especially if it means scaling infrastructure. But an embedded iPaaS is purpose-built to scale, ensuring that everything works when you go from managing a handful of integrations to hundreds of them.
Costs almost always seem to go up instead of down. Fortunately, leveraging an embedded iPaaS is a good way to keep your native integration costs under control.
Start-up costs: If you build your own integration solution, you must set up infrastructure in addition to an integration designer, application connectors, logic components, and an embedded marketplace. This infrastructure, whether local or cloud, requires technical oversight to keep working correctly.
Your team may also need to address additional security and compliance issues. But using an embedded native integration platform means that the integration platform vendor has already addressed those start-up costs.
Ongoing costs: When you add functionality to your application, your company owns (and supports) it forever. Native integrations are no different. When initially specifying and building integrations, it is common for SaaS companies to overlook long-term support costs. We get the idea that we'll set up an integration, and it will just work. However, this is not what usually happens.
Using an embedded iPaaS to create, deploy, and maintain your customer integrations lets you address changing needs. And you can do this without your team re-writing code every time there is a change to the integration partner's API or your customer's requirements.
People costs: Good developers are expensive. By the time you assemble a development team for your core product, you will have made a significant investment. On top of that, you may need to hire more developers to build the functionality for the native integrations your customers need.
One of the features of a mature embedded iPaaS is that much of the technical work is abstracted away from things like infrastructure, authentication, configuration, and component assembly. This means developers don't need to handle most of the work of integrations. Technical non-developers can perform 80 to 90% of the integration work – from onboarding through support.
Whether you and your team have worked on your products for months or years, your team does certain things better than anyone else. Allowing your team to focus on these makes the most of limited resources.
Solve unique product problems. Your company is probably in business because of one or more products that give you a competitive edge. You maintain that edge by solving unique problems for and with your application. If your developers work on issues that are not unique to your company and its products, you may be squandering resources.
Move beyond the proof of concept. POCs are probably easy for your team to build. By definition, a POC usually addresses the most straightforward use case. However, it is another matter to build into your embedded iPaaS all the functionality that makes users happy to work with it. An integration platform vendor solves difficult use cases by proactively building functionality to enable complex integrations.
Don't get stuck at "good enough" integration tooling. It is often hard for teams to justify the engineering time and expense of building a SaaS integration platform that is more than "good enough." While the integration solution may meet minimum requirements, your team may not have enough time to build deployment and support tools for customer-facing teams. An ideal embedded iPaaS goes well beyond "good enough."
While all integration platform vendors have varying functionality, an ideal SaaS integration platform vendor should allow you to do the following:
Start with a comprehensive integration toolset. When we think about integrations themselves, they are only the tip of the iceberg. An embedded iPaaS vendor is constantly improving its integration platform to ensure that users can build a wide range of native integrations.
Save time with pre-built components. An integration platform needs to include pre-built components (or API connectors). They give you a head-start when building your own components, whether by reusing them or following component patterns. In addition, you shouldn't need to build components for standard SaaS applications.
Write code when you need to. Integrations are complex. An ideal integration platform recognizes that sometimes developers need to write code for the last mile of an integration. But the platform also makes the coding a natural part of creating the native integration instead of an afterthought. Your developers can extend the platform if your app needs to integrate with industry-specific apps or requires unique integration logic.
Benefit from the single focus of an integration platform vendor. A mature integration platform vendor brings a powerful focus to bear on your integration needs. There is enormous value in working with an integration team whose entire focus is the universe of native integrations. Such a team does not only understand the "what" of integrations, but the "who, when, where, why, and how." Business needs change quickly, often more rapidly than internal teams can handle. An integration platform vendor dedicated to native integrations for B2B SaaS companies can keep pace with needed changes.
Some parts of your application make sense to build in-house. For many B2B software companies, native integrations and integration tooling do not belong in that category. A third-party SaaS integration platform lets you use the best tools for your customers' native integrations. At the same time, your primary focus remains on your core application, where it ought to be.
Please contact us to discuss in detail the value Prismatic can bring to your integrations.