Back

Playbook

How to Build a SaaS Partners Page That Recruits Partners

November 7, 20266 min read

Short answer: a SaaS partners page is a public page on your own marketing site, usually at /partners, written for other founders rather than customers. It says who you partner with, shows each live integration as what it does for a shared customer, explains what a partnership with you involves, and ends in one "Partner with us" button that leads somewhere that can take an application. Build it even with one partner: it is the only recruiting channel that compounds and costs nothing per contact.

Most early SaaS products have no partners page, or have a logo wall labelled "Integrations" that nobody updates. Both waste the same asset. Your marketing site already gets visitors, and some of them run software companies whose users overlap with yours. A good partners page turns a fraction of that traffic into partnership conversations, with no cold email, no scraped address list and no per-contact cost. The visitor came to your site on their own.

Who reads a partners page?

This is the decision everything else follows from, and most pages get it wrong. There are two different surfaces where an integration becomes visible, and they are read by different people:

Public partners pageIn-product integrations screen
Where it livesYour marketing site, e.g. /partnersInside your app, e.g. Settings, "Connected tools"
Who reads itFounders and partnership leads at other companiesYour own customers
Its jobRecruit the next partnerLet a user find and switch on a partner feature
Its call to actionOne clear "Partner with us" button"Connect" or "Turn on", plus at most one quiet link
When to build itAlways, from the first live integrationOnly if one already fits, or the integration needs a switch

The common failure is writing one page for both readers. Customers get partnership pitch copy they don't care about, founders get a grid of logos that says nothing about what an integration with you involves, and neither one acts.

What should a SaaS partners page include? A section-by-section outline

Here is an outline you can hand to a designer or to your coding agent as-is. Keep it on one page; a partner program with tiers, badges and a portal is a thing for later, if ever.

1. Headline: who you partner with

One sentence naming the kind of product you want to integrate with, and the customer you share. "We integrate with tools that small accounting firms already use every day" beats "Partner with the leading platform for…" because a founder can tell in two seconds whether it is about them.

2. Live integrations, one row each

For every live integration: the partner's name and logo, then one sentence about what it does for a shared customer. Not "Seamless two-way sync with X", but "Your bookings appear as invoices in X without anyone retyping them." A visiting founder reads these rows to understand what an integration with you actually looks like, so they are the most persuasive part of the page. One honest row is better than six vague ones.

3. What you bring a partner

The section most pages skip. Describe the users you serve and the job they hire you for, in plain words, without inflating numbers. What a partner wants to know is whether your users need something they sell. Partnerships that work change what each side can sell to the users it already has; they are an ARPU argument, not a reach argument, and this section is where you make it.

4. What you look for

Three to five honest criteria. The most useful one: a capability you could not cheaply rebuild yourself. Anyone's coding agent can rebuild an ordinary feature in a weekend, so a partner worth integrating with holds something else, such as data, a network, a regulatory right or real expertise encoded in the product. Saying so filters out partners who would waste both your time. The moats worth integrating with are a good starting list.

5. How a partnership with you works

Four or five numbered steps, so a founder can picture the effort before they write:

  1. A short call to check the customer overlap.
  2. Agree what the integration does and where it appears in each product.
  3. Each side builds its own half.
  4. Agree the commercial terms, such as a revenue share on attributed sales.
  5. Launch, and list each other on your partner surfaces.

Saying plainly that each side builds its own half is a trust signal, not a caveat. It tells the reader nobody is promising to do their engineering for them.

6. One call to action

"Partner with us" or "Integrate with us", once, at the bottom, and optionally once near the top. It should lead to a page that already explains the collaboration and can take an application, not to a generic contact form and not to a sales calendar. A founder who has read this far wants to know what happens next; a form with fifteen fields tells them it is slow.

7. A short FAQ

Three or four questions founders actually ask: does this cost anything, who builds what, who supports a shared customer when something breaks, and how either side can end it. Honest answers here do more than any adjective in the headline.

What to leave off a partners page

  • A logo wall with no sentences. Logos prove you have partners; they don't say what an integration with you involves.
  • Affiliate language. "Earn a commission on every customer who signs up through your link" tells a software founder you want a sales channel, not an integration. Talk about what the integration lets each side sell.
  • Tiers and badges. Gold, silver and bronze partner levels at a few hundred users read as theatre.
  • Customer-facing setup instructions. Those belong in the product and in your help docs, where the customer actually is.
  • Numbers you cannot defend. A founder will do the arithmetic on any audience figure you print. Describe your users instead.

When should you build an in-product integrations screen?

The in-product screen is not marketing. It is where your customer discovers the partner feature you just built and switches it on, so it is part of shipping the integration. The test is simple:

  • Build it if your product already has a settings, connected-tools or apps area where the integration naturally fits, or if the integration genuinely needs somewhere for the user to turn it on or connect an account.
  • Skip it if the integration works inside an existing screen with no switch, and you would be creating a new page just to show one tile. That invents a page nobody asked for, and it ages badly.

If you do build it, give it one quiet line at the bottom, never a banner: "Want your product here? Partner with us," linking to the partners page. Your customers are there to get work done. The occasional one who runs a software company will find the link; the rest should not be asked to read a pitch.

Why a partners page compounds

Every other way to find integration partners costs something per contact: a researched cold message, a conference ticket, a marketplace listing that needs upkeep. The outreach message still matters for the partners you pick, but it never gets cheaper. A partners page does. Each live integration adds a row that shows the next founder what an integration with you looks like, and each partner who builds their own partners page with you on it adds a second front door you did not pay for.

That is also why the best time to write it is the day an integration ships, while the details are fresh and your coding agent already has the integration in context.

Where to link your partners page from

  • Your site footer, labelled "Partners" or "Integrate with us".
  • Your API or developer docs, near the top.
  • The changelog entry or post announcing each new integration.
  • Your in-product integrations screen, as the one quiet link above.
  • Each partner's own partners page, pointing back at yours.

On Ordana, the build prompt each member gives their own coding agent includes both surfaces: the public partners page every time, with its "Partner with us" button pointing at the collaboration's launch page, and the in-product screen only where the member's codebase shows one already fits. If you run partnerships without a team, the same outline works by hand; see integration partnerships without a partnerships team.


Related reading: