Build vs Buy: Which Integration Strategy is Best?

Product integrations are key to keeping clients happy, they’re pivotal to attracting new business, and they provide the moat your platform needs to keep competing vendors at bay.

The question isn’t whether you should build integrations with your product—it’s how you build them. To that end, product managers are often faced with two options: build native integrations, or buy and embed third-party integrations.

How are the two different? And how do you decide which is right for your platform? Like many things, the answer is dependent on a range of factors. We’ll break down those factors so that you can make an informed decision on which you use. We’ll also discuss the benefits and drawbacks of both building and buying so that you can make an informed decision.

What Does It Mean to Buy vs. Build?

When it comes to integrations, you can either build them in-house or you can partner up with a third party and buy them.

Choosing to build integrations in-house means your team develops software that’s specifically tailored to your company’s needs. This not only gives end-to-end control, but you also get to customize functionalities according to your needs. This is ideal if you only want to add a few simple integrations and your engineering team has the capacity to do so.

Opting to buy software means you purchase off-the-shelf solutions that typically need minimal customization. Since the task of developing and maintaining integrations is outsourced, your developers get to focus solely on product development. Plus, in most cases, buying is faster, less resource-intensive, and more cost-efficient.

In today’s rapidly changing tech landscape, the decision to buy vs. build has become very critical for a number of reasons:

• It’s better to buy existing solutions if you want to innovate quickly. However, if you want to have a competitive advantage, building might be the better option.
• With the rise of cloud technology and the high demand for global reach, companies need to consider long-term scalability. While building allows you to tailor scalability, you get instance access to cloud-based scalability if you opt to buy.
• If you’re in an industry with strict regulatory requirements like healthcare or finance, you might want to build custom solutions to control data flow, address specific security needs, and comply with the relevant regulations.

Pros of Buying

• Third-party integrations are scalable and agile, and you can easily add another application to your integration.
• Buying gives your developers the space and time that your development team needs to focus on your core product instead of spending time on unnecessary integration maintenance and overhead.
• It also reduces the delays and difficulties that occur due to process or system changes. Third-party integrations are typically built keeping in mind changes to the underlying system, so they can operate independently of changes.
• Buying helps reduce costs significantly, and there are often different pricing plans to support you in your integration efforts.
• When you opt to buy, you get a dedicated team that maintains the software documentation and provides the necessary training. The team even works with you to troubleshoot your problems and provides the required support.
• You can leverage a variety of reliable and secure integrations out of the box to improve your offerings.

Cons of Buying

• Off-the-shelf integrations usually have a limited collection of integration templates, which means if you have a more advanced use case with detailed dependencies and data mappings, you won’t be able to fully benefit from the solution.
• You might find it difficult to choose the right option considering the numerous options available today.

Pros of Building

• Building allows you to customize the integration to your use case.
• Your team gets complete control over resolving integration issues.

Cons of Building

• Scaling a solution that you built in-house can be quite hard and hinders your integration’s agility.
• The dynamic nature of business environments means that as things change, your integrations should change with them. Your development team has to cater to the changes in the workflows, which can be quite time-consuming and even complex.
• Your dev team has other tasks to do as well and so requests related to integrations might not be at the top of their list, resulting in delays.
• Maintaining in-house solutions can be pretty costly. At some point, you will want to do some upgrades, and to do so, you’ll have to modify existing apps and retest the whole configuration. Plus, the documentation will have to be updated too, which will require more time and effort.

When to Invest in Native Integrations

Though its definition can vary, depending on the context, we’ll treat native integrations as any integration that requires your team of engineers to build directly to another application’s API.

Each native integration involves members of product and engineering who can access an app’s API and, using the documentation provided, write the code necessary to complete the integration.

You should look to implement native integrations when the following scenarios are met:

• Your team only needs to implement one integration. This can be relatively manageable for your team, as it doesn’t require gaining expertise on building to and implementing several complex APIs.
• The integration is critical to your business. Some integrations can fundamentally transform the product or service you offer for the better, while others may fall in the bucket of nice-to-haves. Assuming it’s the former, like an API to the application your product sits within the ecosystem of, the native integration can provide your business with a sustainable competitive advantage. Native integration is also the right choice if you want more control over the code.
• The integration scope is fairly shallow. If you only need a minimal number of capabilities from the integration, the scope of build to an API becomes less complex and is easier to maintain.

Note: Implementing a single native integration can easily open the flood gates to integration requests. As an example, let’s say you implement a native integration with a file hosting service like Dropbox. Clients and prospects who become aware of this and who use alternative platforms—like Box or Google Drive—might request integrations with the ones they use.

When to Invest in Embedded Integrations 

Put simply, embedded integrations are any that get added into your product via an integration platform as a service (iPaaS).

They can be worth implementing when at least one of the following scenarios rings true:

You need to take your integrations to market quickly

Many integrations can significantly improve your team’s ability to attract and retain clients, but lengthy timelines for building each integration threaten to hamper both new business sales and client retention. Embedded integrations directly address time to market by shortening your team’s integration-building timeline from months—if not years—to days.

You need engineers focused on building out your product’s core features

Your engineers are uniquely qualified to tackle challenges that are specific to your product and the market problems you’re trying to solve. This means that moving them off of critical product-specific initiatives and onto integration-related projects fails to leverage their expertise in the most valuable ways. Embedded integrations, however, allows you to get the best of both worlds: engineers can stay on business-critical projects and your team can have the integrations your customers need.

You’re experiencing a high volume of integration requests

As your business expands into new use cases or market segments, you’ll receive integration requests organically and look to build others proactively.

You don’t have the budget to hire engineers who focus on integrations

Engineers who can build to and work with the APIs can, all else equal, command a higher salary. But these highly-skilled engineers aren’t just a strain to your budget—they’re also hard to find and recruit.

Related: Comparing build vs buy across a range of considerations

For the reasons outlined above—embedded integrations don’t require engineering resources and can be taken to market quickly—an embedded iPaaS is best positioned to solve for quantity, without compromising on quality. While an embedded iPaaS does come at a cost, it offers greater economies of scale than native integrations. Why? Because once you’ve connected your product to a modern embedded iPaaS, each integration you add doesn’t require additional headcount or time from your existing dev team.

Related: 3 reasons to invest in an embedded integration platform

Looking to Build Embedded Integrations? Try Workato’s Embedded iPaaS

Workato, the leader in enterprise automation, offers Workato Embedded Platform, an embedded iPaaS that can provide the following (and much more):

• The ability to embed the platform into your UI with a configuration that works for you—users can initiate an automation with the click of a button or customize/build any automation without leaving your platform
• Pre-built connectors and automation templates (“recipes”) so that your clients can implement any integration and automation with minimal customization
• A centralized admin dashboard for monitoring permissions and usage

Conclusion

When it comes to product integrations, you can either choose to build them in-house or buy them from a third-party provider. You now know the pros and cons of each, when to invest in native integrations, and when to invest in embedded integrations. While it’s typically more cost-effective to buy integrations, you need to consider the amount of control you want, the available developer resources, and your integration’s requirements before making the final choice.