Note: This composite case study is based on patterns Boomi sees across multiple customers. It reflects real challenges and decisions, but does not represent any single company.
For a lot of B2B SaaS companies, the move upmarket follows a familiar script. The product is ready. The pipeline is building. And then, in late-stage enterprise deals, the same question keeps appearing: “Does it integrate with our ERP?”
What happens next — how companies answer that question, and what it costs them when they can’t — is the focus of this post.
The Company
Picture a B2B SaaS company about five years into its journey. The company has roughly 150 employees, $18M ARR, and a product built around production planning and shop floor visibility for manufacturers. They’d established a strong foothold in the mid-market, selling to companies in the $100M – $500M revenue range, and the product had the depth to compete higher. Leadership made the call: it was time to push to enterprise.
The pipeline reflected the ambition. Deals were getting larger, sales cycles were getting longer, and the prospects across the table were more sophisticated. They had dedicated IT teams, internal security reviews, and non-negotiable requirements around how their tools connected to existing infrastructure.
Almost every one of them ran SAP, NetSuite, Oracle, or Microsoft Dynamics at the center of their operations, and it wasn’t going anywhere. For a production planning tool, that wasn’t a peripheral concern. ERP systems stored bills of materials, created production orders, and tracked inventory. A planning tool that couldn’t read from and write to that system wasn’t a planning tool. It was a spreadsheet with a nicer interface.
The Breaking Point
The breaking point came in two moments about six weeks apart.
The first was a lost deal. A 400-person industrial equipment manufacturer had been in late-stage conversations for nearly four months. The product had performed well in the demo, the champion was enthusiastic, and the commercial terms were close. Then the IT review happened. The prospect ran SAP across all three of their facilities, and when they asked for documentation on the SAP integration, what the company had to show was a custom connector their senior backend engineer had built eighteen months earlier for a different customer. It technically worked — but only for that customer’s specific SAP configuration. The prospect’s IT team took one look at it and killed the deal.
The second was a churned customer. A mid-sized auto parts manufacturer who had been a happy customer for two years sent a terse cancellation notice. In the exit conversation, the reason came out. Their Ops team had gotten frustrated waiting for field mapping updates that kept breaking after their ERP vendor pushed an update, so their internal IT team had built their own connection between the two systems. Once that was working, the value of the SaaS product dropped enough that it was hard to justify the cost.
Both situations tracked back to the same root cause. The company had built their integrations entirely in-house, one at a time, by engineers who were also responsible for core product development. The NetSuite connector had taken months to build. The SAP connector had taken longer, and was still technically in beta. Every ERP vendor update triggered engineering maintenance work. Every new enterprise prospect who ran a different ERP configuration meant scoping another custom project. The integration backlog had become a shadow roadmap that nobody had officially approved, but everyone was quietly working around.
After the second loss, the VP of Product pulled the data. Of the last eleven enterprise deals that had gone to late stage, seven had included integration requirements that the team couldn’t fully meet. Three of those had been cited as a factor in the loss. The math was uncomfortable.
The Decision Process
The VP of Product came to the offsite with a simple framing: either they solved the integration problem properly, or they stopped targeting enterprise. Doing neither wasn’t an option anymore.
Two paths made it to serious evaluation.
The first was hiring. The argument was straightforward — they already knew how to build integrations, they just didn’t have enough people doing it. A dedicated integration engineer, maybe two, could accelerate the backlog and keep up with the maintenance.
The second option was embedding an integration platform as a service (iPaaS) solution such as the Boomi Enterprise Platform, allowing integration capabilities to appear natively within their product rather than as an external tool.
They stress-tested both options against four criteria that had emerged from the post-mortems on the lost deals and the churned customer.
- Engineering Capacity and Opportunity Cost: When the CTO mapped out what two integration engineers would actually work on for the first year (rebuilding the SAP connector properly, extending the NetSuite connector, building a Microsoft Dynamics connector from scratch, and maintaining all three) there was almost nothing left for product work. They weren’t hiring people to move faster. They were hiring people to stay still.
- Time to Market: The earliest a new hire could be productive on a complex ERP connector was three to four months in. An embedded platform with pre-built connectors could have a production-ready SAP integration in front of customers in weeks. With enterprise deals already in the pipeline citing integration gaps, weeks mattered.
- Ongoing Maintenance Burden: This was the criterion that surprised the team most in the analysis. They’d been thinking about the build cost but underweighting the carry cost. ERP vendors push updates. Authentication methods change. Field requirements shift. Every connector they owned was a long-term liability on the engineering roadmap. An embedded platform transferred that maintenance responsibility to the vendor whose entire business was built around keeping those connectors current.
- Enterprise Buyer Expectations: How it would appear to enterprise buyers ended up being the closing argument. When they walked through what a self-serve integration experience would look like inside their product versus what they could realistically build in-house in the same timeframe, the gap was significant. Enterprise IT teams weren’t just asking whether an integration existed. They were evaluating whether it looked like something a serious software company had built intentionally, or something that had been duct-taped together under pressure.
The decision wasn’t unanimous immediately. There was real discomfort about depending on a third-party vendor for something this close to the core product experience. But when the team modeled out the two-year roadmap under each scenario, the embedded path was faster to market, cheaper to maintain, and produced a better end result for customers. The vote was close, but it was clear.
In Part 2, we walk through how the implementation actually went, including the field mapping complexity and API edge cases they didn’t see coming, and what changed for the business once the integrations were live. Stay tuned.
Thinking through the same decision for your SaaS product? Start with our guide: Build or Buy: The Ultimate Guide to Effective Product Integration Strategy.