Customer-driven integration strategy
Zachary Kirby, co-founder of Vessel, on building the Vercel for integrations
The key dynamic is that integrations are usually sold by customer demand, not roadmap ambition. A SaaS vendor can list many logos to stay in buying conversations, then only fund the real build when a prospect says this Salesforce, HubSpot, Close, or Pipedrive connection is blocking the deal. That keeps engineering focused on revenue linked requests, and pushes teams toward integration infrastructure only after repeated one off builds turn into ongoing maintenance work.
-
This is a head versus tail allocation decision. Companies tend to build the few integrations that drive activation and retention, then leave the long tail to platforms like Zapier, which are useful for coverage but usually weaker than native product flows for core use cases.
-
The trigger to buy an embedded or native integration platform is usually operational pain. After two to four in house builds, teams find engineers spending meaningful time on OAuth, bug fixes, schema drift, rate limits, and endpoint changes instead of the core product.
-
That is why developer first vendors like Vessel position against workflow tools such as Workato and Zapier. Workflow tools help internal teams drag blocks together. Native platforms put the integration in product code, where a SaaS company can control scopes, data models, refresh timing, and UX.
The market is moving toward a split model. More SaaS companies will natively own the handful of integrations that decide deals, while outsourcing the plumbing and long tail. That shifts spending away from generic automation and toward infrastructure that makes deep product integrations fast to launch and cheap to maintain.