If you've got a B2B SaaS product on the market today, it needs integrations.
No matter how good your engineering team is, your product can't do everything your customers want. At the same time, your customers expect integrations to smoothly incorporate your product into their existing business workflows.
Meanwhile, your devs may be looking at yet another API spec, wondering if there is anything else they can work on right now.
So, is there a way to make integrations less painful to build, deploy, and manage?
Yes, there is. But first, let's look at the intersection of devs and integrations in detail.
Devs and integrations
As a rule, devs aren't fond of working with integrations. They don't like building them, deploying them, managing them after they are deployed, and being on the hook to support them until the end of time.
Unfortunately, there are good reasons for this dislike: integrations are full of unwelcome challenges like diverse, undocumented, or non-existent APIs, inconsistent endpoints, varied protocols, and the joys of dealing with third parties with totally different priorities and who don't communicate changes well. And, integrations often drive outsized demands for dev time and other resources, leaving devs with the impression that integrations provide low rewards for the effort required.
Many experienced devs don't even consider integrations real work and will seek to wiggle out of integration-related tasks as soon as they can get someone else lined up in their place.
As noted, your SaaS product needs integrations. However, as long as your developers continue to view integrations as problems they want to go away, it will be hard to make significant progress with your integration strategy.
Why your devs shouldn’t ignore integrations
Despite the difficulties inherent in providing integrations to your customers, enabling your product to securely and efficiently exchange data with your customers' other apps is a task worthy of engineering.
First, building integrations is a way to solve real problems for real customers. As a rule, customers are not interested in your code but in what it allows them to do. They are looking for ways to streamline processes and have their employees spend less time doing drudge work (like running reports and copying data from one system to another) and more time engaged in processes requiring unique skills. Integrations can save customers time and significantly reduce data entry errors.
Next, SaaS products without integrations have very uncertain futures. They are siloed, challenging to scale as customer needs change, and tend to have lower customer satisfaction. By comparison, apps with integrations are more flexible, allowing SaaS teams to tailor products to specific needs.
Finally, interoperability is the key to modern software. Modern users don't just want standalone tools – they want solutions that fit into their existing ecosystems. For example, if your product (an OMS, we'll say) doesn't integrate with popular CRMs, it risks being seen as isolated and outdated, driving users to competitors who offer that connectivity.
Including integrations with your app enables the connectivity between apps that your customers increasingly depend on to streamline their business processes. And your devs get to leverage work that others have done to make your product do more for your customers.
Making sense of integrations for devs
Despite devs' difficulties with integrations, they should treat them as puzzles to solve instead of something to get done as quickly as possible. Integrations introduce real software challenges and are an increasingly important part of the landscape. Embracing them is the best way forward.
Here’s how.
Offload the infrastructure on someone else
Most of what comprises an integration lies just out of view. That's often why, when a dev is asked, "Can you build this integration," the initial answer is often, "Sure, that looks pretty easy." The unfortunate reality sets in some time later as the dev must figure out precisely what compute resources are needed, how the integrations will be activated, how auth will be managed, the webhook structure, event scheduling, data logging, monitoring and alerting, testing and versioning, security, and all the rest.
Since it doesn’t make any sense to reinvent the wheel, an embedded iPaaS such as Prismatic is built to handle all of that and more, leaving your devs free to focus on the unique details of how you can efficiently share data from System A to System B.
Check out our blog post where we dig into everything you can’t see right away.
Use the tools your devs know
It's hard for any skilled worker to perform tasks with unfamiliar tools. This is true of devs, and one of the reasons they would prefer not to use a low-code designer to create integrations. It slows them down, limits their problem-solving ability, makes debugging a nightmare, doesn't include robust testing tools, and more.
Yes, there's a place for a low-code designer in integration development (and we'll look at that shortly). However, for devs who need to create integrations, the best tools to use are the ones they know, starting with their IDEs. Then, they can do what they do best: write code to solve problems. And by writing integrations in code, they can take full advantage of a familiar environment for maximum efficiency and flexibility.
Automated testing, detailed debugging, version control, and more are a few keystrokes away. Devs can also ensure that integrations are fully incorporated in CI/CD pipelines, driving consistent build, test, and deployment processes.
Where it makes sense to code new functionality, the dev can do so, but where it makes sense to use triggers, actions, and other pre-defined code functions, those are accessible. All the infrastructure we covered in the previous section and our pre-built connectors and other components are available.
Get non-devs involved where it makes sense
One of the big drawbacks with integrations, as many SaaS teams currently handle them, is that they are almost entirely owned by engineering. This often occurs when integrations are not considered fully part of the product. Instead, they are often seen as a necessary evil that gets bolted on after the fact. And so the devs build, deploy, and manage them – because no one else knows anything about them.
But integrations don't need to be bottlenecked like this. You can use technical non-devs to build integrations with a low-code designer, then configure and deploy those integrations to customers, and support the integrations once they are deployed. Taking it one step further, you can even determine which integrations your customers should build themselves and turn them loose with an embedded workflow builder to do just that.
Many of our customers have found that while devs are still essential for integrations, most day-to-day integration tasks don't depend on them. Instead, have your dev focus on your core product and the parts of your integrations where their skills provide optimal value.
Yoti completely overhauled its integration process and reduced engineering time spent by 95%.
Integrations are a key piece of the equation
Integrations are an essential element of modern software development. While working on integrations can often be complicated, time-consuming, and frustrating, we can't have modern connected apps without them.
Rather than viewing integrations as tedious tasks, consider how they can help level up your team. After all, integration development requires a deep understanding of how systems communicate, how data flows, and how to design secure and scalable systems.
And your devs don't need to venture into the dark caves of integration development without help. Request a demo and let us show you the latest in pain-reducing tools and processes for your integrations.
