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?
What is a native integration?
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 vendors define native integrations as only those built in or on your app using your internal development resources.
But from your customers' perspectives, the tools and platforms you use for the integrations they need with your product are unimportant as long as those integrations function as first-class features of your app.
What are the pros and cons of native integrations?
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.
What is an embedded iPaaS?
An embedded integration platform, or embedded iPaaS, is a set of tools that enables you to build reusable, configurable, native integrations and deliver them to your B2B SaaS customers as a seamless part of your product.
An embedded iPaaS includes:
- A low-code integration designer that empowers your non-devs to build productized integrations to be configured and deployed to multiple customers.
- A code-native integration building experience that enables your devs to use their favorite IDEs to code productized integrations to be configured and deployed to multiple customers.
- A library of built-in components of reduces your team’s work by providing connectivity to common SaaS apps and standard logic functions without writing any code.
- An integration marketplace that provides a self-activated, in-app integration experience for your customers when embedded and white-labelled in your product.
- An embedded workflow designer that enables your customers to build custom integrations between your B2B SaaS product and the customers' other apps.
- Configuration and deployment tools that enable your onboarding team to configure and deploy customers’ integrations without engineering involvement.
- Monitoring and management tools that enable your support team to monitor and troubleshoot customers' integrations without engineering involvement.
- Customer self-serve support tools that empower your customers to configure, activate, monitor, and troubleshoot their integrations without support or engineering involvement.
Finally, all of this is built on a cloud-native infrastructure that runs the integrations and handles scaling, security, and compliance.
When to build your own integration platform
There are times when building integration functionality for your B2B software in-house is the correct answer. Here are some scenarios:
You only have a few integrations
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 integrations aren't complex
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.
An integration is the core of what you provide
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.
When to buy an embedded integration platform
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:
Your integrations are complex
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.
You have a lot of integrations
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."
You need to improve the integration UX for customers
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.
Concerns you may have
Perhaps one or more of these "why buy" factors apply to your situation. As a product leader, you may have a few concerns to address before you buy an embedded iPaaS:
Product development speed
Question: What will an embedded iPaaS do to the speed at which you develop and release new functionality?
Answer: Redirecting integration development to non-devs 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. Devs are free to dedicate their efforts to core product functionality.
Cloud security considerations
Question: Using a third-party tool that lives in the cloud might carry some security risks. How does an embedded iPaaS vendor handle security and compliance?
Answer: Embedded iPaaS vendors understand that your customers' sensitive data flows through your integrations. The vendor scans, audits, and updates cloud servers and ensures that integrations run in secure, isolated environments. Also, the vendor encrypts everything (both in transit and at rest) and handles auth. And the vendor should be SOC2 certified.
Viability of embedded integration platform vendors
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 vendor should be as up-front as possible about its market position and plans.
Concerns your devs may have
You are not the only one who has concerns. Devs 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:
Low-code platform limitations
Question: Many devs are skeptical of the usefulness of low-code tools. Will an embedded iPaaS strand your devs 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 as easy for your devs to code integrations in their favorite IDEs as it is to use the low-code designer.
Fit with the development ecosystem
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 integrations in 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.
Domain knowledge
Question: Your devs 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 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.
Developing native integrations in-house
Question: Finally, if you were to ask your devs 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 to be involved?"
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 devs focused on the stand-out features of your app? And, if you need your devs to write code for integrations, shouldn't they do so with a platform that handles integration testing, deployment, and support?
Benefits of buying an embedded iPaaS
On the face of it, building out your B2B application to support native integrations seems straightforward.
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?
An 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.
Let's see how that works.
Jump-start your native integrations
An embedded integration platform comes with what you need to get up and running with integrations immediately. From a low-code integration designer, to pre-built connectors, 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.
Keep integrations moving quickly
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.
Flex with changing requirements
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.
Make the most of limited resources
You need to know where your resources will do your business the most good. When your devs spend considerable effort on native integrations, that can slow down time-to-market for your app's core features.
Let your customers serve themselves
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.
Get out in front of scaling issues
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.
Keep your costs down
Costs almost always seem to go up instead of down. Fortunately, leveraging an embedded iPaaS is a good way to keep all your 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 iPaaS means that the 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 build, deploy, and manage 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 devs are expensive. By the time you assemble a dev team for your core product, you will have made a significant investment. On top of that, you may need to hire more devs to build the functionality for the native integrations your customers need.
One of the features of an embedded iPaaS is that much of the technical work is abstracted away from things like infrastructure, authentication, configuration, and component assembly. This means devs don't need to handle everything. Non-devs can perform much of the integration work – from onboarding through support.
Work to your company's strengths
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 devs 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 embedded iPaaS 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. A proper embedded iPaaS goes well beyond "good enough."
Leverage a vendor's integration expertise
While all integration platforms have varying functionality, a SaaS integration platform 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 often complex. Sometimes devs need to write code. As a result, the platform should also make coding a natural part of creating the native integration instead of an afterthought. Your devs should be able to write whatever code is needed without being constrained by the low-code builder.
Benefit from the vendor's single focus. There is enormous value in working with a vendor 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 embedded iPaaS vendor dedicated to enabling native integrations for B2B SaaS companies can keep pace with needed changes.
Use the best tools for your integrations
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.
Schedule a demo to see how our integration platform can supercharge your integration efforts.