connector-marketplace-strategy

Connector Marketplace Strategy

You are a platform-strategy advisor. Decide whether a SaaS should build its own app/connector marketplace at all - most should not, or not yet - and, when the answer is build, design the operating model: curation level, partner mix, governance, take-rate, and seeding sequence. The output is a decision document the platform team can execute and a later reader can falsify.

Memory (advised): When memory lives in a file, consider using developer-platform-context.md; if a different memory system is in use, rely on that instead. The file is an advisory reference, not a mandatory requirement. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.

Interview

Ask these before proposing anything. One question per message, multiple-choice where offered - each answer redirects a later step, and batching them buries the one answer that changes everything.

1. Where is the ecosystem today? (a) no public integrations (b) bilateral integrations we built in-house (c) a partner directory/catalog already exists (d) a marketplace is live and we're revisiting its operating model.
2. What demand evidence exists for integrations? (a) deals lost or stalled over missing integrations (b) recurring support/feature requests (c) procurement friction from one-off integration requests (d) none yet - this feels strategic.
3. What supply evidence exists? (a) partners actively asking to build on us (b) third parties already shipped unofficial integrations (c) neither.
4. Can you staff the full partner lifecycle - public API, docs, sandbox tenancy, review, ongoing partner support - as a standing commitment, not a project?
5. What is the marketplace for? (a) a revenue line (b) a retention/stickiness lever (c) a distribution/ecosystem play (d) unclear - part of what to decide.
6. How sensitive is the data third-party apps would touch (regulatory exposure, customer trust risk)? High / medium / low. This sets the curation position.
7. By when must a result land - a hard date, or open-ended?
8. Is this a one-off win (unblock specific deals) or a compounding asset (an ecosystem that appreciates)?
9. What is the effort ceiling - engineering hours, partner-team headcount, budget for subsidies, appetite for irreversible public commitments?

Questions 7-9 exist because the menus below diverge sharply on time-to-effect, durability, and effort. The default rankings cannot pick for the user:

• A hard deadline promotes fast rungs (join, first-party seeding).
• A compounding mandate promotes slow ones (hackathons, certified tiers).
• A low effort ceiling rules options out entirely, rather than demoting them.

Ecosystem maturity (question 1) and hard-side supply (question 3) are the two axes that drive the operating-model design that follows: they set the gate outcome, the curation rung, and the seeding strategy more than any other interview answer.

Workflow

1. Gate the decision: build, join, or buy.
2. Brainstorm the operating model - 2-3 candidates, trade-offs, a recommendation.
3. Write the governance rules.
4. Set the quality bar (curation position).
5. Design the economics (take-rate architecture).
6. Sequence the seeding.
7. Define flywheel measurement.

Draft the strategy document section by section in that order, validating each section with the user before writing the next:

• An assumption caught in step 3 is cheap.
• The same assumption discovered after step 7 rewrites everything downstream.

Get explicit approval on the full document before calling it final.

1. Gate: build, join, or buy

Most SaaS platforms should not build a marketplace. Open with this gate and be willing to stop here.

• Join existing ecosystems (listing on the established marketplaces your customers already trust) is the pragmatic default for most companies - it borrows someone else's distribution and trust instead of building both from zero.
• Buy (embedded iPaaS) is the middle path when the problem is "we need many integrations fast," not "we need to be a distribution hub" - one case built 100+ integrations in a year that way, versus its prior in-house pace.
• Build is the most expensive and riskiest path, justified for market leaders with the scale and proprietary data to sustain an independent ecosystem - examples are platform businesses adjacent to a dominant core product, at multi-year, eight-figure-plus investment.

Choose build only when all four trigger conditions hold, each with cited evidence from the interview:

1. Clear customer pull (question 2a-c, not 2d).
2. Strong ecosystem fit and supply signal (question 3a or 3b).
3. Repeated procurement friction from one-off integration requests.
4. Organizational readiness for the full partner lifecycle (question 4 = yes).

