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.
What is embedded iPaaS?
An embedded iPaaS is an integration platform that enables a SaaS company to quickly build integrations connecting its product to the other apps its customers use and deliver those integrations as an integral part of its product. It handles everything that breaks at scale (so your team doesn't need to reinvent the wheel).
It is called "embedded" because it includes an integration marketplace, integration designer, and workflow builder that SaaS teams can white-label and embed in their product to create a self-activated, in-app integration experience for end users. When using the right embedded iPaaS, your customers won't realize that those features aren't part of your product.
It empowers everyone from non-devs (onboarding and support) to devs to customers, allowing each to build, deploy, and maintain integrations as necessary to support the best way to manage integration processes for your company.
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 – Since 80% of the code for every integration isn't the business logic, but the back-end (authentication, error handling, rate limiting, automatic retries, etc.) provided by an embedded iPaaS, your engineers will need to write much less code. And, with a low-code integration designer, non-devs can handle simpler integrations. Support has much greater visibility into integrations via dashboards, ensuring that engineering is only pulled into problem resolution for truly complex issues.
- Customer UX – An embedded iPaaS brings integrations into the light. From the integration marketplace to configuration, monitoring, and troubleshooting, you can place your customers in control. You can even empower them to create workflows for those one-off integration scenarios that tend to spoil your roadmap. As a result, customers are far more invested than when those integrations were black boxes whose secrets were known only to your engineering team.
- 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.
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.
Download 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.
