Here's a scenario from our archive of prospect and customer conversations:
We promised an integration to one of our best customers without really understanding what we needed to do. Integration development took almost six months, and we finally finished it, but we went way into the hole to make that customer happy. Our devs are now saying that they would rather leave than do more integrations.
Nearly every dev has worked on an integration project like this one. As always, it begins with good intentions but ultimately takes far more time and effort than expected.
So, what is the root problem? The root problem is a lack of formal estimating and planning, which is likely exacerbated by the need to create everything from scratch.
The solution? We'll get to that. But first, what other issues are likely to accompany this scenario?
Related issues
These are not the only additional issues that might arise with this scenario, but they are some of the most concerning.
Dissatisfied developers
Our scenario already mentions that the devs aren't happy, so it's easy to understand this as a related issue. It's likely that these six months, filled with unforeseen complexities and considerable scope creep, have left devs feeling off. Their desire to go, if faced with more integrations, is no small matter.
Several factors have contributed to this, but the primary driver is likely the sheer frustration of working on something this disorganized. This unhappiness may also reflect deeper issues tied to devs not being part of the vetting process for this integration. They may well believe that their expertise was ignored and their concerns were dismissed throughout the project.
As a result, they now view integration work as a punishment rather than an interesting technical challenge, and they're questioning whether the company truly values them as the professionals they are. Unfortunately, when another team promises deliverables without consulting the people who build them, it can destroy trust.
Tech debt and maintenance issues
The custom integration development has almost certainly created a maintenance nightmare that will continue to pop up. With projects like this, where things constantly change, and devs must react accordingly, they inevitably take shortcuts – such as hardcoding values that should be configurable, skipping proper error handling, avoiding comprehensive testing, and creating tightly coupled code that doesn't follow best practices. The worst part is that this tech debt doesn't disappear when the integration is deployed; it will increase over time, causing the devs who work on this code in the future to dread the experience.
The integration is likely poorly documented, with temporary fixes (done to get this thing out the door) that have already become permanent. Every time this integration requires a modification or bug fix, everyone will want to know which dev worked on it last and ensure that it's the same person who will work on it again. The poor dev gets to own it and all of its fixes forever because no one else wants to take the time to figure things out.
If the team doesn't address this soon, patterns and shortcuts used for this integration may become the de facto starting point for subsequent integrations. Then, new team members will struggle to understand and extend the existing integration architecture.
Friction between teams
Since the scenario mentions that the integration was built "without really understanding what we needed to do," it's likely that sales was focused so much on closing the deal that no one conducted the kind of detailed discovery that would have prevented the entire issue. As a result, sales may feel that engineering is being difficult, while the devs feel as though their sanity was sacrificed to make unrealistic commitments.
Customer support was likely caught in the mix, trying to manage a customer who wondered where the integration was while internal teams were at odds. At the same time, product was no doubt struggling to balance customer demands against technical capabilities. And the company's leadership was putting pressure on everyone to step up and do what was promised to the customer (regardless of the technical, scheduling, or other problems that needed to be solved).
Teams often speak different languages; cross-team communication can be fraught with misunderstandings. In this scenario, however, because things continued for as long as they did, more than one team is likely dealing with a substantial pile of resentment towards another team or teams. If that's not addressed, it will lead to numerous issues down the road.
Disappointed prospects
During the time it took the team to build the integration, they undoubtedly lost some opportunities – whether those were opportunities to develop new product functionality, establish new integrations, or refine and perfect what was already in place.
And, given how painful and expensive this integration process was, the company is unlikely to jump on opportunities where prospects are interested in new integrations alongside the main product. Any other integration plans have likely been put on hold, which may lead potential prospects to move on to competitors instead of waiting for the company to figure out how it will handle integrations.
Sales is now in the position of explaining why integrations take so long that they're not worth doing (or are expensive) or why prospects don't need the integrations they think they do. Pretty soon, the company develops a reputation for being slow and unreliable compared to competitors who can quickly deploy integrations or otherwise address prospects' integration needs.
Don't stay where you are
If this scenario and its related issues match how things are going for your integrations, we have some good news: you don't need to stay where you are.
Remember this scenario's underlying problem? "A lack of formal estimating and planning, which is likely exacerbated by the need to create everything from scratch."
To address this, we bring you Prismatic – an embedded iPaaS that enables you to create a scalable integration strategy, leveraging your entire team to deliver productized integrations to your customers. Here's how it helps.
Efficient, focused devs
It is essential to capture integration requirements upfront. If there is no defined scope, then it's easy for the scope to keep growing (as in this scenario). We recommend using our integration specification template as a starting point.
Beyond that, Prismatic provides devs with many efficiencies, not the least of which is the integration infrastructure, including auto-scaling compute resources, auth, webhooks, config wizards, logging, and automatic retries. This allows devs to focus on writing the integration and not spend a lot of time creating and spinning up everything needed to make the integration work.
Another efficiency is driven by integration accessibility. Unlike many custom integrations built from scratch, Prismatic-built integrations are not black boxes. Instead, they are visible and accessible to your non-dev teams (such as onboarding and support) and your customers. This allows many integration issues to be addressed without requiring engineering involvement.
And, if it makes business sense for your customers, you can set them up with the embedded workflow builder to create the types of one-off integrations that your team may not have the time to build because they aren't a priority.
Maintainable code
In addition to the infrastructure, Prismatic provides pre-built integration connectors and other components, as well as an SDK for devs to create custom connectors. This ensures that devs and non-devs alike have building blocks and patterns that can be used for all your integrations, driving consistency.
Using tools such as Cursor and Claude Code with our SDK and a publicly available ruleset, your devs can substantially speed up the process of creating custom connectors (and soon full integrations) while maintaining best practices. This ensures future devs won't be frustrated when they attempt to create bug fixes or perform other code updates.
Integration code can be incorporated into your standard CI/CD processes, including code repositories such as GitHub.
Teams that communicate
Many of the communications issues highlighted by this scenario must be addressed outside of the embedded iPaaS. However, there are direct and indirect ways the platform can improve communication on the topic of integrations.
One direct way is by the inclusion of an integration marketplace. This marketplace can be set up quickly and easily with minimal customization, allowing customers to search and self-activate all your available integrations. Alternatively, you can use our SDK to create a marketplace that is completely customized to match your products' existing UI, including logos, colors, fonts, and terms. Additionally, the marketplace offers a comprehensive integration list for onboarding, support, sales, or anyone else in your company.
Using Prismatic to build integrations significantly decreases time to market. As a result, the gap between when sales would like to have new integrations ready (today) and when you can deploy them (a few weeks from now) is not very large. You still need sales and engineering to communicate better than in our scenario, but with a much faster request turnaround time, it'll be easier for teams (including sales, engineering, and product) to create timelines that work for your company and customers.
Beyond that, deploying and maintaining integrations via Prismatic ensures that teams throughout the company have visibility into all sorts of information about integrations: what customers have them, how often they are used, what types of issues arise, what issues can be addressed directly by customers and which ones require support, and much more.
More prospects becoming customers
You need to convert your prospects to customers. An embedded iPaaS can help.
As we've already discussed, your time to market for new integrations will be significantly reduced. And you'll have a team that knows how to execute new integration requests successfully. Now, when you are working with a prospect who says, "Oh, and I need an integration with X," you can say "Yes" and note how long it will take.
And, with everyone on your team, from sales to support, having a consistent, repeatable process for integrations, neither your devs nor anyone else will shy away from the work and value presented by new integration requests.
Instead of being in a position where prospects who want to do business with you are leery about integrations, you'll gain a reputation as the "get-it-done" team for integrations. No longer does a lack of integrations stand between sales and closing the deal.
What next?
Prismatic provides a framework and all the necessary tools to create and support integrations through a structured, repeatable process. Many integration-related tasks, such as onboarding and support, can be handled by non-devs, freeing up devs for more demanding work and ensuring that your customers' integration issues are addressed sooner rather than later.
Schedule a demo, and let us show you how using Prismatic to build, deploy, and manage integrations for your product helps you reduce integration friction and frustration for everyone, both inside and outside your company.
