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 integration?

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 top of 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.

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.

You need to improve the integration experience for your 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.

Potential concerns with buying an embedded iPaaS

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:

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-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.

Cloud security considerations

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.

Viability of embedded integration platform vendor

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.

Concerns your engineering team might have

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:

Low-code platform limitations

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 as easy for developers 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 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.

Developing native integrations in-house

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? 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?

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.

Jump-start your native integrations

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.

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 developers 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 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 everything. Technical non-developers 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 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."

Leverage a vendor's integration expertise

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. But the platform also makes the coding a natural part of creating the native integration instead of an afterthought. Your developers should be able to write whatever code is needed without being constrained by the low-code builder.

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.

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.