connector-marketplace-strategy

{
  "skill_name": "connector-marketplace-strategy",
  "evals": [
    {
      "id": 1,
      "prompt": "I'm VP Product at Threadline, an HR onboarding SaaS. 320 customers, about $4.1M ARR. Last year we lost six enterprise deals where the buyer explicitly named missing integrations as the reason, and support gets integration requests most weeks. We've hand-built nine integrations in-house (Workday, BambooHR, a few ATSs). We have no public API, no developer docs, no sandbox, and no partner manager - engineering is 14 people total and fully committed to the core roadmap. Nobody outside the company has ever built anything on us and no partner has ever asked to. Our CEO wants an app marketplace live by Q2 and has already said it in an all-hands. Put together our marketplace strategy.",
      "expected_output": "A gated decision that declines to build now: the four build trigger conditions evaluated against the evidence, two of them failing (no supply signal, no organizational readiness for the partner lifecycle), with a curated partner catalog or deeper bilateral integrations recommended as the intermediate step and the trigger conditions restated as promotion criteria.",
      "files": [],
      "expectations": [
        "Applies a build / join / buy gate before proposing any marketplace design",
        "Recommends against building a marketplace now",
        "Names all four build trigger conditions that must hold before choosing build",
        "Identifies the absent supply signal (no third party has built on the platform, no partner has asked) as a failed trigger condition",
        "Identifies the absent organizational readiness for the full partner lifecycle (no public API, docs, sandbox, or partner staffing) as a failed trigger condition",
        "Credits customer pull as a satisfied trigger condition, citing the six lost deals and the recurring support requests",
        "Recommends a curated partner catalog or better bilateral integrations as the intermediate step instead",
        "States the four trigger conditions as explicit promotion criteria for revisiting the build decision later",
        "Warns that building without confirmed supply and demand produces little more than an expensive partner directory",
        "Does not deliver a take-rate, curation ladder, or seeding plan as the headline recommendation"
      ]
    },
    {
      "id": 2,
      "prompt": "Cadence Ops here - field-service management SaaS, 1,100 customers, $22M ARR. Our partner directory lists 40 integrations. Six partners have asked to be able to charge for their apps, and three third parties have already shipped unofficial integrations by reverse-engineering our web app. We do have a documented public API and two partner engineers. I need the full marketplace operating model document today: curation, revenue share, governance rules, seeding plan, the whole thing. Board meeting is Thursday.",
      "expected_output": "An interview conducted one question at a time before any proposal, then 2-3 candidate operating models that differ across the whole bundle, each with a platform archetype, what it optimizes for, its cost and failure mode, a recommendation tied to the answers, and a pause for the user's pick before detailing governance, curation, take-rate and seeding.",
      "files": [],
      "expectations": [
        "Asks interview questions before proposing any operating model, despite the same-week deadline",
        "Asks one question per message rather than batching the questions into a single list",
        "Asks the effort ceiling: engineering hours, partner-team headcount, subsidy budget, or appetite for irreversible public commitments",
        "Asks whether this is a one-off win or a compounding asset",
        "Asks by when a result must land",
        "Presents 2-3 candidate operating models that differ across the whole bundle (curation level, partner mix, take-rate, seeding), not on a single dial",
        "Gives each candidate the real-platform archetype it resembles, what it optimizes for, what it costs, and the failure mode it courts",
        "Recommends one candidate with reasoning tied back to specific interview answers",
        "Waits for the user's pick before detailing governance, curation, take-rate, and seeding",
        "Drafts the document section by section with user validation between sections rather than delivering every section at once"
      ]
    },
    {
      "id": 3,
      "prompt": "Lumen Freight, logistics visibility SaaS. Our marketplace launches in five months with 12 partner apps lined up, none of them charging yet. Billing already runs through our own platform, so we can collect on partners' behalf from day one. Our CFO wants 25% of partner app revenue, plus a $2,500 one-time security review fee and a $400 annual listing fee - her argument is that the big enterprise app stores charge that and nobody walks away from Apple over 30%. Tell me how to structure the rate and what to announce to partners.",
      "expected_output": "A recommendation of zero take-rate through the seeding phase, with the 25%-plus-fee-stack rung identified as one earned by irreplaceable distribution rather than ambition, an explicit promotion path to a volume-tiered rate, an anti-circumvention rule with a delisting path, and a committed notice period for rate changes.",
      "files": [],
      "expectations": [
        "Recommends against a 25% take-rate at launch",
        "Recommends a zero take-rate during the seeding phase",
        "States that zero take-rate is a deliberate architecture rather than a transitional state, citing a major marketplace that charges no revenue share and funds itself as a retention asset",
        "Explains that taxing the hard side during the cold start selects against the supply the network's survival depends on",
        "States that a 15-25% flat rate is earned by distribution the partner cannot replicate, naming the procurement-gate position (91% of one platform's customers using at least one marketplace app) as what earns it",
        "Names the promotion condition to a volume-tiered rate: billing flowing through the platform plus some partners visibly winning",
        "Gives the volume-tiered archetype with its threshold shape (0% under $1M per year, 15% above)",
        "Treats take-rate as level plus tier axis plus fee stack rather than a single percentage",
        "Pairs whatever rate is chosen with an anti-circumvention rule carrying a delisting path",
        "Commits a notice period for future rate changes in the document itself, citing the six-months-notice pattern",
        "Does not use Apple or Google's 30% as justification for the proposed rate"
      ]
    },
    {
      "id": 4,
      "prompt": "Veriquil builds clinical trial management software for CROs and research sites. Third-party apps on our planned marketplace would read de-identified patient records, site financials, and protocol deviation logs. Our head of product's position is: open app store, anyone can publish, we review nothing - supply is the binding constraint and we only have four launch partners committed. Separately she wants to sell the homepage 'Featured' slot to partners for $5,000 a quarter to help fund the program. Give me the quality bar and the placement design.",
      "expected_output": "A curation spectrum with the hybrid default named, then the single hard review gate promoted above it because apps read regulated and sensitive data, with the promotion attributed to that answer, the openness counter-argument acknowledged, and a disclosure rule required for the paid featured placement as a separate axis from admission.",
      "files": [],
      "expectations": [
        "Presents the curation choice as a ranked spectrum of four rungs, not a binary open-versus-closed decision",
        "States that the default rung is hybrid: open admission with a minimal automated bar plus a separate certified tier",
        "Promotes the single hard review gate above the default for this case, because every app can read regulated or sensitive customer data",
        "Says explicitly which interview answer (data sensitivity = high) moved which rung",
        "Acknowledges that the single hard review gate loses the efficiency ranking because review cost scales with every submission",
        "Warns that an uncertified-but-listed tier is an incident waiting to be attributed to the platform when apps read sensitive data",
        "Describes the review gate as staged - completeness, compliance, security testing, scope minimization - followed by post-approval monitoring",
        "Names the openness counter-argument (heavy gatekeeping inflates prices, hampers innovation, costs choice) as the live trade-off rather than ignoring it",
        "Treats admission (who gets listed) and discoverability (who gets seen first) as separate axes",
        "Requires a disclosure rule labeling the paid featured placement",
        "Warns that undisclosed paid placement reading as an editorial pick spends the trust curation bought"
      ]
    },
    {
      "id": 5,
      "prompt": "Brightloom Retail, cloud POS platform. Our marketplace has been live 14 months with about 180 apps. Two partners now account for 61% of marketplace GMV between them and both are pushing for preferential terms and homepage placement. Last month a security engineer found one listed app forwarding customer transaction data to an undisclosed analytics vendor - and nobody internally could say who has authority to pull an app, on what notice, or what the partner's recourse is. All we have written down today is a listing requirements page. Legal has asked me for 'the marketplace rules doc'. Draft it.",
      "expected_output": "A governance document structured around admission, value split, and conflict resolution, each with a named owner, including a concrete removal path with notice and decision authority, every rule traced to at least one of the four platform market-failure causes, a pooled-scale countermeasure for the GMV concentration, and a scheduled governance review.",
      "files": [],
      "expectations": [
        "Structures the governance rules around three questions: admission, value split, and conflict resolution",
        "Attributes that three-part definition of platform governance to a named source (_Platform Revolution_)",
        "Assigns a named owner to each of the three governance answers",
        "Specifies a removal path: what gets an app delisted, with what notice, decided by whom",
        "Checks the draft rules against the four named causes of platform market failure",
        "Names all four causes: information asymmetry, externalities, monopoly power, and risk",
        "Treats a market-failure cause with no rule written against it as a gap in the document",
        "Maps the undisclosed data-forwarding incident to information asymmetry",
        "Treats the 61% GMV concentration in two partners as a governance problem, not only a commercial negotiation",
        "Prescribes pooling scale for smaller complementors - shared analytics, shared marketing infrastructure - as the standing concentration countermeasure",
        "Schedules a recurring governance review rather than treating the launch rules as permanent, because platforms tend to grow more open over time"
      ]
    },
    {
      "id": 6,
      "prompt": "Onwards Labs - API-first expense management SaaS, 2,400 customers, marketplace shell already built and styled. The plan on the table from our ecosystem lead: launch with 60 connectors spread across every category we can think of (accounting, HRIS, travel, card issuers, BI, procurement), run a $50,000 hackathon in month one to generate buzz, and stand up a build fund. Constraints: the launch date is fixed four months out, finance has not approved any subsidy budget yet, and our API portal has 31 registered developers, nearly all of them internal teams at existing customers. We have no developer community, no Discord, no meetups. Sanity-check this plan and give me the seeding sequence.",
      "expected_output": "A seeding sequence that names the developers as the hard side, replaces the 60-connector breadth plan with a dense atomic network in one use case, defaults to first-party complements, and demotes the hackathon as the starved option whose two promotion conditions both fail here, with the subsidy rung flagged as unfunded.",
      "files": [],
      "expectations": [
        "Names the connector and app developers as the hard side of this network",
        "States that the hard side determines whether the network survives and must be given a reason to build before customers see value",
        "Defines the atomic network as the smallest self-sustaining cluster - one use case, dense and mutually reinforcing",
        "Rejects the 60-connectors-across-every-category plan in favor of density over breadth, naming a broad thin catalog as the failure",
        "Recommends first-party complements as the default seeding rung: the platform builds the first handful of connectors itself so day-one customers see value with no external dependency",
        "Gives the promotion condition off first-party complements: when the catalog must outgrow what first-party engineering can build",
        "Demotes the hackathon, stating that social mechanisms lose every efficiency round",
        "Names the two conditions that would promote hackathons anyway: a compounding mandate plus an existing developer community",
        "Notes that both hackathon promotion conditions fail here, citing the fixed four-month deadline and the absence of a developer community",
        "Notes that subsidies are promoted by a hard deadline only when real budget sits behind them, which is not yet the case here",
        "Names the sequential / Trojan-horse option - ship a stand-alone tool the hard side wants on its own merits, 'come for the tool, stay for the network' - as the rung for a hard side with no reason to show up yet"
      ]
    },
    {
      "id": 7,
      "prompt": "Pathvine, vertical SaaS for veterinary clinic groups. 240 customers, $9M ARR. Our VP Product wrote a one-pager arguing the marketplace creates a flywheel: more apps attract more customers, more customers attract more apps, and it compounds. Our CEO shot back that at 240 clinics nobody is going to build a business on our platform, so the flywheel argument is fantasy and the whole thing is a distraction. They've asked me to settle it and to say what we'd actually measure in year one if we go ahead. What's the honest read?",
      "expected_output": "The two business cases separated and argued independently, with the retention/expansion case named as the one that can carry the decision at this scale, a requirement that the document state which case carries it, and a year-one metric set led by supply-side metrics with mature-platform figures labeled as context rather than targets.",
      "files": [],
      "expectations": [
        "Separates the ecosystem/distribution (flywheel) case from the retention/expansion case as two independent justifications",
        "States that a platform can act on the retention/expansion case even where the flywheel case does not apply at its scale",
        "Requires the strategy document to name which single case carries the decision",
        "States that a document blending the two cases cannot be falsified",
        "Cites the retention evidence that customers integrating multiple tools churn measurably less",
        "Names the 4+ integrations cluster as the switching-cost threshold to watch",
        "Cites buyer research placing integration capability among the top SaaS purchase criteria (86% importance)",
        "Leads the year-one metric set with supply-side metrics, stating the supply side is the hard side and fails first",
        "Includes at least three supply-side metrics from: active partners with a live listing, time from partner signup to first live listing, catalog freshness, partner revenue concentration",
        "Labels mature-platform figures such as 91% of customers using at least one marketplace app as context anchors, not year-one targets",
        "States that marketplace-attributed deal influence is inherently soft attribution rather than presenting it as a hard number"
      ]
    },
    {
      "id": 8,
      "prompt": "Statlas, product analytics SaaS, $17M ARR. Sales has a running list of 40-something named integrations that show up in RFPs - Salesforce, HubSpot, Zendesk, Intercom, Stripe, NetSuite, the usual suspects. Nothing exotic. Our in-house pace is about five integrations a year with the two engineers we can spare. Our head of platform wants to build a full marketplace with a developer program, partner tiers, and a revenue share. While you're at it, tell me what payout cadence and merchant-of-record setup we should use for paying partners.",
      "expected_output": "A gate that selects buy (embedded iPaaS) rather than build, because the problem is integration volume rather than distribution-hub ambition, with the build path's true cost stated, no operating-model design produced for an unselected path, and the payout-cadence and merchant-of-record question routed to the marketplace monetization skill.",
      "files": [],
      "expectations": [
        "Runs the build / join / buy gate before responding to the marketplace request",
        "Recommends the buy path (embedded iPaaS) as the fit for this situation",
        "Distinguishes the buy trigger explicitly: the problem is needing many integrations fast, not needing to become a distribution hub",
        "Contrasts the embedded-iPaaS pace (a sourced case building 100+ integrations in a year) against the stated in-house pace of about five per year",
        "States that build is justified for market leaders with the scale and proprietary data to sustain an independent ecosystem, at multi-year, eight-figure-plus investment",
        "Evaluates join - listing on the established marketplaces customers already trust - as the pragmatic default that borrows existing distribution and trust",
        "Does not treat 40 RFP-requested integrations as evidence of a supply signal",
        "Does not design a take-rate, curation ladder, or partner-tier program for a path that was not selected",
        "Declines to specify payout cadence and merchant-of-record posture, routing that question to the marketplace monetization skill"
      ]
    }
  ],
  "trigger_queries": [
    {
      "query": "Should we build our own app marketplace or just list on the marketplaces our customers already use?",
      "should_trigger": true
    },
    {
      "query": "We're thinking about launching an integration marketplace next year - where do we even start?",
      "should_trigger": true
    },
    {
      "query": "What revenue share should we charge partners who list apps on our platform?",
      "should_trigger": true
    },
    {
      "query": "Is our company actually ready to run an app ecosystem?",
      "should_trigger": true
    },
    {
      "query": "curated vs open admission for third-party apps - how do we decide which way to go",
      "should_trigger": true
    },
    {
      "query": "How do we get developers to build integrations for us when nobody is asking to?",
      "should_trigger": true
    },
    {
      "query": "Our partner directory has 40 integrations and partners now want to charge money. What's the next step?",
      "should_trigger": true
    },
    {
      "query": "Design the operating model for our connector marketplace.",
      "should_trigger": true
    },
    {
      "query": "We keep losing enterprise deals because we don't have enough integrations. What's the play here?",
      "should_trigger": true
    },
    {
      "query": "Do we need an app store, or would embedded iPaaS get us there faster?",
      "should_trigger": true
    },
    {
      "query": "What take-rate is defensible for a marketplace that hasn't launched yet?",
      "should_trigger": true
    },
    {
      "query": "How do we seed a two-sided developer ecosystem from zero?",
      "should_trigger": true
    },
    {
      "query": "who gets to list on our platform and who decides - we have literally nothing written down",
      "should_trigger": true
    },
    {
      "query": "Our CEO wants an app store by Q3. Talk me out of it or help me scope it.",
      "should_trigger": true
    },
    {
      "query": "How curated should our third-party app program be if the apps can read patient data?",
      "should_trigger": true
    },
    {
      "query": "Should we charge 15% or 20% on partner app revenue?",
      "should_trigger": true
    },
    {
      "query": "we have no partner program, no public API, and the board wants an ecosystem story by next quarter",
      "should_trigger": true
    },
    {
      "query": "What metrics tell us whether our app marketplace is actually working in year one?",
      "should_trigger": true
    },
    {
      "query": "Two partners are 60% of our marketplace revenue and now they want better terms. What do we do?",
      "should_trigger": true
    },
    {
      "query": "Is a hackathon a good way to kickstart our integration ecosystem?",
      "should_trigger": true
    },
    {
      "query": "Write the rules for who can publish on our platform and what gets them removed.",
      "should_trigger": true
    },
    {
      "query": "We're a $6M ARR vertical SaaS. Does an app store make any sense at our size?",
      "should_trigger": true
    },
    {
      "query": "how do the big platforms decide what percentage to take from app developers",
      "should_trigger": true
    },
    {
      "query": "What's the case for building an ecosystem when the flywheel argument is weak at our scale?",
      "should_trigger": true
    },
    {
      "query": "Our marketplace is live but stale - half the listings haven't been touched in a year. Rethink the operating model.",
      "should_trigger": true
    },
    {
      "query": "Help me choose between a certified tier and reviewing every single app before it goes live.",
      "should_trigger": true
    },
    {
      "query": "What do we need in place before we open our platform up to third-party builders?",
      "should_trigger": true
    },
    {
      "query": "Should the first connectors be ones we build ourselves or ones partners build?",
      "should_trigger": true
    },
    {
      "query": "We want to raise our commission from 15% to 20%. How do we do that without blowing up partner trust?",
      "should_trigger": true
    },
    {
      "query": "Is there ever a reason to charge nothing at all for apps on our marketplace?",
      "should_trigger": true
    },
    {
      "query": "how many apps do we actually need at launch for this to look credible",
      "should_trigger": true
    },
    {
      "query": "Our legacy framework and our new one - can we price the commission differently to push partners to migrate?",
      "should_trigger": true
    },
    {
      "query": "Partners are billing customers outside our platform to dodge the rev share. How should we handle that?",
      "should_trigger": true
    },
    {
      "query": "Plan the ecosystem strategy for our platform: who we let in, what we charge them, and how we get them.",
      "should_trigger": true
    },
    {
      "query": "We want to put a revenue line on our app directory - what are the options and what does each cost us in supply?",
      "should_trigger": true
    },
    {
      "query": "should we be a platform other people build on, or just keep integrating with everyone ourselves",
      "should_trigger": true
    },
    {
      "query": "Build me the decision doc for whether we launch an app marketplace.",
      "should_trigger": true
    },
    {
      "query": "How do I convince my exec team that not building a marketplace is the right call?",
      "should_trigger": true
    },
    {
      "query": "What payout cadence and hold window should we use for paying app developers?",
      "should_trigger": false
    },
    {
      "query": "Should we be merchant of record for paid apps, or let developers bill customers directly?",
      "should_trigger": false
    },
    {
      "query": "How do we handle VAT and marketplace-facilitator tax obligations on app sales?",
      "should_trigger": false
    },
    {
      "query": "Which billing rails do we need so revenue share is collected at source?",
      "should_trigger": false
    },
    {
      "query": "Design the billing API that third-party apps call to charge our customers.",
      "should_trigger": false
    },
    {
      "query": "How do we implement fee waivers for partners in our incentive tier?",
      "should_trigger": false
    },
    {
      "query": "What should our automated pre-screening check before a human reviewer ever opens an app submission?",
      "should_trigger": false
    },
    {
      "query": "Write the re-review triggers for when an already-published app ships an update.",
      "should_trigger": false
    },
    {
      "query": "How do we harden our app publish channel against supply-chain attacks?",
      "should_trigger": false
    },
    {
      "query": "What's a fair appeal path for a developer whose app submission we rejected?",
      "should_trigger": false
    },
    {
      "query": "Design the permission and data-access audit checkpoints inside our app review pipeline.",
      "should_trigger": false
    },
    {
      "query": "What screenshot dimensions and demo-video specs should we require on every listing?",
      "should_trigger": false
    },
    {
      "query": "Write objective reject criteria for listing descriptions that are too thin.",
      "should_trigger": false
    },
    {
      "query": "How should we design the category taxonomy for our marketplace?",
      "should_trigger": false
    },
    {
      "query": "Our listing content is decaying - what's the staleness enforcement rule?",
      "should_trigger": false
    },
    {
      "query": "How big should our founding launch cohort of partners be, and how do we stage the announcement?",
      "should_trigger": false
    },
    {
      "query": "How do we split MDF between marketplace-wide demand gen and per-partner co-marketing?",
      "should_trigger": false
    },
    {
      "query": "Set up an app-of-the-month spotlight program for our marketplace.",
      "should_trigger": false
    },
    {
      "query": "We're selling featured placement slots on the marketplace homepage - how do we run that program day to day?",
      "should_trigger": false
    },
    {
      "query": "Our AppExchange listing gets plenty of views but almost no installs. How do we fix the funnel?",
      "should_trigger": false
    },
    {
      "query": "How do we get more reviews on our Shopify app listing without breaking their rules?",
      "should_trigger": false
    },
    {
      "query": "Which keywords should go in our HubSpot marketplace listing title and tagline?",
      "should_trigger": false
    },
    {
      "query": "How do we chase the Built for Shopify badge and does it actually move rank?",
      "should_trigger": false
    },
    {
      "query": "Should we build a Fivetran connector ourselves or wait for them to build one for us?",
      "should_trigger": false
    },
    {
      "query": "Can our REST API realistically support CDC for a data-pipeline integration?",
      "should_trigger": false
    },
    {
      "query": "Which ETL platforms should we get listed on as a source connector first?",
      "should_trigger": false
    },
    {
      "query": "How do we prioritize which technology partners to integrate with next quarter?",
      "should_trigger": false
    },
    {
      "query": "What are the graduation gates between a referral partnership and an OEM one?",
      "should_trigger": false
    },
    {
      "query": "Should our technology partnerships function report into sales or into product?",
      "should_trigger": false
    },
    {
      "query": "How fast should a new partner developer get a sandbox tenant after signup?",
      "should_trigger": false
    },
    {
      "query": "Should partner developer registration be self-service or application-gated?",
      "should_trigger": false
    },
    {
      "query": "Should we add a GraphQL layer before or after building out our webhook surface?",
      "should_trigger": false
    },
    {
      "query": "Are we a product or a platform? We can't agree on whether to open our API to outsiders at all.",
      "should_trigger": false
    },
    {
      "query": "How do I get my SaaS listed on the Salesforce AppExchange?",
      "should_trigger": false
    },
    {
      "query": "What's the best marketplace to sell my Shopify theme on?",
      "should_trigger": false
    },
    {
      "query": "We run a two-sided marketplace for freelance designers and supply liquidity is terrible in three cities. Fix it.",
      "should_trigger": false
    },
    {
      "query": "Design our reseller channel program - margins, deal registration, and partner tiers.",
      "should_trigger": false
    },
    {
      "query": "What rate limits should we publish for third-party apps calling our public API?",
      "should_trigger": false
    }
  ]
}

