“Let’s be honest, we can no longer ‘do nothing’ when it comes to integration. Our buyers expect our product to integrate with their systems and if it doesn’t they will go elsewhere.” This is a common statement made by engineering, product management and sales leaders at SaaS companies. They realize that doing nothing about integration means they won’t be able to grow as fast as they need to, they’ll miss out on sales opportunities, and they will lose market share to their competitors.
How to tackle the integration challenge is often an emotional, tough question for these SaaS companies to answer. Often SaaS companies look at it as a “buy vs. build” decision with the following two options:
- Build – Create custom, hand-coded, point-to-point integrations between the APIs of both applications.
- Buy iPaaS – Use a cloud-based integration platform, or iPaaS, like Scribe Online, to create custom integrations using the hub and spoke structure of the platform, a marketplace of pre-built connectors that expose application meta data, and graphical design tools.
Let’s consider an e-commerce platform provider. The VP of Product Management might argue that the company should use an iPaaS to address integration needs because:
- Many potential customers have different marketing, sales, and fulfillment systems and it would be a lot of effort to build custom integrations (i.e. write code) to each of their APIs.
- We don’t have time to create numerous hand-coded integrations. Time to market is crucial. The faster we can integrate with all the systems our potential customers use, the faster we open new markets, increase sales opportunities, and increase our close rates.
- Integration, while a requirement, is not our core business. Let’s invest our precious engineering resources on the numerous feature requests for the e-commerce platform itself.
The head of engineering, however, may have a different view. For one thing, writing code to application APIs is not a scary proposition to them. The engineers at the company probably write code in their spare time for pure enjoyment. So they may argue that the company should write their own custom integrations because:
- The quality of the integration can reflect poorly on our product. If it doesn’t do what it is supposed to do then our company’s brand takes the hit.
- If we commit to integrating to a customer’s fulfillment system and we hit a roadblock, I’m confident we can get around it by writing custom code. I don’t know if we can do that if we use a connector that we didn’t build.
Who is right?
We work with many SaaS companies that go through this decision process. It’s considered a very strategic decision for these companies because it affects all departments (sales, product, service, etc.) and it has a direct customer impact.
In the Build scenario, you have total control, but you also have a higher burden when it comes to maintaining integrations, tracking application changes, and building scaffolding to help with alerting, monitoring, and other aspects of lifecycle management. That can limit growth by delaying market expansion and by slowing development of your core SaaS product.
In the Buy iPaaS scenario, you gain a speed advantage by using a library of pre-built application connectors and reducing the custom integration work that is required. You also reduce the maintenance and lifecycle burden because the iPaaS comes with debugging, documentation, alerting, and management tools. To gain these advantages, you do give up some of your control. Although we should point out that unlike many buy vs. build scenarios, the Buy iPaaS scenario still provides a high-degree of control for you to configure integration logic and deliver intricate, custom integrations.
Ultimately, it’s a very personal decision and no two companies follow exactly the same path. I would encourage you to consider the following in your decision:
- Get benchmarks on the full development costs and time required for custom-coded integrations. SaaS companies usually underestimate the costs of developing, testing, and maintaining custom-coded software. Scribe often encounters SaaS companies that choose an iPaaS after first deciding to go down the custom-coding path, only realizing too late that it was more difficult than expected to meet their time, cost, and quality requirements. In fact, as outlined in Overcoming the Connectivity Hurdle: The Business Case for Using iPaaS vs. Custom Coding, the maintenance costs of integrations can be more than twice the initial development costs over a five year period. Plus the cost of custom-coded integrations can be four times the cost of using an iPaaS.
- Evaluate the benefit of accelerated time to market. If you are in a fast-growing market or one where competitors are fighting for market share, getting to market quickly with your integrations can significantly increase the value of your company. If you go down the Build path, it could take several years to build the integrations you need. In the Buy iPaaS scenario you can shorten that time to market to just a few weeks or months. To get an idea of how much this matters, look at your sales leads and evaluate how many potential sales opportunities you missed because of a lack of integration.
- Will your integration be dynamic, even needing to be customize for each customer? If you only need to integrate several fields from one application to another, and you don’t expect that to change over time, the integration may not differentiate your product much at all. In this case, you could probably custom code it and leave it alone for a long time. Though, it is more likely that your integration requires you to send numerous fields in both directions, transform data along the way, create workflows that can affect the customer experience, and adapt the integrations frequently to meet specific customer needs. In that case, you will want something that you can control, and the Scribe iPaaS has the flexibility to support the unique aspects of those integrations without burdening your development team with extra maintenance requirements.
- Consider your packaging and deployment strategy. If you expect to deploy integrations for hundreds of customers, not just a few, you’ll need an efficient way to deploy and maintain integrations. If your integrations will need to be modified to fit the application configuration or business process of your customers, then you will want to use a solution where your team, whether they are developers or analysts, can make the necessary customizations. The Scribe iPaaS can enable business analysts, not just developers, to customize and quickly deploy integrations across your new and existing customer base, which can give your organization a great deal of flexibility. Custom-coded integrations can be packaged for fast deployment, but may be more difficult for analysts to modify.
The decision on whether to go the Buy iPaaS route or Build route is a personal one; depending on your comfort level with your iPaaS platform, the vendor, your technical skills, your deployment strategy and more. Both Buy iPaaS and Build options can give you the ability to differentiate your solution, but Scribe’s iPaaS allows SaaS providers to strike a better balance between control, speed, and cost/time savings.
Check out our additional information on using Scribe to integrate your SaaS product.