Picking your first integrations by watching where the copying happens

The short answer: build integrations for the tools that sit immediately before and after yours in the real workflow, identified by watching where people currently copy data by hand. Two is normally the right number for a first release, because each one is permanent maintenance against somebody else’s roadmap.

Integration roadmaps are usually assembled from a list of large, well-known products, on the reasonable-sounding theory that more users of a tool means more users of an integration with it. The theory fails because it substitutes popularity for adjacency, and adjacency is the thing that determines whether anyone ever switches the integration on.

Adjacency beats popularity

An integration removes work only if data currently moves between the two systems. If it does not, the integration is a logo on a page. The distinction is easy to state and surprisingly easy to lose once a large customer asks for something in passing.

The top row is the most valuable observation available in this kind of research, and it is common in instructional content because tutorials are obliged to show every step, including the tedious ones the author has stopped noticing. Those unnoticed steps are the whole point — the same reasoning behind finding micro-SaaS ideas in tutorial videos.

Mapping the workflow seams

Rather than collecting tool mentions, collect transitions. For each source, note the sequence of systems the work passes through and mark every point where a human moves data across a boundary. Ten to fifteen sources is normally enough for the same two or three seams to recur.

Two properties make a seam worth building for. It has to be frequent — weekly rather than quarterly — and it has to be lossy, meaning something gets retyped, reformatted or dropped in the crossing. A seam that is frequent but clean is an annoyance; a seam that is lossy but rare is a support ticket. The intersection is where an integration converts directly into retained users.

That last item is a genuinely reliable tell. When someone narrating a workflow says some version of “this part is a bit annoying, I have to do this manually”, they have identified an integration for you and told you it is painful, in one sentence, unprompted.

Why the list should stay short

Every integration is a permanent liability: an API that changes, an authentication flow that breaks, and support requests that arrive on someone else’s release schedule. That cost is fixed and recurring while the benefit scales only with how many of your users actually enable it.

The arithmetic is unforgiving for anything below roughly a third adoption. Two integrations that most users switch on, maintained properly, beat eight that a scattering of users touch and that quietly rot. Depth on the adjacent tool also gets you the second-order benefit breadth never does: your product starts to feel like part of the workflow rather than another destination.

Ship the escape hatch before the third integration

Once the two adjacent integrations exist, the requests keep arriving, and the temptation is to work down the list. The cheaper move is usually to build the generic mechanism that lets someone else close the gap.

Three primitives cover most of what a bespoke integration would have done. A clean import and export in a boring, universal format handles the occasional bulk crossing. Outbound webhooks let a user trigger work in a system you have never heard of. And a documented API — even a small one — turns every remaining request into something a customer’s own team can satisfy without waiting on your roadmap.

The trade is real and worth stating: an escape hatch serves technical users well and non-technical ones barely at all, so it is not a substitute for the two seams that matter most. But it changes the shape of the backlog. Instead of a growing queue of connectors each carrying permanent maintenance, you have a small set of mechanisms that age slowly and a short list of integrations chosen because the evidence justified them.

Keeping the evidence attached

Integration requests arrive constantly once you have users, and they arrive with urgency attached and no frequency data. A research-backed list gives you something to weigh them against — you can ask whether this request describes a seam you already observed, or a one-off that happens to be top of mind for the person asking.

Keeping the source and timestamp attached to each observed seam makes that argument concrete rather than a matter of taste, which is the general approach in prioritising features with research evidence. It also means the reasoning survives the person who did the research, so a new teammate can see why the list looks the way it does — the handoff problem covered in making research survive contact with the rest of your team.

Direction matters as much as the pairing

Two products can be adjacent and still not need a two-way integration. Deciding which direction the data should flow — and whether the reverse trip is ever taken — removes a surprising amount of work before any code is written.

Watch the seam carefully in the corpus. If people only ever pull records in, a read-only import covers the case entirely, and building writes back adds conflict resolution, permissions and an entire class of support conversation for no observed benefit. If they push results out and never look at them again, an outbound sync is enough. Genuine two-way sync is the most expensive thing on this list and is justified far less often than it gets built.

Frequency is the second dimension worth reading off the same evidence. Somebody doing this once a week is well served by a scheduled sync; a step that happens several times a day needs to feel immediate, which is a different engineering problem. The corpus usually answers both questions in the same clip, because the person narrating the workflow will say how often they do it while complaining about it.

Revisit when the workflow moves

Tool stacks in most segments turn over meaningfully every couple of years, and an integration roadmap set once at launch ages into a maintenance burden pointed at products people have left. Re-running the seam map annually is a small pass that occasionally saves a large amount of work, and it is the same recurring habit described in monitoring a niche with recurring research.

What it takes to map

Ten to fifteen instructional and workflow sources, watched for transitions rather than opinions, is enough to see the recurring seams. As of August 2026 that fits the $19 a month plan with 25 videos and 2 projects; $59 covers 80 videos and 8 projects if you are mapping several segments, and $199 covers 250 videos, 20 projects and 3 seats. The full comparison is on the pricing page.

Closing thought

The best integration you can ship is one your users would otherwise perform by hand every Monday. Those are visible in public, in the middle of videos about something else entirely, being narrated by people who have stopped noticing how much time the step costs them.