# Governance and quality-bar case studies

## The Platform Revolution framework

_Platform Revolution_ (Parker, Van Alstyne, Choudary, 2016) defines platform governance as "the set of rules concerning who gets to participate in an ecosystem, how to divide the value, and how to resolve conflicts." An operating model that leaves any of the three unanswered is incomplete by definition - admission criteria, value split, and dispute/removal process each need a written answer with an owner.

Their curation argument: trust is central to any marketplace with interaction risk, and it is built by curating participants until both sides are comfortable with the residual risk of engaging. Curation is not a one-time gate - the book notes platforms tend to grow more open over time, which requires continually re-adjusting curation criteria rather than setting them once at launch.

Their four named causes of platform market failure (good interactions failing to occur, or bad ones occurring) are the diagnostic checklist for why governance rules exist at all:

1. **Information asymmetry** - one side knows something material the other cannot see (their example: a seller who knows goods are fake and doesn't disclose it).
2. **Externalities** - an interaction imposes costs on parties outside it.
3. **Monopoly power** - one participant, or the platform itself, extracts beyond its contribution.
4. **Risk** - the residual chance of a bad outcome that deters good interactions.

Walk each of the four against your marketplace design; every governance rule you write should trace back to at least one of them.

## Two quality-bar architectures

**Ladder - HubSpot's listed/certified two-tier model.**

- Any app meeting minimal requirements gets "listed."
- A separate, harder "Certified" tier layers on quantitative gates (2026: a security questionnaire, 95% API success rate, sustained maintenance evidence, a minimum review-quality threshold), reviewed by a dedicated Ecosystem Quality team on a 2-4 week cycle.

Losing certified status keeps the app listed, just without the badge - decoupling "allowed to exist" from "endorsed by the marketplace." The ladder lets a marketplace stay open to low-risk apps while still signaling trust for the subset that clears a higher bar.

**Single gate - Zoom's four-stage review pipeline.**

1. Submission-completeness check.
2. Compliance review (data handling against Zoom's own privacy/security requirements).
3. Security review (OWASP Top 10 testing, OAuth-scope minimization - unused or excessive scopes get flagged for removal).
4. Post-approval ongoing monitoring with removal authority.

Review duration scales with app quality and scope clarity, which itself incentivizes developers to submit minimal, well-documented scope requests.

Choose the gate when every listing carries real data-access risk. Choose the ladder when most listings are low-risk and the trust signal only needs to cover a subset.

## Enforcement precedents

- **Delisting as the compliance lever (Salesforce, 2026):** mandatory new security controls for Connected Apps from May 2026, with non-compliant apps delisted. A mature marketplace enforces retroactive requirements through removal, not persuasion.
- **Delisting as the anti-circumvention lever (Shopify):** apps that routed billing through Stripe directly to dodge revenue share violated the terms. Several high-revenue apps reversed course under delisting threat. "Pay through us" is a governance rule enforced by removal, not a pricing preference.
- **Post-approval monitoring (Zoom):** approval is not permanent. Ongoing monitoring with removal authority is the mechanism that keeps the admission gate meaningful after day one.

## The openness counter-argument

A U.S. NTIA analysis of the mobile app ecosystem argued heavy gatekeeping produces "prices inflated due to fees collected by gatekeepers, innovation hampered by policy decisions to limit access... and loss of choice" - the standard antitrust argument against curation-as-control. Treat it as the live counterweight when setting the curation position: every notch toward the curated end buys trust and costs supply, fee tolerance, and (at platform scale) regulatory attention.

## Discoverability is a separate governance surface

Admission (who gets listed) and discoverability (who gets seen first) are independent axes - a marketplace can be open on the first and still gate or monetize the second.

- **Paid/featured placement** (homepage, search results, email campaigns) is a second revenue line distinct from take-rate - and it needs its own disclosure rule. Featured placement that reads as an editorial pick erodes exactly the trust curation was meant to build.
- **Review-driven organic ranking** is the counterweight: HubSpot explicitly cites its user review system as the mechanism that "helps ensure listed apps are of high quality and meet user needs."
- **Heavier structures exist above the review gate:** some enterprise marketplaces gate listing itself behind a formal partnership agreement layered on top of technical/security review. Cloud marketplaces add multi-tier reseller/distributor structures with downstream storefronts. Relevant only if the marketplace expects resellers, not just direct app builders.

## Partner concentration and pooled scale

Once complementors scale, a few can gain outsized bargaining power over the platform. The documented countermeasure is the platform actively "pooling scale" for complementors - shared analytics, shared advertising infrastructure - so smaller partners get scale benefits without individually reaching that scale, keeping the complementor base level rather than letting a few dominate. Write this into the governance section as a standing mechanism, not a crisis response.

# Seeding the two-sided network and measuring the flywheel

## The problem, named twice

The academic literature frames marketplace bootstrapping as a chicken-and-egg problem: a marketplace needs both complementors (app/connector builders) and consumers (customers who'll use those apps) to have a valid value proposition, but neither joins while the other side is empty. Reaching "critical mass" is likened to igniting an auto-catalytic reaction - below the threshold nothing sustains itself, above it the network feeds its own growth.

Andrew Chen's _The Cold Start Problem_ (2021) is the practitioner counterpart, with a five-stage arc: cold start, tipping point, escape velocity, hitting the ceiling, the moat. Two of his concepts transfer directly to a connector marketplace:

- **Atomic network** - the smallest self-sustaining unit of the network, not the eventual scale. "Start as small as your product will allow" and prioritize network _density_ over total size. For a connector marketplace, launch success is one tight, mutually-reinforcing cluster of complementors and users in a single use case - not a broad but thin catalog.
- **The hard side** - in any two-sided network, one side is naturally harder to attract, and that side determines whether the network survives. Chen names app-store developers explicitly as a hard-side example: "for app stores, these are the developers that actually create the products." Solve the hard side's problem first - win developers with a compelling reason to build (tooling, docs, revenue potential, audience reach) - and the easy side follows once real apps exist.

A related named tactic, credited to Chris Dixon: "come for the tool, stay for the network" - attract the hard side with a single-player-useful tool, then layer network value once volume exists (Instagram: photo filters first, social feed second).

## Naming the partner-mix axis

No framework was built specifically for app-marketplace partner tiers, but two named, citable ones map onto parts of the long-tail-builder vs. anchor-ISV vs. reseller split named in SKILL.md's operating-model bundle:

- Iansiti and Levien's keystone / dominator / niche-player typology (_The Keystone Advantage_, Harvard Business School Press, 2004) casts the platform owner as the keystone (later "landlord") and small complementors as niche players - academic grounding for the long-tail end, though it names no distinct anchor-ISV category.
- Sangeet Paul Choudary's orchestrator / non-orchestrator split - aggregator, integrator, and infrastructure roles versus niche producer, value-added reseller, and scale-supplier roles (Choudary, 2022) - is the closer conceptual match: niche producer reads as the long-tail builder, value-added reseller as the reseller tier. It comes from a newsletter, not peer-reviewed research, so weight it accordingly.

Neither replaces the platforms' own partner-program tiers, which formalize ISV vs. reseller as a category but split long tail from anchor only informally, through revenue thresholds or quality badges: Salesforce's ISV maturity ladder, Atlassian's Silver/Gold/Platinum tiers, Shopify's "Built for Shopify" badge.

## Four seeding strategies

Ranked in SKILL.md. Detail behind each rung:

1. **Seed with first-party complements.** The platform owner builds a handful of connectors itself before opening to partners, so day-one customers see value with zero external dependency. Near-zero coordination effort, limited scale - it cannot fill a catalog, only prove the category.
2. **Sequential one-side-first / "Trojan horse."** Ship a stand-alone tool that benefits the harder-to-attract side before any demand exists. Sourced case: Eventbrite launched as a ticketing SaaS for organizers alone, seeding supply before ever seeding buyer demand. Moderate effort, the most broadly applicable strategy.
3. **Subsidies / negative pricing.** Formal economic models solve the cold start by literally paying the initial cohort to join - build-fund grants, guaranteed revenue floors, zero take-rate windows. Moderate-to-high cost, fast if funded.
4. **Social mechanisms (hackathons).** Research found hackathons drive adoption through social contagion "over and above the effect of economic subsidies" - a compounding, slower-acting lever layered on top of the others, never a replacement for them.

## Two independent business cases - argue them separately

A connector marketplace has two distinct justifications, and a platform can act on the second even where the first doesn't yet apply at its scale:

1. **Ecosystem/distribution value.** More complements bring more platform value, compounding into the flywheel: the marketplace as a genuine multi-sided business.
2. **Retention/expansion value.** Customers who adopt multiple integrations churn less. One cited threshold: integrating 4+ tools into a workflow is where switching cost meaningfully rises, because customers who invest in learning an ecosystem are reluctant to rebuild that investment elsewhere. G2 buyer research puts integration capability at 86% importance in SaaS purchase decisions - marketplace breadth feeds sales-cycle conversion, not just post-sale retention.

A strategy document that blends the two cases can't be falsified. One that states which case carries the decision names what evidence would kill it.

## Flywheel measurement

No published industry thresholds exist for marketplace health at launch scale. The anchors below are single-platform data points, labeled as such. Baseline your own metrics in the first quarter and measure direction against yourself.

Demand side:

- Share of customers with ≥1 installed app/connector. Mature-platform anchor, not a target: 91% of Salesforce's 150,000+ customers use at least one AppExchange app (mid-2026).
- Installed integrations per account, watching the 4+ cluster (the cited switching-cost threshold) - the retention case made measurable.
- Retention/expansion delta between accounts above and below that cluster: the direct test of business case 2.

Supply side (the hard side - lead with these):

- Active partners with a live listing.
- Time from partner signup to first live listing.
- Share of catalog updated in the last two quarters - a stale catalog is the "expensive partner directory" failure becoming visible.
- Partner revenue concentration (share of GMV in the top few partners) - the trigger for the pooled-scale governance mechanism.

Flywheel coupling:

- Marketplace-attributed influence on new deals (integration capability cited in wins) and on churn saves. Direction matters more than precision. Attribution here is inherently soft - say so in the document rather than inventing a hard number.

# Take-rate benchmarks: four architectures (2026 snapshot)

Every figure below is a dated snapshot of one platform's published terms, not an industry norm. Use the architectures and the ratios they imply. Re-verify any exact figure before quoting it in a strategy document, since marketplace terms change on announcement cycles measured in months.

## Zero take-rate - HubSpot Marketplace (2026 terms)

HubSpot charges no revenue share and no listing or certification fee. Quality gating (its listed/certified two-tier ladder) and monetization are fully separated design choices: the marketplace is funded as a retention and ecosystem asset for the core product, not as a revenue line.

Read: take-rate zero is a real architecture used at scale, not a transitional state a marketplace must grow out of.

## Volume-tiered take-rate - Shopify App Store

- 0% revenue share on a developer's first $1,000,000 USD in annual gross App Store revenue (in effect since January 1, 2025), then 15% above that - down from a flat 20% previously.
- Exception: developers earning $20M+ through the store in the prior year, or with $100M+ total company revenue, pay 15% on all revenue with no free tier, re-assessed annually.
- A flat 2.9% payment-processing fee applies to all billing, charged separately from revenue share.
- Theme developers keep 85% of Theme Store revenue - a materially better split than the post-threshold app tier.

Shopify explicitly markets its 15% ceiling as better than Apple/Google's 30%, positioning take-rate generosity as a developer-acquisition lever for the marketplace itself. The volume tier subsidizes small developers (the hard side of the network) while still monetizing the winners.

Enforcement note: apps that routed billing through Stripe directly to dodge the revenue share violated Shopify's terms. Several high-revenue apps reversed course under delisting threat. Circumvention pressure is proportional to the take-rate - see the failure modes in SKILL.md.

## Flat percentage plus fee stack - Salesforce AppExchange (2026 terms)

- 15% of net revenue for standard ISV partners, 25% for OEM partners.
- One-time $999 security-review fee per paid app, plus a $150 annual listing fee.
- Free apps (about 40% of the marketplace) pay no revenue share.
- A non-percentage flat-annual-fee contract exists for apps that don't fit the percentage model, priced by org/user count.

Scale context (mid-2026): 6,233+ apps listed. 91% of Salesforce's 150,000+ customers use at least one AppExchange app. A marketplace can become the procurement gate most enterprise deals route through - which is what makes a 15-25% take sustainable there and unaffordable for a marketplace still fighting for supply.

2026 strategic move: Salesforce rebranded/expanded the marketplace into "AgentExchange," adding AI agents and experts alongside apps while keeping the partner program and security review unchanged - repositioning an existing marketplace around a new complement type rather than rebuilding.

## Differential take-rate as a migration lever - Atlassian Marketplace

Atlassian ran two opposite revenue-share moves in the same 2026 cycle:

- Legacy Connect app commission scheduled to rise to 20%, then 25% - with the increase later delayed three months (January 1 to April 1, 2026).
- Its modern Forge hosting framework got a temporary 0% commission (100% of revenue to the partner) up to $1M in lifetime Forge revenue, replacing an earlier "5% commission in year one" incentive - and this favorable change was accelerated ahead of schedule.

Both moves ran under Atlassian's stated 6-months'-notice commitment for standard-rate changes. Read: take-rate can differ by hosting/architecture choice, pricing partner migration toward the platform's preferred technical model the way a cloud vendor prices egress. Favorable changes were sped up and unfavorable ones deferred - the notice discipline is part of the lever.

## What the four architectures imply for a new marketplace

- Take-rate is at least three-dimensional: level (0-25%), tier axis (volume, hosting model, partner type), and the fee stack around it (review fees, listing fees, payment processing).
- The mature, high-take platforms earn their rate through distribution the partner cannot replicate (AppExchange as procurement gate). A marketplace without that leverage charging the same rate selects against the supply it needs most.
- Every platform above pairs its rate with an enforcement mechanism (delisting) and, where the rate changed, a notice commitment. A take-rate without both is a number partners will route around or churn over.

---
name: connector-marketplace-strategy
description: Decide whether and when a SaaS should build its own app/connector marketplace, versus joining others' marketplaces or buying embedded iPaaS, and design its operating model - curation level, partner mix, governance rules, take-rate, and seeding sequence. Use whenever the user mentions building an app store or integration marketplace, ecosystem readiness, marketplace revenue share or take-rate, curated vs open admission, third-party app governance, or seeding a two-sided developer ecosystem - even if they never say "marketplace strategy". Strategy layer only. Do NOT use for billing and payout mechanics (samber/developer-platform-skills@app-marketplace-monetization-model) or for being a connector on others' data platforms (samber/developer-platform-skills@etl-connector-strategy).
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.1"
---

# 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](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](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](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](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](references/seeding-and-flywheel.md).

## 7. Flywheel measurement

The strategy document passes only when three gates hold - self-set from the rules above, since no industry pass-standard exists for a strategy artifact; iterate the document until all three pass:

1. Every build trigger condition in step 1 cites concrete evidence from the interview - a build recommendation with an unevidenced trigger fails.
2. All three governance questions have a written, owner-assigned answer, including the removal path.
3. The seeding plan names the hard side, the atomic network, and the chosen rung with its promotion condition.

Post-launch, track three categories of metrics:

- Demand-side: share of customers with ≥1 installed connector, and integrations per account, watching the 4+ switching-cost cluster.
- Supply-side: active partners, time-to-first-listing, catalog freshness, partner revenue concentration.
- Flywheel coupling: marketplace-attributed deal influence.

Lead with the supply side: it is the hard side, and it fails first. Baseline against your own first quarter - the mature-platform anchors in the references are context, not targets. Full metric detail: [references/seeding-and-flywheel.md](references/seeding-and-flywheel.md).

If your harness has persistent memory, record the chosen path (build/join/buy), the trigger evidence, the operating-model bundle, and each menu's chosen rung with its promotion condition - later tactical runs (onboarding, review, monetization) should inherit these decisions instead of re-asking.

## Failure modes

- **Building too early.** No confirmed supply or demand yields an expensive partner directory. The fix is the step 1 gate honestly applied - recommending "not yet, catalog first" is a success, not a failure.
- **Over-curation kills supply.** A review gate sized for a mature platform, applied at cold start, starves the hard side. Match step 4's rung to actual risk (question 6), not aspiration.
- **Circumvention.** Partners route billing around the marketplace when the take-rate exceeds the distribution value. Sourced case: high-revenue apps routing payments through an external processor, reversed only under delisting threat. Fix: enforcement rule plus honest step 5 pricing.
- **Take-rate shock.** Raising rates without notice burns partner trust; the pattern is a six-months-notice commitment, with unfavorable changes deferred and favorable ones accelerated.
- **Undisclosed featured placement.** Selling homepage slots that read as editorial picks spends the trust curation bought. Label paid placement.
- **Partner concentration.** A few complementors gain outsized bargaining power. Pool scale for the rest before it happens (step 3).

## Invocation examples

- "We keep losing enterprise deals over missing integrations - should we build an app marketplace or just list on the big platforms?"
- "Design the operating model for our connector marketplace: how curated should admission be, and what revenue share can we charge at launch?"
- "Our partner directory has 40 integrations and partners are asking for billing - is it time to turn it into a real marketplace, and how do we seed the ecosystem?"

## References

- `samber/developer-platform-skills@partner-app-onboarding` - the partner-developer onboarding path (docs, sandbox tenancy, certification steps) executing the admission this skill decides.
- `samber/developer-platform-skills@app-marketplace-review` - designs the security/quality review process behind step 4's chosen rung.
- `samber/developer-platform-skills@app-marketplace-listing-standards` - listing quality standards and the approval rubric.
- `samber/developer-platform-skills@app-marketplace-launch-marketing` - marketing the marketplace launch once the seeding sequence is set.
- `samber/developer-platform-skills@integration-listing-optimization` - listing-level optimization, the execution layer under the join path.
- `samber/developer-relations-skills@developer-ecosystem-strategy` - the product-to-platform decision above this skill; run it first when whether to become a platform at all is still open.