Your first integration: build the one your customers already ask for

You shipped the product. You got a handful of paying customers. Retention is holding, support is under control, and you've even run a referral loop. Now the advice starts arriving from every direction: "integrate with everything", "get listed in every partner marketplace", "white-label to bigger vendors", "give your feature away free so the giants can't match your cost structure."

Most of that advice is written for a Series A SaaS with a partnerships hire and a marketplace team. You have neither. You have you, Claude Code, and somewhere between 3 and 30 customers. Wiring up ten integrations at this stage doesn't multiply your growth. It multiplies your support surface for near-zero revenue.

Here's the move that actually works: build ONE integration first. The one your customers already ask for, or already hack around by hand. Everything else waits.

An integration does one of two jobs. Pick which.

Every integration you could build does one of exactly two things:

1. It removes a manual step your existing customers already do. They currently export a CSV from your app and paste it into their accounting tool. An integration kills that step. This is a retention play — it makes your product stickier for people already paying you.
2. It puts you in front of a partner's audience. You get listed in a bigger platform's marketplace, or a partner co-markets you to their users. This is an acquisition play — it's about reach.

The mistake solo founders make is chasing job 2 first, because it feels like growth. A logo on someone else's integrations page looks like progress. But at 3-30 customers, acquisition integrations almost always underperform: the partner's audience doesn't know you, the listing generates support questions from tyre-kickers, and you've built OAuth plumbing for a channel that converts a trickle.

Your first integration should almost always do job 1. Deepen the value for people already paying you. Retention compounds; a cold marketplace listing doesn't.

The brief is already sitting in your support tickets

You don't need to guess which integration to build. Your customers have been telling you.

Go back to two things you should already have running:

• Your support workflow. The integration customers keep asking for shows up as repeat tickets: "can this connect to X?", "is there a way to sync this with Y?". Three of the same request is a signal. Ten is a mandate.
• Your cancel reasons. When someone churns and writes "we moved to a tool that talks to our stack", that's the integration that would have kept them. Cancel reasons are the sharpest brief you'll ever get, because someone cared enough to leave over it.

If you tracked tickets and churn reasons as your own build inputs, you already have the answer. The first integration to build is the one that appears in both lists. Demand plus retention risk is as strong a signal as you get at this stage.

If nothing repeats yet, that's fine. It means you don't need an integration yet. Don't manufacture one to feel busy.

Build it, or partner for it?

Once you've picked the target, there are two ways to get there. They're not the same thing, and people conflate them constantly.

Build a direct integration when the value is a data flow: pull data in, push data out, sync on a schedule, react to a webhook. This is code you own. And this is exactly the kind of well-trodden, boilerplate-heavy work where an AI coding tool earns its keep. OAuth flows, token refresh, webhook receivers, retry logic, idempotency keys — Claude Code or Cursor can scaffold the whole plumbing layer from the partner's API docs, and you focus your attention on the mapping logic and the edge cases that are specific to your product. A first integration that would have eaten a fortnight of fiddly auth work becomes a couple of focused sessions.

Pursue a partnership when the value is distribution or trust, not data. A co-marketing deal, a referral arrangement, being recommended in a partner's onboarding, a joint webinar. There's usually little or no code. What there is instead is a relationship, and the price of admission is being able to point at real demand: "we have customers already asking to use your platform alongside ours." A partnership is a distribution deal you earn with evidence, not a logo swap you chase for the appearance of momentum.

Rule of thumb: if you can't yet name three of your own customers who'd use the partnership, it's too early to pursue it. Build the integration they asked for first, then let that adoption become the evidence for the partnership later.

The marketplace-listing trap

Someone will tell you to get listed in every partner marketplace and directory you can find. On a young product with a handful of customers, resist it.

Each listing is a front door you now have to staff. It surfaces you to people who don't know your product, who arrive with different assumptions, and who file support tickets that have nothing to do with your actual users. You get the support cost of a channel without the revenue of one.

List where you have evidence of demand, and nowhere else. If eight customers use a particular platform and would genuinely benefit from finding you in its marketplace, list there and instrument it. If it's speculative, skip it. You can always add the listing later, in about an hour, once there's a reason.

The UK first-integration playbook

Here's the concrete sequence for shipping your first one without over-building:

1. Pick the target from evidence. The integration that appears in both your repeat support tickets and your churn reasons. One target, not a shortlist.
2. Validate with three customers. Message the three who asked. "If this connected to X, would you use it this month?" You want a yes you can hold them to, not a polite maybe. Three real yeses is enough to justify the build.
3. Scaffold the plumbing with AI. Point Claude Code at the partner's API docs and let it build the auth, token refresh, and webhook layer. You review the mapping logic and the failure modes. Don't hand-roll OAuth in 2026; it's solved boilerplate.
4. Ship behind a flag. Release to the three validators first, not the whole base. A broken integration erodes more trust than a missing one, so prove it works on friendly users before you announce it.
5. Measure adoption before you build the second. How many customers actually connect it, and does it move retention? If adoption is real, you've earned the next integration. If it's crickets even from the people who asked, you've learned something cheap: stated demand and real demand diverge, and you just avoided building the next one blind.

That last step is the discipline the "integrate with everything" crowd skips. One integration, validated, shipped, measured. Then decide.

When a partnership actually beats an integration

There is a moment where a partnership is the better first move than an integration: when your customers don't need a data flow, they need to trust you, and a credible partner can lend you that trust faster than months of your own content could.

If a respected UK tool in your customers' stack will recommend you in their onboarding or newsletter, that borrowed credibility can be worth more than any API connection, and it costs you a relationship rather than a fortnight of code. But notice the precondition: you still need real customers using both products to make the pitch land. The integration-first path is what generates that evidence. Which is why, for almost everyone at 3-30 customers, the honest answer is still: build the one they asked for, then let the results open the partnership door.