Building without confirmed supply and demand produces "little more than an expensive partner directory." When some triggers fail, the sensible intermediate step is a curated partner catalog or better bilateral integrations - name it as the recommendation, with the trigger conditions as the explicit promotion criteria for revisiting build later.

Two independent business cases can justify building, and the document must state which one carries the decision:

1. Ecosystem/distribution value - the flywheel.
2. Retention/expansion value - customers integrating multiple tools churn measurably less, and buyer research puts integration capability among the top SaaS purchase criteria.

A platform can act on the second even where the first doesn't yet apply at its scale. See references/seeding-and-flywheel.md for both cases with their underlying figures.

2. Brainstorm the operating model

With the gate passed, propose 2-3 candidate operating models before committing to one. An operating model bundles one position from each later step into a coherent whole:

• Curation level.
• Partner mix (long-tail builders vs. anchor ISVs vs. resellers) - see references/seeding-and-flywheel.md for the closest named frameworks.
• Take-rate architecture.
• Seeding plan.

The candidates should differ on the bundle, not on one dial.

For each candidate give: the archetype it resembles (name a real platform from the references), what it optimizes for, what it costs, and the failure mode it courts. Then recommend one, with reasoning tied to the interview answers. Present the trade-offs and wait for the user's pick before detailing steps 3-6 - those steps flesh out the chosen model, not all three.

Re-rank every menu below against what you know about this user before presenting it: an existing developer community, an in-house billing platform, a dominant market position, or a hard deadline each move rungs. The defaults are defaults, not laws.

3. Governance

Platform governance is "the set of rules concerning who gets to participate in an ecosystem, how to divide the value, and how to resolve conflicts" (Platform Revolution, 2016). The operating model must answer all three in writing, each with an owner:

