When SaaS companies build customer integrations in-house, most (if not all) of the work is performed by devs. As a result, integration development ties up resources that could otherwise be spent on the core product.
This resource constraint can cause you to postpone key roadmap initiatives, create integration backlogs for new customers, and lead to numerous other issues.
One way to ensure you use your devs more efficiently is by implementing an embedded iPaaS for your customer-facing integrations.
Every software company is different, so you may still want to use devs for your integrations. But you’ll reduce the integration work needed and if it makes sense for your team, transfer much of the work from devs to technical non-devs.
Cofactr, recently overhauled its integration process and saw huge savings in integration build time.
Let's look at how you can use devs efficiently at every stage of doing integrations with an embedded iPaaS.
Setting things up
The initial setup of our embedded iPaaS (creating your org and users, setting up multi-region deployment, single sign-on, and custom domains) can be mostly done by non-devs. However, you will want your devs to handle the part of the setup that requires prism (our command line interface). This usually involves integrating Prismatic with your CI/CD pipeline.
Of course, if you do in-house integration development, all of the above work (and more) depends entirely on devs. Infrastructure development alone may take a team of devs many months as they work through everything from sizing and setting up compute resources to figuring out how to manage OAuth, webhooks, and logging.
Building your integrations
We have enabled two paths for building integrations with our embedded iPaaS: one uses our low-code integration designer, and the other enables a code-native integration building experience.
Using our low-code integration designer, you could create simple integrations without devs. But even using the designer, some integrations will need dev assistance with tasks such as writing custom code or building a custom action, trigger, or data source.
More than 50% of our new revenue is coming from customers who use these new [integration-enabled] modules and upsells of existing customers onto these new modules. And that would not have been possible if we were still having to build the underlying integrations manually with engineering resources.
Companies with enough devs to build integrations are usually most comfortable with our code-native integration building experience. This allows them to write code in their favorite IDEs.
Regardless of which approach you might use for your team, you will need devs to build custom connectors and other components. We have an SDK to simplify this process, but it still requires a solid understanding of TypeScript and how APIs work. But, once you've built the custom components you need, your non-devs can use them with the low-code integration designer.
On the other hand, in-house integration building depends entirely on the devs because there is no low-code integration designer. Instead, each integration is built from scratch in code. And, because there is no common integration platform, in-house integrations are all over the place regarding structure, coding, languages, reusability, and more.
Deploying your integrations
Using our embedded iPaaS, deployment is the stage that's most dependent on devs. This is true because deployment usually depends on the white-labeled integration marketplace (where you'll list your integrations) or the embedded workflow builder (where your customers can create their own integrations with your product).
You will need devs to set up or fully customize the marketplace and the builder. You'll also need devs if you use data sources with the config wizard. In addition, depending on how complex deployment and activation become, you may need additional dev help with other parts of the configuration wizard.
[Prismatic] completely streamlined the process of activating integrations and freed up developers from having to be involved.
Once those matters are addressed, your non-devs can list those integrations in the marketplace and either activate the integrations for customers or ensure that customers can successfully self-activate.
Integration deployment is far different when done in-house. Devs must usually modify each integration to meet the specific deployment needs of each customer. Additionally, each integration must be deployed individually, usually by a dev, because there is no UI to allow non-devs to work through the deployment and activation processes.
Managing your integrations
Managing integrations includes everything from performing integration updates to solving customer issues. And, with our embedded iPaaS, most of that work can be done by your non-devs. The heavy lifting for infrastructure concerns (platform updates, security fixes, etc.) is done by our team here at Prismatic, so your devs don't need to worry about that.
Of course, if you need to make changes to underlying code, such as custom connectors and other custom components, devs should handle that work.
However, the day-to-day work of keeping your integrations running and making your customers happy can be handled by non-devs with access to the integration and customer dashboards. Non-devs can look at integration statuses, help customers update OAuth credentials, and even dig into the logs. Going further, you can enable your customers to handle first-level troubleshooting and fixes themselves.
[Prismatic] allows our developers to focus on developing. It's been a game changer to give our customer success team and our technical support team access into Prismatic so they can look at logs and provide better customer support.
As a rule, the management stage of integrations is the least well-served by in-house development. From a customer support standpoint, they usually send all integration-related requests directly to engineering because they (customer support) lack the tools that allow them to view or modify anything for deployed integrations. And customers rarely have any direct insight into integration states beyond a handful of terse error messages.
Save resources and stay on task
Use an embedded iPaaS to ensure that your devs spend their time where it is most needed. Whether that's taking them mostly off the day-to-day work of building, deploying, and managing integrations or not, make sure your devs are spending their time where it benefits your company and product the most.
Our embedded iPaaS allows you to use the team you have to create the integrations your customers need. It not only provides you with substantial savings for using it to build integrations, but it can also help you dramatically increase the number of customers who use your integrations.
We probably save 95% of [engineering] time, we've deployed far more integrations than we would have without Prismatic.
Schedule a demo, and let us show you how an embedded iPaaS can provide the tools to create a scalable process for building the integrations your customers need.
