Whether you should build or buy to add functionality to your B2B software for your customers is an evergreen question. It is likely that you have answered the question a dozen different times in the last few years. Your answer may not have even been the same every time, for good reason. You’re doing your best to stay on track with an approach that allows you to keep building out the functionality that differentiates your company in the marketplace while ensuring that you meet current customer requirements. Determining how you will support your customers’ integrations is a key part of that overall strategy.
When it comes to integrations, things have never been busier. Business is simply moving too quickly for your customers’ systems to not have native integrations with your product. As a result, the question is not whether your customers will need integrations, but what strategy you will use: building those integrations and integration tooling using internal resources, or leveraging an embedded iPaaS with a purpose-built integration marketplace?
An embedded integration platform, or embedded iPaaS, is a set of tools that enables software companies like yours to build reusable, configurable integrations quickly 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, as well as common 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.
✓ 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 provides handling for concerns such as scalability, security, and compliance.
There are times when building customer integration functionality for your B2B software in-house is absolutely the right answer. Here are some scenarios:
You are working with a small number of customer integrations. Building out what you need with internal resources does not require a large investment on your part (for development, infrastructure, or support).
Your customer integrations are very simple (example: when a user flags a record as “urgent” in your application, you send a notification email). Much like with a very small number of integrations, handling this internally does not require much in the way of resources.
Your product is the integration. If the integration is the fundamental purpose your product serves for your users and sits at the very core of your value proposition, it likely makes sense to build the complete integration experience yourself.
If all integrations were simple, and none of us had to deal with more than a handful of them, embedded iPaaS wouldn’t exist. Here are a few scenarios where buying an embedded iPaaS from an integration platform vendor may serve your product and your customers better than if you were to build an integration platform in-house:
You need to support integrations which are both standard (common) and bespoke. You have simple integrations (example: send a Slack notification every time a new customer account gets created) but you also need to support integrations whose requirements change based on real-time data logic, or integrations which are sending data to multiple endpoints simultaneously. In short, sourcing these integrations in-house is going to require much more in the way of resources, both short-term and long term.
You previously had your approach to customer integrations working well enough. However, as your market expands and you reach scale, you have identified numerous additional long-tail integrations which will need to be created for customers to successfully implement your product. Or, perhaps you are newly arrived in the market with your product and realize that integrations are going to be a much more important part of your go-to-market plans than originally anticipated, but you would rather not slow the core product development team or spin up an additional team to handle these new integrations.
Your integration experience needs to be a first-class part of your product, allowing your team members and customer users alike to be able to easily interact with integrations for purposes of setup, configuration, testing, deployment, and support. At the same time, integrations have become table stakes. Your customers expect that you’ll have them and that they are going to work: every time. As a result, you cannot afford for the integrations to seem like a product afterthought.
Perhaps one or more of these “why buy” factors applies to your situation. However, as a product leader, you likely have a few concerns that need to be addressed before you make the decision to implement 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 within your company is likely to enhance your time to market, particularly with reference to the integrations themselves. You will be able to release them on a flexible schedule, instead of waiting for primary product releases. Your integrations will get done when they are needed, instead of being relegated to the engineering backlog. Developers will be freed up to dedicate their efforts to core product functionality.
Question: Using a third-party tool which lives in the cloud sounds like it might have some security risk. How does an integration platform vendor address security and compliance?
Answer: Integration platform vendors understand that your customers' sensitive data flows through your integrations, and security is a first-class consideration. From frequently scanning, auditing and updating cloud servers, to ensuring that integrations and custom code run in secure isolated environments, to making sure everything is encrypted (both in transit and at rest), to built-in authorization, user credential handling – the embedded iPaaS has security covered. In addition, the integration platform vendor should be certified for SOC2, ensuring that you are not simply taking the vendor’s word for its approach to security.
Question: There are several vendors in the embedded iPaaS space. How do you pick one which is going to be around for the long haul?
Answer: There are a few indicators that an integration platform vendor is doing everything it can to protect your long-term investment. It should have a single focus on integrations, rather than it being peripheral to the vendor’s core business. It should have an API and other tools enabled to ensure that any custom code your team writes is easily accessible and can be exported for use elsewhere. The code generated by the embedded iPaaS should be in a standard format, making it easier to move to another platform or approach, should that be required. Finally, the integration platform vendor should be as up-front as possible with reference to its position in the market and future plans.
You are not the only one who has concerns. Your engineering team, after all, will be responsible for ensuring that whatever approach you take to integrations is going to work. Developers are wired to fix problems, so it comes as little surprise that they are also pretty good at identifying them:
Question: Many developers are skeptical of the usefulness of low-code tools due to previous experiences working with low-code solutions that simply weren’t powerful enough to do the job. Will an embedded iPaaS leave developers stuck with a toolset that lets them get 90% of the way to a solution but makes the last 10% nearly impossible?
Answer: With a mature toolset for native integrations, low-code is an important part of the equation, but it does not stop there. There is infinite variety in the world of integrations. An embedded iPaaS solution should recognize this and include the ability for developers to write code for that last 10%.
Question: Your engineering team has likely spent years building out the development ecosystem with its tools and processes. How will an embedded iPaaS fit into that ecosystem, or will you have to handle it as an exception?
Answer: An ideal embedded iPaaS will be easy to incorporate into your ecosystem and allow you to store the code for custom components in source control, allowing you to unit test and deploy them like everything else. Integration logs and metrics can be streamed to an existing log service and issues can sent to notification systems such as Slack or PagerDuty.
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 intimately 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 – it will rely on you for that – but it does need to know the world of integrations inside and out. While there are obviously business differences between verticals, and there is great variety in the world in integrations, there is a real benefit to working with an integration platform vendor which has broad experience across verticals – and has probably needed to solve for integration issues that your team has yet to address.
Question: Finally, if you were to ask your developers if they could build the needed integrations and integration tooling for your customers, the answer would almost certainly be “Yes.” If so, 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 build your integration platform the absolute best use of engineering skills? Would it not be better if you could keep your developers (with their comprehensive knowledge of your specific vertical) focused on the things in your product that make you stand out from the competition? If you choose to do this in-house, will you still have the engineers who built the system around in five years?
On the face of it, building out your B2B application to support native integrations may seem straightforward. After all, an integration just moves data from A to B, right? As it turns out, the concept of an integration is simple, but the execution often becomes complicated.
Building a handful of integrations may be easy enough, but building dozens or scores of them for hundreds of customers? Creating the framework that makes it all fit 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 will allow you to stop spending time on integration infrastructure and tooling — the “blocking and tackling” that adds little value to your customers — and start focusing on delivering the best possible integration experience for your customers.
An embedded integration platform comes with what you need to get up and running with integrations very quickly. From the intuitive integration designer, to pre-built integration components, to the integration marketplace, to built-in auth handling, to the fully-scalable infrastructure, everything is ready for your customer-facing teams to begin implementing integrations in a matter of days, rather than weeks or months.
When it comes to reasons for buying, keeping things moving at speed is a plus. Time to market for new features/functions is what can make the difference between making sales goals and far exceeding them. Using a native integration platform can substantially increase your velocity when it comes to deploying integrations.
Integration projects are often challenging to define well. Either the customer or the third-party vendor may change the requirements at any time. An embedded iPaaS allows you to iterate quickly to meet these changing requirements. Instead of rebuilding an integration from scratch, the integration platform allows your team to easily swap out components and retest everything in a matter of seconds with the built in testing tools, right in the same UI.
None of us have the luxury of working with unlimited development resources. This means that you need to determine where those resources are doing your business the most good. If your developers are expending considerable effort on integrations, that resource drain could be slowing down your time to market for the core features that your product needs.
One benefit of an embedded iPaaS is that much of the work of integrations can be done by your customer-facing teams (such as onboarding and support). This ensures that when questions arise with reference to integrations, the first people to be notified by the customer are the ones who can answer the question and solve the problem. Most of the time, there is no need to get engineering involved. Addressing customer needs quickly, whether with the initial onboarding or when things have moved to support, ensures that customers remain happy.
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.” The truth is, such success can be crippling in the short term, particularly it means scaling infrastructure. The good news is that an embedded iPaaS is designed to scale, ensuring that if you go from managing dozens of integrations to hundreds of integrations, everything simply keeps working as it should.
Costs almost always seem to go up, instead of down. Fortunately, leveraging a purpose-built embedded iPaaS solution is a good way to keep your integration costs under control.
Start-up costs: If you build your own integration platform, then you will need to set up infrastructure, in addition to all the other pieces (integration designer, application connectors, logic components, embedded marketplace, etc.) This infrastructure, whether local or cloud, will then require technical oversight to ensure that it keeps working exactly as it should.
Your team may also need to address additional security and compliance issues. However, going with a native integration platform built by someone else means that the integration platform vendor has already addressed these start-up costs.
Ongoing costs: When you build out new functionality for your application, that is something your company owns (and supports) forever. Integrations are no different in that regard.
When initially specifying and building integrations, it is very common to overlook long-term costs of support. We have the idea that we are going to set up the integration and it will just work. However, this is not what usually happens. Instead, people change things (sometimes without telling us) and a perfectly good integration no longer works as it used to.
Using an embedded iPaaS to create, deploy, and maintain your customer integrations allows you to easily address the changing needs of specific integrations, without requiring that your team spend considerable effort re-writing code every time there is a change to the third-party API or customer requirements change.
People costs: Good developers are expensive. By the time you have assembled your development team with the right skills and abilities to ensure that you keep your product fresh and headed in the right direction, you will have made a significant investment. On top of that, you may now need to hire more developers to build the functionality to support the required integrations for your customers.
One of the features of a mature embedded iPaaS is that much of the technical work has been abstracted away from things like infrastructure, authentication, configuration, and component assembly. This means you do not need developers to handle most of the work of integrations. They will still be called on to help when the low-code approach needs to be augmented with some real code to solve for a particular integration, but 80 to 90% of the integration work (from onboarding through support) can be handled by technical non-developers.
Whether you and your development team have been working on your products for months or decades, you know that there are certain things your team is going to do better than anyone else. Allowing your team to focus on these things ensures that you are making the most of limited resources.
Solve unique product problems. Chances are that your company is in business because of a product or products which give you a competitive edge in the marketplace. You maintain that edge by solving unique problems for and with your application. If your developers are working on problems which are not unique to your company and its products, you may well be squandering crucial resources. You need your developers to be focused on your core application functionality, not sitting on calls with third parties while spending hours going through less-than-clear API documentation.
Move beyond the proof of concept. POCs are probably easy for your team to build. By definition, a POC usually solves for the simplest possible use case. However, it is another matter entirely to build into your embedded iPaaS all the functionality which makes different users (developers, non-developers, customers) happy to work with it. An integration platform vendor has had to solve for the most complex use cases, which means that the vendor is proactively building out functionality to address difficult integrations.
Don’t get stuck at “good enough” integration tooling. Integrations are not usually high on the list of critical features for a product. As a result, it is hard to justify the engineering time and expense to build an integration platform which is more than “good enough.” While the integration platform may meet the minimum requirements, your team may simply not have enough time to ensure that it includes good deployment and support tools for customer-facing teams. An ideal embedded iPaaS goes well beyond “good enough.” It ensures that that the user experience for your developers and non-developers (such as onboarding and support) is excellent and that as much of the functionality as is possible is available to your customers.
While all integration platform vendors have functionality which varies a bit from one to the other, an ideal integration platform vendor should allow you to do the following:
Start with a comprehensive integration toolset. When we think about integrations themselves, in a sense, they are only the tip of the iceberg. A full-featured embedded iPaaS includes an intuitive integration designer, purpose-built integration infrastructure, an embedded integration marketplace (which allows customers to serve themselves), an API and CLI which allows developers to interact with the embedded iPaaS the way they want and need, and the troubleshooting and logging tools which lets your customer-facing teams fix things quickly. An embedded iPaaS vendor is constantly adding and improving on this functionality, with an eye toward ensuring that everyone who uses the platform (dev, non-dev, and customer end users alike) can implement the integrations which make sense for the application and the customer.
Save time with pre-built components. An integration platform needs to include pre-built components (or API connectors). They give you and your team a head-start when it comes to building your own components, whether through reuse of these components, or using the component patterns to understand how they get assembled to solve for specific integrations. In addition, you simply shouldn’t need to build components for common SaaS applications.
Write code when you need to. Integrations are complex. An ideal integration platform does not only recognize that there are situations where developers need to write code for the last mile of an integration, but rather the platform makes the coding a natural part of creating the integration (instead of an afterthought). If your app needs to integrate with industry-specific apps or requires unique integration logic, your developers can extend the platform as needed for your product and industry. In addition, the code they write can be stored with the rest of your code base so it flows through your standard code management processes.
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. While experts can be overrated, there is something to be said for working with an integration team whose entire focus is on the universe of integrations. Such a team does not only understand the “what” of integrations, but the “who, when, where, why, and how.” If you are interested in implementing a long-term solution for your customer integration needs, an embedded iPaaS vendor should be first on your list. Business needs change quickly, often more quickly than internal teams can handle. An integration platform vendor with a dedicated focus on integrations for B2B software companies can move very quickly with changes in the marketplace.
There are certainly parts of your application that make sense to build in-house; but for many B2B software companies, native integrations and integration tooling do not benefit from being in that category. Taking advantage of a third-party integration platform allows you use the best tools which are available for your customer integrations while ensuring that your primary focus remains on your core application, where it needs to be.
If you would like to discuss in detail the value an embedded integration platform vendor can provide, please contact us.
Prismatic is the integration platform for B2B software companies. It's the quickest way to build integrations to the other apps your customers use and to add a native integration marketplace to your product.
A complete embedded iPaaS solution that empowers your whole organization, Prismatic encompasses an intuitive integration designer, embedded integration marketplace, integration deployment and support, and a purpose-built cloud infrastructure. Prismatic was built in a way developers love and provides the tools to make it perfectly fit the way you build software.