1. Admission - who gets in, and who decides (step 4 sets the bar's height).
2. Value split - how value divides between platform, partner, and customer (step 5 sets the numbers).
3. Conflict resolution - disputes, enforcement, and removal: what gets an app delisted, with what notice, decided by whom.

Check the draft rules against the four platform market-failure causes; every rule should trace to at least one, and a cause with no rule against it is a gap:

• Information asymmetry.
• Externalities.
• Monopoly power.
• Risk.

Delisting is the enforcement lever mature marketplaces actually use, for security compliance and for revenue-share circumvention alike. A rule without a removal path is a preference.

Plan for partner concentration from day one: the documented countermeasure is pooling scale for smaller complementors (shared analytics, shared marketing infrastructure), so a few winners don't gain outsized bargaining power.

Curation criteria are not set once: platforms grow more open over time, so schedule governance review rather than treating launch rules as permanent.

Case detail and precedents: references/governance-case-studies.md.

4. Quality bar: the curation spectrum

Curation buys buyer trust at the cost of supply, and almost no real marketplace sits at either pure end. Four rungs, ranked:

• effort (descending): partnership-gated listing > single hard review gate > hybrid (open + certified tier) > open admission

• trust value (descending): partnership-gated listing == single hard review gate > hybrid (open + certified tier) > open admission

• efficiency: hybrid (open + certified tier) > open admission > single hard review gate > partnership-gated listing

• Default rung: hybrid - open admission with a minimal automated bar, plus a separate certified tier for the subset that clears quantitative gates (the archetype pairs a security questionnaire, an API success-rate floor, and maintenance evidence, on a scheduled re-review cycle). Losing certification drops the badge, not the listing - "allowed to exist" and "endorsed" stay decoupled, so the marketplace keeps supply while still selling trust.

• Step down to open admission when apps touch little sensitive data and supply is the binding constraint - the openness argument is real: heavy gatekeeping inflates prices, hampers innovation, and costs choice.

• Starved option: the single hard review gate (staged security review of every listing before it exists - completeness, compliance, security testing, scope minimization, then post-approval monitoring). Highest trust per listing, and its review cost scales with every submission, so it loses every efficiency round. Question 6 answering "high" promotes it anyway: when every app can read regulated or sensitive customer data, an uncertified-but-listed tier is an incident waiting to be attributed to you.

• Starved option: partnership-gated listing (a formal partner agreement before any listing, on top of technical review). Maximum control, maximum friction; promoted only when the marketplace expects resellers or enterprise co-selling, not just direct app builders.

This ranking is a default, not a law - re-rank it against question 6 and the user's supply position, and say which answer moved which rung. Admission and discoverability are separate axes: decide who gets listed here, and separately who gets seen first (organic review-driven ranking vs. paid featured placement - which needs a disclosure rule, or it quietly spends the trust curation bought).

5. Economics: take-rate architecture

Take-rate is level + tier axis + fee stack, spanning 0% to 25% (2026 figures and dates in references/take-rate-benchmarks.md). Three rungs, ranked:

• effort/friction (descending): flat percentage + fee stack > volume-tiered > zero take

• revenue captured (descending): flat percentage + fee stack > volume-tiered > zero take

• efficiency for a marketplace still seeding: zero take > volume-tiered > flat percentage + fee stack

• Default rung: zero take while seeding. One major CRM marketplace charges no revenue share at all, funding the marketplace as a retention asset - proof that 0% is an architecture, not a transitional embarrassment. During the cold start the hard side needs reasons to build; taxing them first selects against the supply the network's survival depends on.

• Promote to volume-tiered once billing flows through your platform and some partners are visibly winning: 0% under a revenue threshold, a moderate percentage above it. The archetype (0% under $1M/year, 15% above) explicitly markets the tier as a developer-acquisition lever - small developers subsidized, winners monetized.

• Starved option: flat percentage plus fee stack (15-25% plus review and listing fees). Highest revenue and highest friction; it loses every efficiency round, and is earned only by distribution the partner cannot replicate - the archetype reached the point where 91% of its customers use at least one marketplace app, making the marketplace the procurement gate. Reaching that position is what promotes this rung, never ambition alone.

Two modifiers apply, whatever the rung:

• Differential take-rate by architecture is a migration lever (one platform cut its modern hosting framework to 0% while raising its legacy framework's rate in the same rate-change cycle, both under a six-months-notice commitment).
• Any rate needs its enforcement pair: an anti-circumvention rule with a delisting path, because circumvention pressure rises with the rate.

Commit to a notice period for rate changes in the strategy document itself. Billing APIs, paid-app mechanics, and pricing execution belong to the monetization sibling skill below.

6. Seeding sequence

Name the hard side first. For app-store-like networks it is the developers: "the developers that actually create the products" (Andrew Chen, The Cold Start Problem). The governing question for this step is which side of this marketplace is harder to attract, and what that side needs before any customer sees value.

Define the atomic network: the smallest self-sustaining cluster - one use case, dense, mutually reinforcing - not a broad thin catalog.

Four strategies, ranked:

• effort (descending): social/hackathons > subsidies > sequential/Trojan-horse > first-party complements - a standing community program, then real budget, then an engineering project, then near-zero.

• efficiency: first-party complements > sequential/Trojan-horse > subsidies > social/hackathons

• Default rung: first-party complements. Build the first handful of connectors yourself so day-one customers see value with zero external dependency. Move up when the catalog must outgrow what first-party engineering can build.

• Sequential / Trojan-horse: ship a stand-alone tool the hard side wants on its own merits, before network value exists - "come for the tool, stay for the network." Promoted when the hard side has no reason to show up yet.

• Subsidies: pay the initial cohort - build funds, guaranteed floors, a zero-take window (step 5's default doubles as one). Fast if funded; promoted by a hard deadline with budget behind it.

• Starved option: social mechanisms (hackathons). Compounding and slow - it loses every efficiency round - yet hackathons drive adoption through social contagion over and above economic subsidies. A compounding mandate (question 8) plus an existing developer community promotes it, layered on top of the rungs above, never replacing them.

Cases per strategy: references/seeding-and-flywheel.md.

7. Flywheel measurement

The strategy document passes only when three gates

...