Updated on by Daniel Twigg
When product teams evaluate embedded integrations, the conversation often starts with a simple question:
“Should we build our integrations internally or buy an embedded integration platform?”
In many markets the concept of ‘Build or Buy’ abstracts well and a choice between one or the other is easy. At first glance, building appears cheaper. After all, you already have developers on payroll and complete control over the architecture.
But the upfront development cost is only a fraction of the total investment.
The real expense comes from maintaining, updating, monitoring, troubleshooting, and scaling dozens or eventually hundreds of API connectors over time.
That’s why many SaaS companies eventually discover that the cost of maintaining internal integrations far exceeds the cost of purchasing an embedded integration platform.
What Types of Integration Solutions are Available?
We believe there are three viable ways to solve your SaaS integration needs. Jumping to the conclusion, we are going to recommend that you pick at least two.
Outsource Integrations
Outsourcing integrations involves deploying a ring-fenced solution that achieves the customer’s integration off-platform. A good example of this is Zapier.
What are the benefits and disadvantages of buying an outsourced integration solution?
The benefit of buying a third-party, off-platform, solution is that it is massively scalable, and agile, without disrupting your UI.
The downside is that you are not necessarily addressing your customer’s integration requirements at the ‘point of need’, the burden is on the customer to resolve any complexity.
Build Native Integrations
This option is where you start from scratch and write code to achieve each integration.
What is the benefit and disadvantage of building your own integrations?
The benefit of building your own bespoke solution is that you own 100% of the code and you directly address a precise solution for your end customers. You are meeting their needs directly in a handcrafted manner.
The downside is that these integrations can be fragile and the cost of the human resource expense to resource and maintain the integrations is high. It is a challenge to scale and is not particularly agile.
Why Native Integrations Become More Expensive as You Scale
Imagine a SaaS company with:
- 15 existing integrations
- 2 new integrations released every month
- An average developer salary of $100,000
If each integration takes approximately 15 days to build, the company spends roughly 30 developer days every month simply delivering new integrations.
Maintenance adds additional engineering overhead on top of that.
As the integration portfolio grows, maintenance scales almost linearly.
Every new connector increases:
- Technical debt
- Testing requirements
- Support complexity
- Monitoring requirements
- Upgrade cycles
The result is that engineering teams spend an increasing percentage of their time maintaining integrations instead of building core product functionality.
Design Integrations
This option involves designing integrations using an iPaaS platform, such as Cyclr, that is embedded within your platform
What is the benefit of designing integrations with an Embedded iPaaS toolkit?
The benefit of designing integrations in a solution such as an embedded iPaaS is that it provides the low-code environment and components needed to build connectivity. This means your focus can be to design the customer solution whilst the technical code work has already been done on your behalf.
iPaaS solutions tend to be both agile and scalable whilst also resolving the customer’s need at the point of requirement.
Cost of Building vs Buying an Embedded Integration Platform
Let’s compare the two approaches.
Building Internally
With a native approach, your team owns:
- Connector development
- Infrastructure
- Authentication handling
- Monitoring
- Error management
- Data mapping
- Maintenance
- Security updates
You gain complete control, but every integration becomes a long-term engineering liability.
Buying an Embedded Integration Platform
An embedded integration platform typically provides:
- Pre-built connectors
- Authentication management
- Monitoring and observability
- Multi-tenancy
- Connector maintenance
- Standardized APIs
- Error handling frameworks
Instead of rebuilding the same integration infrastructure repeatedly, your developers focus on customer-facing functionality.
The platform vendor absorbs much of the ongoing maintenance burden.
A Combined Integration Approach for Maximum Coverage
In truth when we speak with customers we always advise that they use at least two of the solutions above.
Design + Outsource
or….
Build + Outsource
or…
Design + Build
or even…
Build + Design + Outsource
Why? Principally because we believe that you should resolve the key integrations natively (Build or Design) and the long-tail off-platform (Outsource).
Choosing the Right Integration Combination for your SaaS
Here are the 5 key questions that we think help you consider what you should do:
- Is it important that I resolve my customer integration at a ‘pain point’?
- Is my application lightly or deeply enhanced by third-party applications?
- Are integration requirements consistent across all 80%+ of my customers?
- What is most important, the source code or the end-customer solution?
- Are my customer’s integration needs relatively fixed or do I need agility?
With these questions in mind, you can look at your platform, and your platform’s users’ needs to work out what combination would be best for you.
The table below gives examples of what combination of integration solutions would work for each use case.
| Outsource | Design | Build | |
| It is important to resolve the customer integration at the ‘pain point’ | X | Y | Y |
| My application is deeply enhanced by third-party applications | X | Y | Y |
| My application is lightly enhanced by third-party applications | Y | X | X |
| Integration requirements are consistent across 80%+ of my customers (focused) | X | Y | Y |
| Integration requirements are inconsistent across 80%+ of my customers (long-tail) | Y | Y | X |
| The source code is most important to me | X | X | Y |
| The end customer solution is most important to me | Y | Y | X |
| My integrations need to be agile | Y | Y | X |
Considering the Volumes of Required Integrations
Depending on the number of integrations you need, you cannot always resolve every single client integration requirement at the point of need.
Why? The complexity of presenting an option for every single possible integration within your native UI. Here is a simple rule of thumb on which choices we would make:
| Total Number of Customer Integrations | How many to Build | How many to Design | How many to Outsource | Recommendation |
| 1-2 | 1-2 | 0 | 0 | BUILD |
| 3-10 | 1-5 | 1-5 | 0 | BUILD + DESIGN |
| 11-20 | 1-5 | 6-20 | 5+ | BUILD + DESIGN + OUTSOURCE |
| 21-50 | 0 | 1-25 | 5+ | DESIGN + OUTSOURCE |
| 51+ | 0 | 1-50 | 5+ | DESIGN + OUTSOURCE |
The 80/20 Rule to Integration Solution Design Success
We are proud of our solution and believe it is an intelligent way to scale your native integrations. But we also believe it is not necessarily the entirety of your integration ecosystem. You should consider the old 80:20 rule. Own the integration solution for 80% of your client’s integration needs and outsource for 20% of your client’s integration needs. It is all about efficiency and managing complexity.
Want to see Cyclr in action?
Book a demo with one of our integration experts to see Cyclr in action and how you could use our embedded iPaaS to enhance your commerce stack!
Our report, An Introduction to Integration, iPaaS and Embedded iPaaS discusses integration strategy and the different approaches in more detail.
