Should you follow an interface strategy or an AI strategy to connect your product to the world? The likely answer is “both.”

I’m sure you came across automation tools such as Microsoft Power Automate, n8n, or Zapier.

These tools exist because people want to connect different software applications: Do one thing in an application, hand over the result to another, then trigger a follow-up action.

Many individuals and small companies use these tools to simplify their lives, for example to automate boring tasks.

That’s great. But what about larger organizations that need different software tools to talk to each other?

At Yonder, the B2B SaaS company I co-founded, we are selling to large enterprise customers in the aviation, critical infrastructure, and defense sectors. All of these sectors are highly regulated, so they would never allow their users to connect our product to Microsoft Power Automate, n8n, or Zapier workflows.

So, what do they request, and how do we respond to their requirements?

Option 1: Interfaces

The “legacy” way for B2B SaaS products to talk to other SaaS products is through interfaces. Your software engineers implement specific actions in your SaaS product based on API calls to another SaaS product. Customers enter their credentials to authenticate the interface, then can perform whichever actions are implemented in the interface.

It sounds simple, and in most cases it is: Take the API documentation of the SaaS product you want to interface with, implement the use cases your customers need, test it, ship it. All fully deterministic, since an API (should) always return the same data when it is called.

However, have you thought of data quality problems? Have you thought of what happens when the SaaS product you want to interface with suddenly changes its APIs and doesn’t inform you upfront? I’m not dramatizing here; we implemented an interface to another SaaS product that didn’t even have proper date formats. Yes, you read correctly. The other party sent ambiguous dates; sometimes formatted as dates, sometimes as text. No wonder our customers reported bugs all the time.

Option 2: MCP Servers

Enter Artificial Intelligence. The Model Context Protocol (MCP) provides a new way for different software applications to talk. Instead of implementing APIs for every service, an MCP server is a standardized bridge between your SaaS product and other products. And that bridge is AI: Any AI model can talk to any MCP server the same way. The only thing you have to do is expose tools for your SaaS product on your MCP server, and other applications can talk to your product through AI.

Does this sound easier than implementing APIs? Yes, the setup is easier. But as with any solution, there are pros and cons.

The first drawback is that AI is never deterministic, meaning that two identical queries can yield two slightly different answers. In many cases, that’s not a big drawback, but in safety-critical or regulated environments, it can be.

Furthermore, exposing tools to your SaaS product on an MCP server needs careful planning to ensure your customers use the integration only in the way you want them to. AI is more flexible in fulfilling edge case requests than a deterministic SaaS user interface.

Conclusion

In today’s world, people expect you to connect your product to other products. Therefore, there is no way around interfaces and MCP servers.

It doesn’t matter which avenue you choose first; you’ll likely have to implement both to stay competitive.

One final thought. While a classic interface just connects two tools, an MCP server lets you integrate your product into your customer’s AI workflows. And no matter how critical you might be towards AI, AI is here to stay. So integrating your tool into your customer’s AI workflows looks like a survival strategy for the years to come.