If you have a B2B SaaS product, you have made (or will make) any number of decisions. One of those decisions used to be whether you would provide integrations with your product.
But the market has moved on, and customers made that decision for you. They expect your SaaS product (and all the others out there) to come with integrations.
The new question is, will you build an integration platform in-house or use a third-party platform (such as an embedded iPaaS) to provide those integrations?
An embedded iPaaS can help accelerate time-to-market, increase deal velocity, and drive greater customer satisfaction and retention. Let's see how that works.
Embedded iPaaS pros
Here are a few of the reasons B2B SaaS teams should implement an embedded iPaaS for integrations:
- Infrastructure – An embedded iPaaS significantly reduces the infrastructure burden on your team. You no longer have to build and maintain the complex, distributed system required to run hundreds or thousands of customer integrations. The embedded iPaaS vendor manages the platform, including the compute resources, databases, and networking for each integration. In addition, the platform scales resources based on customer demand and resolves common issues without manual intervention, ensuring high availability and reliability for your customers.
- Faster time-to-market – You can leverage the platform and features, such as pre-built connectors, to quickly build integrations with common apps your customers use. Instead of telling customers that you'll be able to build their integrations in a few months (or longer), you can have those integrations ready in weeks.
- Engineering relief – Because roughly 80% of the code for every integration consists of standard infrastructure (like authentication, error handling, rate limiting, and automatic retries), building each integration by hand creates long lead times and large development backlogs. An embedded iPaaS moves integrations out of the backlog and into a managed layer of your product, allowing your team to shift from building one-off integrations to managing a scalable platform. Your engineers write far less code and can focus purely on customer business logic and SDKs rather than rebuilding infrastructure. Integrations that once required months to scope, build, and test are compressed to days, allowing teams to reclaim substantial engineering time. Additionally, a low-code integration tool lets non-devs assemble simpler integrations, while customer-facing configuration UI and support dashboards give non-engineering teams greater visibility, so developers are pulled in when their specific skills are needed.
- Customer UX – An embedded iPaaS brings integrations into the light by providing a rich, self-service experience directly inside your app. From an integration marketplace to self-service configuration, monitoring, and troubleshooting, you can put your customers in control. This configuration layer lets customers safely create their own workflows without opening up your codebase or increasing technical risk. As a result, customers are far more invested than when integrations were black boxes whose secrets were known only to engineering. However, because every exposed configuration option creates edge cases, be deliberate about how much control you expose to keep customer support manageable while delivering a first-class user experience.
- Security and compliance – An embedded iPaaS is built with security and compliance in mind. Compliance certifications for frameworks such as SOC 2, GDPR, HIPAA, and CJIS are already in place. Compute and databases are hosted in private VPCs (instead of directly on the public internet). Data is encrypted at rest and in transit. And everything comes back to a zero-trust security posture.
Embedded iPaaS cons
Here are a few of the reasons B2B SaaS teams often consider building an integration platform in-house:
- Vendor risks – If you use an embedded iPaaS, you depend on that vendor's roadmap. In addition, you are constrained by the platform's capabilities, and platform downtime may leave you in a position where your customers have issues, but you have to wait for someone else to fix them. Of course, building in-house doesn't remove third-party dependencies and considerations from integrations. You'll still need to connect with third-party APIs (over which you have no control). You may also need to leverage third-party code libraries and third-party computing resources. In short, the chances of you building everything in-house with no outside dependencies are slim to non-existent.
- Technical limitations – Every embedded iPaaS comes with things it does and stuff it doesn't do. The specific connectors provided by one platform differ from those offered by another. Some platforms support a low-code development approach. Others let your devs build in code, but restrict the languages and frameworks they can use. Some platforms have lots of functionality available for your customers, and others don't. At the same time, while building in-house theoretically allows you to create any functionality you want, you'll still have technical constraints. It isn't feasible for your team to build connectors to the thousands of possible third-party apps, so you'll need to prioritize. You could build all the customer-facing UI, but doing so without adding headcount is likely to pull devs off core app projects. There are always limitations.
- Financial considerations – You know what costs come with an embedded iPaaS at the time of contract, but every platform has different pricing. Some are more straightforward than others. Some pricing scales with usage or customers, making cost projections easier. What will things be like in a few years, when you have 10x the customers and 30x the integrations? Compared with this, internal costs could seem more manageable. While you don't have the embedded iPaaS licensing fees when you build integrations internally, you'll still have costs. Things like cloud-based servers and other tools/systems you use for building, deploying, and managing your integrations. Then there are the people costs. Building internally generally requires senior devs (and they don't come cheap).
- Implementation challenges – Any new tool has a learning curve. An embedded iPaaS is no different. How easy is it for your devs to work with it? How about your non-devs? Are customers able to easily understand their interactions? Do customers even have an integration UI optimized for their use? How easy is it to hook the embedded iPaaS into your CI/CD pipeline? We could ask similar questions about what you might do internally if you built integrations in-house. Integrations have specific auth, encryption, and other security and data compliance needs. Implementing integrations is an involved process, whether you use internal tools or an embedded iPaaS.
You can build a moat without building a platform
Rich, reliable integrations are among the most durable competitive advantages in B2B SaaS, as they become fully embedded in how those customers operate. A customer who has built workflows around your Salesforce integration, configured field mappings to match its data model, and trained its team on the experience has real switching costs.
This product stickiness compounds over time. Every integration you add, and every month a customer relies on it, deepens the cost of moving away from the value you provide. Customers considering competitors with more attractive pricing or a flashier feature set run into the reality that moving also means rebuilding workflows and retraining people. Historically, building integrations to drive this required a dedicated platform team, engineers whose job was to build, deploy, and manage the integration layer (including infrastructure). At scale, this requires multiple senior engineers. An embedded iPaaS lets you have the integrations (and the platform) without the headcount. You get the strategic benefit of the integration platform without the investment required to code it from scratch.
But, the moat only forms around integrations that work every time. Inconsistent or unavailable integrations don't create lock-in. Instead, they provide customers with an excuse to churn. Customers whom non-functioning integrations have burned remember them, and they bring them up at contract renewal. Operational quality is key. Monitor your integrations. Set up alerting. Pursue integration uptime the same way you do core product uptime.
Should you use an embedded iPaaS?
That decision is yours. And it's critical. A proper integration strategy can help your integrations (and product) stand out from the competition.
Most B2B SaaS companies will benefit more from using an embedded iPaaS for integrations than from building those integrations in-house. However, some teams have particular constraints and requirements and should build integrations in-house to meet those needs.
Check out our build vs buy guide for much more detail on whether building in-house or using an embedded iPaaS is best for you and your customers.
