Owning Product Experience in Integrations
Zachary Kirby, co-founder of Vessel, on building the Vercel for integrations
The real moat in integrations is owning the product experience, not merely moving data from one API to another. Customer-facing integrations behave like core app features, because they affect demos, win rates, onboarding, and retention. That is why vendors that look similar at the plumbing layer split apart in practice by who they serve, developers shipping native product features or operators automating back office workflows.
-
Workato grew as a no-code workflow tool for internal automations, where business users drag together recipes across apps like Salesforce, Slack, and Workday. That core DNA is different from platforms built for engineers embedding integrations directly inside a SaaS product UI for end customers.
-
Paragon sits closer to the customer-facing camp. It sells to B2B SaaS teams that need white-labeled integrations inside their product, with APIs, SDKs, auth management, and usage pricing. That supports the view that the market boundary is defined more by workflow and buyer than by ETL versus unified API labels.
-
Within customer-facing integrations, the harder technical work still matters, but mainly in service of reliability and depth. A Salesforce sync that updates quickly, respects permissions, and exposes edge case objects cleanly is what lets a SaaS company treat integrations as a product advantage rather than a box checked on a pricing page.
The category is heading toward the same split seen in auth and payments. Internal automation platforms will keep broadening from workflows into embedded products, while developer-first integration platforms will absorb ETL, action layers, and sync infrastructure into one stack. The winners will be the ones that make integrations feel native inside the product, and invisible behind the scenes.