Should I build integrations to grow my SaaS?
Usually yes, but rarely for the reason founders expect. Most integrations remove a reason not to buy rather than bring anyone new — they close deals that were already close and keep customers who would otherwise leave. The exception is a partner with a public, searchable marketplace, because that listing is a genuine acquisition channel and it is worth choosing the partner for. Build the one your almost-customers keep asking for, and treat everything you ship as a standing maintenance commitment to somebody else's API.
What an integration actually buys you
Three different things get called an integration and only one of them is a growth channel. The first is a technical connection your customers need in order to use you properly — data flowing in from the tool they already live in. The second is a partnership: co-marketing, a joint webinar, an introduction to their customers. The third is a listing in the partner's marketplace, where people who have never heard of you can find you by browsing or searching. Only the third one brings strangers.
That is not an argument against the first. An integration that removes the last objection in a sales conversation is worth building even if it never appears in an analytics report, because the return shows up as deals that close instead of deals that stall. But it belongs on your roadmap under conversion and retention, not under acquisition, and confusing the two is how a founder spends a month of engineering expecting traffic and gets none. If what you actually need is more people arriving, which marketing channel to double down on is the question upstream of this one.
The marketplace listing is the part that behaves like a channel
When an integration does bring new customers, it is almost always because the partner runs a directory that people search. That makes the listing much closer to an SEO surface than to a partnership: it has a title, a description, a category, screenshots, reviews and an install count, and it ranks against every other app filed beside it. Treat it that way and the work becomes familiar.
- Pick partners whose marketplace people actually use A tool with ten thousand customers and no directory sends you nobody. A tool with a browsable, searchable app store sends a trickle every week for years. Search its categories the way a buyer would before you commit engineering time — the same shortlist test that applies to AI tool directories.
- Write the listing for the browser, not the reviewer The person approving your submission wants completeness. The person reading it wants to know in one line which problem this solves inside the tool they already pay for. Those are two different documents and most listings are written for the reviewer.
- Reviews and install counts are the ranking signal you can move Marketplaces surface what looks adopted, and the customers who asked you for the integration are exactly the people who will leave a review if you ask them in the week it ships. Nobody asks later.
- Instrument the listing separately Give the marketplace its own tracked link before you launch. Otherwise its traffic lands in the direct bucket and you will never learn whether the channel was worth the build.
The cost you are signing up for
An integration is not a feature you ship once. It is a standing dependency on an API somebody else owns and changes on their own schedule, and the failure mode is quiet: it keeps working until the day it does not, and your own test suite does not notice, because a test proves you sent the request you meant to send — never that the other side still accepts it.
Price that in before you commit. A read-only connection to a stable, well-documented API is cheap to keep alive. A write integration against a fast-moving product, with tokens that expire and permissions that get renamed, is a recurring cost you will pay in support tickets for as long as the feature exists. That is the real argument for building the one your customers keep asking for instead of the ten that would look good on a landing page: maintenance is per-integration, and it never ends.
What this looks like from the other side of the API
At AgentCeres — the AI growth team at agentceres.com — we maintain a large catalogue of connections into the tools our customers already use, so we see this from the building side. Two things have held consistently. Almost none of those connections brought us a customer; they keep customers, by making the product useful against real data instead of an empty workspace. And the maintenance is not hypothetical: vendors rename actions and parameters without an announcement, and we found out in production while every one of our own tests stayed green, for exactly the reason above. We now check the live schemas on a schedule, which is a cost we did not price the first time.
The other habit worth stealing is cheap. When a customer asks for an integration, find out which of two sentences they mean. "I cannot use you without it" is a blocker and goes to the front of the queue. "That would be nice" is a preference and goes in a tally. The tally is the useful artefact — after a couple of months it tells you which one to build, and it is far more honest than whoever asked loudest this week. Once the thing is live, the growth work is getting existing users to switch it on, which is an onboarding problem rather than an engineering one.
FAQ
- Do integrations actually bring in new customers?
- Sometimes, and almost always through the partner's marketplace rather than the integration itself. A connection that only exists inside your product is invisible to anyone who is not already a customer. A listing in a directory people browse is a real acquisition channel — steady rather than spiky, and small enough that it should not be the whole reason you build. If new signups are the goal, judge the partner's directory before you judge their API.
- One customer is asking for an integration nobody else wants. Should I build it?
- Only if that customer is worth the permanent maintenance, and it helps to say it to yourself in those words, because the deal closes once and the upkeep continues. A reasonable middle path is to ask whether an export, a webhook or a documented API would solve the same problem. Those serve every future request of the same shape instead of one, and they are usually less work than the integration you were about to hand-build.
- Should I build integrations myself or use a unified API service?
- A unified layer is a fair trade when you need breadth quickly: many connections for one implementation, paid for in per-connection cost, less control at the edges, and a dependency on a company sitting between you and the vendor. Building directly costs more up front and gives you the whole surface of each API. Most teams end up mixed — hand-built for the handful that matter commercially, a shared layer for the long tail nobody asks about by name.
Want this done for you?
AgentCeres is a managed AI marketing team — specialists draft the work, you approve what ships. 14-day free trial, from $39/month.