The Three Moats That Decide Whether a SaaS Is Worth Integrating With

Short answer: when deciding whether a SaaS product is worth building an integration with, don't ask what it does — ask what it has that a partner's own developer could not rebuild in an afternoon. There are three answers that count: network effect, data, and IP or licenses. A product with none of them is not an integration partner. It is a favor.

Here is that rule applied to a real product, live, with the founder's landing page open in front of me.

The idea was good. That was never the question

The tool was a search engine for your own network. Connect your email, your calendar, your contacts, your Outlook, your LinkedIn, your Instagram, and an AI surfaces the person you already know who can help with whatever you are trying to do.

That premise is genuinely solid. You do already have the person you are looking for somewhere in your network, and you do not have the mental capacity to remember all of them or to know at any given moment when to go looking. A tool that fixes that is a real tool.

I still would not take it to a client, and the reasons are worth more than the verdict.

Problem one: nobody goes looking on a random Tuesday

People do not wake up on an ordinary Tuesday with a small problem and think "I wonder if someone in my network can help me with this." They just do not.

What actually happens is narrower. Somebody is in a position where they need new clients, so they go in once, pull a list of leads, and reach out. Then they are done until the next time they have something new to sell. That is the realistic retention pattern for a tool like this: one burst per thing you need to sell, and months of nothing in between.

And even when the tool does surface someone, the questions that follow are not ones software answers. Are we close enough that they would do this for free? Do I still have to pay them? How do I know they are the best option? Every one of those is a reason to stall.

I might be wrong about the retention — I do not know his industry, and maybe it is much higher than I think. The second problem does not depend on being right about the first.

Problem two: what here is actually hard to replicate?

This is a tech tool that wants to be integrated into another tech tool. So the question for the other side is: what does it have, in its tech, that is hard for them to replicate?

Right now, nothing.

What is under the hood is a coding agent wired up to some APIs to pull those connections in, plus a manual upload path for the sources that have no API, plus a system prompt over what is probably a retrieval model to rank the results. That is a real weekend of work. It is not a moat.

I know it is not, because I have built the same feature. It took about an hour on Ordana, and it works about as well as it can, because the data underneath it is thin. If you upload your LinkedIn connections, what you get in that file is a name and a headline — founder at company, head of operations at something. That is the whole record. No amount of prompt engineering makes a richer answer out of a name and a job title.

He also does not have more data than anyone else, and he cannot aggregate it. The value of the tool to me is finding people in my network — there is nothing in it for me in searching someone else's — which means he is not sitting on data nobody else has. He is tapping into a slice of the data I already own.

So if I take this to a SaaS client and ask them to spend a sprint on the integration, the honest pitch is: this company has spent months on something your developer would rebuild in two hours. I would rather say "just add me to your GitHub repo, I will build this for you in two hours" — and I could.

What would have made it defensible

There is a version of this product that I would take to a client, and it is not a better system prompt.

If the networks merged — if I bring my network, and a thousand other people bring theirs, and the whole thing pools into tens of thousands of people — then typing "I need someone who does X" and getting back a first- or second-degree connection with a warm introduction attached is something no client could replicate. At that point what he is selling is the thousand users who have uploaded their network, not the AI on top of it.

That is a network effect. It is the difference between a feature and a company.

The three moats

This is the general rule, and it is the one I apply to every collaboration I put together:

1. Network effect — the product is more valuable because other people are already on it, and a competitor starting today would have to recreate the crowd, not the code.
2. Data — it holds something nobody else holds, or holds it aggregated in a way nobody else can assemble.
3. IP and licences — the legal right to do something your partner cannot simply go and do themselves.

Those are the three kinds of thing that, delivered through software, are genuinely valuable inside an integration. If a product has none of them, an integration is not a deal — one side is doing the other a favour, and favours do not survive a roadmap review.

This is the same test behind startup moats in the AI era — here it's the version you run on someone else's product before agreeing to build alongside it, rather than the one you run on your own before pitching investors.

What to do on Monday

Open your own product and answer one question in writing: what does a partner get from integrating with us that their own developer could not build in two hours?

• If the answer is "our users", write down how many, and whether they compound — that is a network-effect claim and it is your strongest pitch.
• If the answer is "our data", write down exactly which fields, where they come from, and whether the partner could get them from the source directly. If they could, it is not a moat.
• If the answer is "our licences or IP", say which ones, and be ready to show them.
• If you cannot finish the sentence, stop pitching integrations and go build one of the three. Partnerships do not fix that, and neither does a nicer deck.

And when you do pitch, lead with the moat rather than the feature list. The person on the other side is doing this exact arithmetic whether you name it or not.

This is the filter Ordana runs before recruiting an integration partner for a client — it's also why the shortlist we hand back is short.

Related reading:

• Startup Moats in the AI Era — the full breakdown of the three defenses, applied to your own product instead of a partner's.
• How to Find Integration Partners When You Have 300 Users — the shortlist process this moat test feeds into.