Product Manager's Dilemma: Build vs. Buy

By Chase Doelling in Product Managers, SaaS Integration Posted Feb 1, 2018

Integrations have become the easiest way to turn a product into a platform, extending your application's reach by either embedding itself into an ecosystem of applications or creating new ones. A recent research paper found that API adoption predicts a 10.3% increase in a firm’s market value, making API integrations a necessity instead of a nice feature.


Should I build or buy API integrations for my app?

We know integrations are important, but how you approach your integration strategy will also have substantial impacts on how quickly you go to market and claim those future gains. This guide will uncover the hidden nuances in deciding whether to build integrations yourself or to look for an integration platform partner.


Calculate Your Own Buy vs. Build


Where is it on our backlog?

Where do integrations live in your organization, and is the priority the same across departments? Integrations might be seen as a critical component to capture market share in product management but could be seen as a thorny, black-hole in engineering. Integration platforms increase your feature throughput by delivering on your roadmap without increasing development backlogs.

Build: Top priority and you have the capacity in your roadmap & development team

Buy: High priority but lacking the development capacity and expertise

Do we need just a connection or a true {advanced} integration?

The level of interaction you have with the integrated applications matter. Simply getting information from one system and directing it to another is fairly straightforward. Updating, transforming, and orchestrating information that is intertwined with your application and business model is inherently more complex. How will you handle authentication, eventing, and pagination? Which API specification will you use? Do you need to transfer in bulk?

Build: Simple use case of pulling data from one application to another in its original state

Buy: Getting, Transforming, Updating and Orchestrating data to your application

Do we want to handle business logic in app or in API?

Integration platforms have the ability to embed event-based business logic directly into an API, saving development cycles by orchestrating the data based on user activity and data being integrated. If you're thinking about your organization as a car, do you want to focus your efforts on just the core engine or expand the scope to include intake and exhaust?

Build: Let your application handle all logic, even the mundane

Buy: Transforming data and adding business logic directly into an API 

Do we need to build more than one?

We saw that there were 5381 MarTech applications in 2017, meaning your customers are selecting best-of-breed applications to meet their specific needs. As a result, you'll need to have multiple integrations to cover different use cases that are represented from multiple applications. This wouldn’t be an issue if all APIs were made the same, but they're not - far from it. Can your application consume both JSON and XML? Can your application receive webhooks? Even if it does, the majority only allows polling so you’ll need to add a polling logic in as well. Testing environments, sandboxes and SDKs add to the delivery timeline.

Build: Want to live within the ecosystem of one application (HubSpot)

Buy: Want to live within multiple ecosystems (Marketing Automation & CRM)

Who will “own” the integration and maintain it once operational?

Integrations may seem static but are actually quite fluid by nature. You need to define who will own the maintenance from version changes and other updates. You’re not the only one building new features. The source application will have new: resources, fields and logic to take advantage of. Who will take these changes back to the product and with what priority? What if the developers who built it can’t maintain it? The best fire drills are the ones out of your control.

Build: Clear process and ownership of maintaining parity with the source application(s)

Buy: Let the platform capture changes, allowing you to decide your own pace of product change

Do you want speed or experience?

In partnering with an integration platform you also gain the expertise and guidance in the various applications you’re integrating to. In doing so you accelerate your time to market by leveraging other people's experience with those various applications. This trades time in the market having integrations for time your teams would have to spend learning about integrations.

Build: Want to spend more time learning how the application’s APIs work

Buy: Want to spend more time in the market selling the integration

Ultimately when it comes to integrations the decision to buy vs. build becomes: how much time do you want to be building in your application vs. building against other applications. We have seen how accelerating time to market with integrations more than outweighs the cost of bringing in a platform. But don’t take it from us, hear how our customers did it.

Read the Case Study