developer-ecosystem-strategy

{
  "skill_name": "developer-ecosystem-strategy",
  "evals": [
    {
      "id": 1,
      "prompt": "I'm the CEO of Keelstack - we do managed database schema migrations for engineering teams, about 210 paying accounts. Our board keeps asking why we don't have an app marketplace like our bigger competitors, and I already told them we'd have one by Q3. Honestly the requests I can point to are: one customer (Halvorsen Retail) asked for a monitoring hook, the same customer asked for a Terraform provider, and a prospect asked about a Jira sync during a demo we lost on price. Our migration engine talks to the rest of the product through an internal Go package, not an API - the public API we have only covers project CRUD. We have 14 engineers, no security review function, and nobody who'd own a partner queue. What should the marketplace look like?",
      "expected_output": "A gated decision that fails counted demand and identified builders, marks the internal Go package as a blocked interface, deletes the app and runtime rungs for lack of a security review function, recommends a low rung, and returns a written decision with reopen conditions instead of a marketplace design.",
      "files": [],
      "expectations": [
        "Reports counted demand as a fail, noting that three complements from effectively one customer falls short of the five-complements-from-named-customers pass condition.",
        "Reports externalizable interfaces as a fail or unknown, naming the internal Go package as the reason the migration capability is not publishable today.",
        "Reports identified builders as a fail or unknown, because no organization with a reason of its own to build has been named or spoken to.",
        "States explicitly that an unknown gate does not count as a pass, and attaches a resolver and an elapsed time or date to each unknown it reports.",
        "Deletes installable third-party apps and the runtime platform from the options because there is no security review function, rather than listing them as a later phase.",
        "States that a ruled-out rung is deleted rather than parked at the bottom as a 'phase two', because a parked rung reappears as scope.",
        "Recommends vendor-built integrations or a documented public API and webhooks rather than an app marketplace.",
        "Presents two or three candidate rungs rather than a single recommendation.",
        "Produces no marketplace listing design, no app review workflow, no revenue-share scheme and no partner contract terms.",
        "Ranks the evidence for counted demand, placing unsupported glue customers already built above requests that were refused, above feature requests or sales anecdotes.",
        "Returns a written decision carrying reopen conditions and a named owner rather than an open-ended 'revisit later'.",
        "Treats the Q3 commitment already made to the board as a constraint to be restated or renegotiated, not as a date to design toward."
      ]
    },
    {
      "id": 2,
      "prompt": "Northfleet here - incident response tooling, 940 accounts on a paid plan. We shipped a documented public REST API with webhooks about 14 months ago because we wanted an ecosystem. 61 teams have generated API keys. In that time exactly two things have been built on it, both by the same customer's platform team, and neither is shared with anyone else. We've written 9 blog posts about the API, sponsored two hackathons and hired a developer advocate. My VP Marketing thinks we need better docs and a bigger relaunch. I think we should skip ahead and build an app store. Which is it?",
      "expected_output": "A diagnosis pointing at absent counted demand and an absent complementor business case rather than at marketing, identifying the wrong-builder signal, refusing the jump to an app store, and returning a seeding plan.",
      "files": [],
      "expectations": [
        "Diagnoses the cause as absent counted demand or an absent complementor business case rather than as a documentation, marketing or developer-advocacy failure.",
        "States that no amount of developer marketing invents demand that was never counted.",
        "States that publishing a surface buys the possibility of complements, never the complements themselves.",
        "Identifies the wrong-builder signal: the surface was designed for independent software vendors and only a customer's internal team showed up.",
        "States that the fix for a wrong-builder signal is the offer, not the surface.",
        "Rejects moving up to installable apps or an app store as the remedy for an unused lower rung.",
        "Requires a named list of requested complements with customers attached before recommending any further opening.",
        "Runs the complementor arithmetic per builder archetype instead of treating 'developers' as a single audience.",
        "Recommends hand-recruiting a founding cohort chosen to cover the complements customers ask for most, explicitly not chosen for logo value.",
        "Recommends building the first complements in-house to prove the surface and set the pattern, then handing them over or retiring them.",
        "Recommends routing Northfleet's own distribution - in-product placement, onboarding, docs, sales conversations - at complementors.",
        "Defines a minimum credible pool: the count and category coverage below which a customer browsing the ecosystem reads it as abandoned."
      ]
    },
    {
      "id": 3,
      "prompt": "Ordwell - we sell warehouse inventory software to mid-market retailers, 180 accounts, $1.4M ARR. We're about to open up partner-built integrations and our CFO has modelled a 20% recurring revenue share on anything a partner sells through us, plus a $600/year listing fee to keep the directory clean. We have zero partners live today; three agencies have said they're interested and one small ISV. The agencies keep asking what they get out of it. Can you sanity-check the economics and tell me how to pitch it to them?",
      "expected_output": "A value-share position that holds the take-rate at zero until liquidity exists, drops the listing fee, identifies complementors as the subsidized side, and splits the offer by builder archetype - agencies get referral flow and certification, not revenue share.",
      "files": [],
      "expectations": [
        "Recommends holding the take-rate at zero until liquidity is real, stating that a tax on a market that does not exist yet deters the supply Ordwell is trying to recruit.",
        "Recommends against the $600 annual listing fee at this stage, or names it as charging the side that should be subsidized.",
        "Identifies complementors as the price-sensitive side to subsidize, and the buying customer as the side whose demand rises most when the other side grows.",
        "Attributes the subsidize-one-side pricing rule to Rochet and Tirole's two-sided-market work.",
        "Marks the claim that complementors are the price-sensitive side in developer-tool ecosystems as a judgment layered on top of that pricing rule rather than part of it.",
        "States that any eventual fee should be charged for something that grew because of Ordwell - distribution, billing or trust - not for the right to exist on the surface.",
        "Offers agencies referral flow and certification rather than a revenue share, on the grounds that agencies monetize hours.",
        "Gives the independent software vendor a different offer from the agency offer rather than proposing one uniform partner deal.",
        "Tests whether the surplus left with each builder beats that builder's own alternative, including the alternative of not building at all.",
        "States that this value-share position is a design principle asserted here rather than a measured result, and invites the user to argue with it explicitly.",
        "Declines to specify billing mechanics, payout rails or fee collection, naming them as downstream execution."
      ]
    },
    {
      "id": 4,
      "prompt": "Parcelwise, last-mile delivery routing software, 260 accounts. We want third-party apps that customers install from inside our product. The complement everyone asks for is carrier-rate comparison. Here's what I know: about 45 of our accounts overlap with the ideal customer of the two rate-comparison vendors we've talked to; realistically maybe a quarter of those would attach; those vendors charge around $5,000 a year per customer. They've told us it's roughly 12 person-weeks to build against us plus about 4 weeks a year keeping it alive, and they already ship a version on a logistics platform with 9,000 customers. Separately, four of our customers' own ops teams have built rate-comparison spreadsheets glued onto our CSV export. Two agencies we work with say they'd build it if we paid them. Does the app model work?",
      "expected_output": "A filled complementor worksheet per archetype showing the vendor column is not positive against its alternative, the agencies are a logo, and the customers' internal teams are the only positive column - so the case is for in-product extension points, not installable apps.",
      "files": [],
      "expectations": [
        "Computes the independent software vendor's annual return from the figures given, arriving at roughly $55,000 a year, from about 11 attached customers at $5,000 each.",
        "Weighs that return against the vendor's stated alternative - the 9,000-customer logistics platform they already ship on - rather than against zero.",
        "Concludes the independent software vendor column is not clearly positive against its alternative.",
        "Treats the two agencies that would only build if paid as a logo rather than a complementor, because they have no return of their own.",
        "Identifies the four customers' own ops teams as the only clearly positive column.",
        "Applies the rule that when the only positive column is the customer's internal team, the case is for in-product extension points, not for installable third-party apps.",
        "Recommends against the installable third-party app model at this point.",
        "Names the unsupported CSV glue the four ops teams already built as the strongest available class of demand evidence.",
        "Fills a worksheet line per archetype with ranges where a figure is rough, leaving no line blank.",
        "Counts the migrations Parcelwise would force on builders inside the maintenance cost line rather than omitting it.",
        "Applies the mirror test: if both sides can walk away at zero cost this is a handshake, not an ecosystem.",
        "States that any builder return that depends on Parcelwise routing customers to them becomes part of the obligations, not part of the pitch."
      ]
    },
    {
      "id": 5,
      "prompt": "I run product at Vaultmark. We sell a cloud misconfiguration scanner to platform teams - the thing customers actually pay for is our curated rule library, about 1,900 hand-written rules mapped to compliance frameworks, updated weekly. Our head of growth wants to open a community rule marketplace so security engineers write and share rules for free; he thinks it kills our biggest cost centre and gives us a moat through network effects. Six customers are asking for rules we don't cover. How do we structure the contribution model and the review queue?",
      "expected_output": "A refusal: the rule library is the differentiated core, so abundant free rules commoditize Vaultmark rather than its complements. The gate fails in the direction no demand can fix, and the deliverable is a written decline with reopen conditions.",
      "files": [],
      "expectations": [
        "Refuses the community rule marketplace instead of designing its contribution model or review queue.",
        "Identifies the curated rule library as the differentiated thing Vaultmark sells, not as a complement.",
        "States that an abundant free supply of rules would commoditize Vaultmark itself rather than its complements.",
        "Reports the commoditized-complement gate as a fail, and as the failure direction that matters most.",
        "States that no amount of demand would fix this particular gate failure.",
        "Attributes the commoditize-your-complements economics to Joel Spolsky's Strategy Letter V.",
        "Names explicitly which complement would be commoditized, as a required output of the hypothesis step.",
        "Stops the workflow here rather than continuing into rung selection, seeding or flywheel design.",
        "States that a decision not to open is a valid outcome of this analysis, not a non-event.",
        "Produces a written decline carrying reopen conditions, a named owner and a review date.",
        "Rejects the network-effect moat claim, on the grounds that abundance moves value away from the side that is scarce today.",
        "Recommends covering the six uncovered rule requests as a roadmap item rather than as an extension surface."
      ]
    },
    {
      "id": 6,
      "prompt": "Halyard Systems, field-service scheduling for utilities. Our biggest account, Meridian Power at $430k a year, renews on 6 March and their procurement lead has said in writing that renewal depends on us having a working integration with their SAP-based work-order system. Five other accounts are asking for connectors to three different asset-management systems. Our CTO has been clear on two things: we are not signing anything we can't withdraw from later, and we are not staffing a security review function - we're 22 people. I want a plan for opening up that gets Meridian done and sets us up for the rest. Today is 2 January.",
      "expected_output": "A re-ranked ladder where the March deadline promotes vendor-built integrations and the constraints delete every rung above the documented API, with two or three candidates presented in a stated efficiency order and a promotion condition written as an observable event.",
      "files": [],
      "expectations": [
        "Recommends vendor-built integrations as the rung to execute for the Meridian deadline, because it is the only rung whose delivery Halyard controls.",
        "Names the 6 March renewal as the answer that promoted vendor-built integrations up the ranking.",
        "Deletes installable third-party apps and the runtime platform because there is no security review function, and says so explicitly.",
        "Deletes every rung above the documented public API because Halyard will not sign an obligation it cannot withdraw from, and says so explicitly.",
        "Names partner-built integrations as the first rung that cannot be walked back, because another company's revenue would then ride on Halyard's surface.",
        "Presents two or three candidate rungs rather than one.",
        "States the efficiency ordering of the candidates out loud rather than leaving it implied by the order they are listed in.",
        "Expresses effort as standing team, weekly coordination and reversibility, never as a budget or currency figure.",
        "Parks no deleted rung at the bottom of the recommendation as a later phase.",
        "Writes the condition that would promote Halyard to a higher rung as an observable event rather than a roadmap date.",
        "Notes that vendor-built integrations carry zero leverage by definition and that their effort grows with every connector added.",
        "Notes that vendor-built integrations are nonetheless the cheapest instrument for discovering which of the three asset-management connectors customers actually adopt."
      ]
    },
    {
      "id": 7,
      "prompt": "Brightwell - data quality monitoring for analytics teams, 8 engineers total, 120 accounts. Two customers, Corveth Bank and a healthcare group, have asked to write their own validation logic in Python instead of using our rule builder. Our staff engineer has drafted a design for running customer Python inside our infrastructure - gVisor sandboxing, per-tenant CPU quotas, a metering layer. He estimates about a quarter of work. I want a second opinion on the architecture before we commit.",
      "expected_output": "A refusal of the runtime platform on all three promotion conditions, a redirect away from reviewing the sandbox design, a recommendation of the highest staffable rung, and a liability register plus an observable promotion condition.",
      "files": [],
      "expectations": [
        "Declines to review or extend the sandbox architecture and redirects to whether a runtime platform is the right rung at all.",
        "Names all three conditions required to promote a runtime platform: the complements genuinely cannot run outside the execution context, a dedicated platform team is funded indefinitely rather than borrowed, and the team would actually run the shutdown migration it is signing up for.",
        "States that the requested validation logic can run outside Brightwell's execution context - for example as an outbound call to customer-hosted code - so the first condition fails.",
        "States that eight engineers in total is a borrowed team, not a dedicated platform team funded indefinitely.",
        "States that the runtime platform loses on value per unit of effort every time, because it carries the largest permanent obligation on the ladder.",
        "States that shutting down a runtime platform is a migration event for every complementor.",
        "Recommends the highest rung Brightwell can actually staff instead of the runtime platform.",
        "Writes the condition that would promote Brightwell back to a runtime platform as an observable event.",
        "Notes that two requesting customers is below the counted-demand threshold, and names what would resolve it and how long that takes.",
        "States that each in-product extension point permanently freezes an internal seam.",
        "Adds every published surface to a liability register, and states that this register rather than the architecture diagram is what tells Brightwell whether its next refactor is affordable."
      ]
    },
    {
      "id": 8,
      "prompt": "Cindermill, workflow automation for ops teams. We list 11 partner-built integrations. The best one by far is built by a company called Threadmark - it's installed in 40% of our accounts and it's basically their whole business now. Our product team has it on the Q2 roadmap to ship the same capability natively, better integrated, and they want to announce it at our user conference in May. Nobody has told Threadmark. Separately, Threadmark has asked whether they can resell a paid version of their integration to our customers and what support they'd get from us. Two questions in one, sorry.",
      "expected_output": "The native feature named as sherlocking, a published roadmap boundary with notice promised before the line is crossed, notification of Threadmark ahead of the conference, and the full obligation set with owners - not a contract draft.",
      "files": [],
      "expectations": [
        "Names the planned native feature as sherlocking a complementor, and attributes the term to Apple's Sherlock being superseded by Spotlight.",
        "States that absorbing a complement into the core is sometimes correct, but never correct when done unannounced.",
        "Requires the roadmap boundary to be published, with notice promised before the line is crossed, while admitting the line can move rather than pretending otherwise.",
        "Warns that crossing the line unannounced teaches every other complementor that investing in Cindermill is unsafe.",
        "Recommends telling Threadmark before the May user-conference announcement, not at it.",
        "Names the permanent obligations owed at this rung with an owner for each: surface stability and deprecation policy, roadmap boundary, support and escalation, review and safety, and wind-down terms.",
        "States the deprecation policy in terms of how long a published interface lives and how much notice a breaking change gets.",
        "States that a third party's bug arrives as Cindermill's own outage.",
        "States that from partner-built integrations upward, the customer blames Cindermill when a complement fails, whoever wrote the code.",
        "Answers the resale question through the complementor's own arithmetic and the obligations owed, not through pricing or contract mechanics.",
        "Declines to draft the partner contract or reseller agreement, naming it as downstream execution.",
        "Reads one complement installed in 40% of accounts as a concentration signal rather than as ecosystem health."
      ]
    },
    {
      "id": 9,
      "prompt": "Ravensworth - API monitoring, 620 accounts. We launched our partner integration program three quarters ago. Current state: 34 announced partners on the website, 6 of them have a live integration, and the top 2 integrations account for 81% of all ecosystem usage. About 4% of our accounts have any integration active at all. Our VP Partnerships reports 'partners signed' monthly and it's up and to the right. Board meeting in three weeks - what numbers should I be showing, and what's a good attach rate for a program this age?",
      "expected_output": "A refusal to supply a cross-industry attach benchmark, a metric set measured against Ravensworth's own baseline, ecosystem theatre and concentration called out, and kill criteria carrying a threshold and a date.",
      "files": [],
      "expectations": [
        "Refuses to supply an industry attach-rate benchmark, and states the program must be measured against Ravensworth's own baseline rather than a cross-industry figure.",
        "Labels any threshold it does propose as a self-set default that exists so the decision can be argued about, not as an industry benchmark.",
        "Replaces 'partners signed' with active complements per account as the reported number, and names the 34-announced-against-6-live gap as ecosystem theatre.",
        "Reads the 81% top-two share as a concentration signal meaning Ravensworth has two partnerships rather than an ecosystem.",
        "Reports complement supply as net new complements per quarter plus coverage of the counted demand list.",
        "Reports complementor activation as the share of registered builders who ship anything and the time to a first working complement.",
        "Names the retention and expansion delta between accounts with an active complement and accounts with none as the number that funds the program.",
        "Reports cost metrics: engineering hours held hostage by extension-point compatibility, and support tickets caused by third-party code.",
        "Requires every metric to carry a baseline value that exists today, and every target to carry a date.",
        "Writes kill criteria containing at least one failure condition with both a threshold and a date, including a de-escalation to a lower rung.",
        "States that nobody shuts an ecosystem program down voluntarily because withdrawal is embarrassing, which is why the criteria get written while the decision is still cheap."
      ]
    }
  ],
  "trigger_queries": [
    { "query": "Should we turn our product into a platform?", "should_trigger": true },
    { "query": "should we build an app marketplace", "should_trigger": true },
    { "query": "We need an integrations story for the next board deck. Where do we start?", "should_trigger": true },
    { "query": "Our customers keep asking for integrations we don't have time to build.", "should_trigger": true },
    { "query": "We opened our public API a year ago and nobody has built anything on it.", "should_trigger": true },
    { "query": "how do we get other companies to build on top of us", "should_trigger": true },
    { "query": "Should partners build the connectors or should we build them ourselves?", "should_trigger": true },
    { "query": "What do we owe a partner who resells something built on our API?", "should_trigger": true },
    { "query": "We're thinking about opening extension points inside the product. Worth it?", "should_trigger": true },
    { "query": "is it too early for us to allow third party apps", "should_trigger": true },
    { "query": "how much value do we need to leave with the people building on us before we charge anything", "should_trigger": true },
    { "query": "we want a complement ecosystem around our dev tool", "should_trigger": true },
    { "query": "Our roadmap can't keep up with connector requests. What are our options?", "should_trigger": true },
    { "query": "Should we let customers install third-party code into their own tenant?", "should_trigger": true },
    { "query": "A vendor asked to publish an integration with us. Do we say yes?", "should_trigger": true },
    { "query": "what would it permanently commit us to if we published extension points", "should_trigger": true },
    { "query": "how far should we open the product up to outsiders", "should_trigger": true },
    { "query": "we keep getting asked for a plugin system", "should_trigger": true },
    { "query": "Is an integration directory worth building at our size?", "should_trigger": true },
    { "query": "Should we start a partner integration program this year?", "should_trigger": true },
    { "query": "Nobody uses our webhooks. Should we build a marketplace instead?", "should_trigger": true },
    { "query": "Our CEO wants an AppExchange for our product. Is that the right call?", "should_trigger": true },
    { "query": "how do we seed the first integrations so the directory doesn't look dead", "should_trigger": true },
    { "query": "Who should we recruit first to build on us?", "should_trigger": true },
    { "query": "Everyone tells us to be a platform, not a product. Should we?", "should_trigger": true },
    { "query": "We have 400 customers and a documented API. What's the next step in openness?", "should_trigger": true },
    { "query": "Should our SDK become a runtime where customers deploy their own code to us?", "should_trigger": true },
    { "query": "Three customers wrote their own scrapers against our UI. What does that tell us?", "should_trigger": true },
    { "query": "Our competitor launched a marketplace. Do we need one?", "should_trigger": true },
    { "query": "we need to decide between building connectors ourselves or letting outside companies do it", "should_trigger": true },
    { "query": "how do we know if opening up is actually working", "should_trigger": true },
    { "query": "when should we shut down an integrations program", "should_trigger": true },
    { "query": "Our product team wants to ship a feature that duplicates what one of our partners built. What do we do?", "should_trigger": true },
    { "query": "We can't staff a review queue but we want partner-built integrations. Options?", "should_trigger": true },
    { "query": "What stops a bigger vendor from just absorbing the whole category we're trying to build here?", "should_trigger": true },
    { "query": "Should we open the plugin API or keep everything first-party?", "should_trigger": true },
    { "query": "our integrations page has 30 logos and nobody installs anything", "should_trigger": true },
    { "query": "give me a decision memo on whether we should become a platform", "should_trigger": true },
    { "query": "We need outsiders to extend the product without us hiring more engineers.", "should_trigger": true },
    { "query": "What would we be signing up for forever if we did this?", "should_trigger": true },
    { "query": "Our board asked why we don't have an ecosystem. How should I answer?", "should_trigger": true },
    { "query": "we want third parties to fill the gaps in our roadmap", "should_trigger": true },
    { "query": "Is there a cheaper version of a marketplace that still gets us integrations?", "should_trigger": true },
    { "query": "how do i decide between a public api, partner-built integrations, and full installable apps", "should_trigger": true },
    { "query": "Two agencies want to build on us. What should we offer them?", "should_trigger": true },
    { "query": "We're about to publish extension points. Anything we should write down first?", "should_trigger": true },
    { "query": "All our integration requests come from one customer. Is that enough to build on?", "should_trigger": true },
    { "query": "If we let the community extend this, do we still have anything left to sell?", "should_trigger": true },
    { "query": "Should we build our own connector marketplace or just list on other vendors' marketplaces?", "should_trigger": false },
    { "query": "Curated versus open admission for third-party apps - which should our marketplace run?", "should_trigger": false },
    { "query": "Write the listing standards every app in our marketplace has to meet.", "should_trigger": false },
    { "query": "Design the review process for third-party apps submitted to our marketplace.", "should_trigger": false },
    { "query": "Should the marketplace be merchant of record, or should developers bill their own customers?", "should_trigger": false },
    { "query": "What payout cadence and hold window should we use for developer payouts?", "should_trigger": false },
    { "query": "Plan the launch marketing for our new app marketplace.", "should_trigger": false },
    { "query": "Design the onboarding flow for partner developers submitting their first app.", "should_trigger": false },
    { "query": "Which technology partners should we integrate with first, ranked by deal-attached revenue?", "should_trigger": false },
    { "query": "Design the referral-to-OEM depth ladder and graduation gates for our ISV alliances.", "should_trigger": false },
    { "query": "Should we add GraphQL and an MCP layer on top of our REST API, and in what order?", "should_trigger": false },
    { "query": "Which languages should get official SDKs first, and generated or handwritten?", "should_trigger": false },
    { "query": "How should we version our public REST API and handle deprecations?", "should_trigger": false },
    { "query": "Design idempotency keys and retry semantics for our write endpoints.", "should_trigger": false },
    { "query": "What rate limits should we set per API key tier?", "should_trigger": false },
    { "query": "Design our webhook delivery platform with retries and payload signing.", "should_trigger": false },
    { "query": "Review our public GraphQL schema before we publish it.", "should_trigger": false },
    { "query": "Build an OAuth2 provider so third parties can request scopes against our accounts.", "should_trigger": false },
    { "query": "Which ETL connectors should we build first and how do we maintain them?", "should_trigger": false },
    { "query": "Optimize our listing on a partner's integration directory so it converts better.", "should_trigger": false },
    { "query": "Design our developer portal's information architecture.", "should_trigger": false },
    { "query": "Should we ship an MCP server for our product?", "should_trigger": false },
    { "query": "How do we instrument and alert on customer integrations that are failing silently?", "should_trigger": false },
    { "query": "Design a sandboxed test mode so developers can call our API without touching production data.", "should_trigger": false },
    { "query": "How should we price our developer tool's paid tiers?", "should_trigger": false },
    { "query": "Should we go open core or hosted open source?", "should_trigger": false },
    { "query": "What should we open source and what stays proprietary?", "should_trigger": false },
    { "query": "Design our bottom-up self-serve go-to-market motion.", "should_trigger": false },
    { "query": "Cut our developer audience into named, sized segments.", "should_trigger": false },
    { "query": "Map the developer journey from discovery through to advocacy.", "should_trigger": false },
    { "query": "Should we join the standards body for this protocol or publish our own spec?", "should_trigger": false },
    { "query": "Which open-source projects should our company sponsor, and with what budget?", "should_trigger": false },
    { "query": "Plan the distribution mix for our open-source project after the launch window.", "should_trigger": false },
    { "query": "Which conferences should we sponsor next year and at which tier?", "should_trigger": false },
    { "query": "Design the perks ladder for our developer champions program.", "should_trigger": false },
    { "query": "Should we start a Discord for our users?", "should_trigger": false },
    { "query": "How do we measure our developer community's health?", "should_trigger": false },
    { "query": "Write our code of conduct and the moderation playbook behind it.", "should_trigger": false },
    { "query": "Build a devrel measurement framework with attribution rules per metric.", "should_trigger": false },
    { "query": "Split our devrel budget across events, content and community.", "should_trigger": false },
    { "query": "Who should DevRel report to - marketing or product?", "should_trigger": false },
    { "query": "Benchmark our competitor's developer relations motion.", "should_trigger": false },
    { "query": "Audit our documentation structure against Diátaxis.", "should_trigger": false },
    { "query": "Write a quickstart that gets a developer to first success in under ten minutes.", "should_trigger": false },
    { "query": "Turn this customer's production deployment into a technical case study.", "should_trigger": false },
    { "query": "Choose a license and contribution policy for our new open-source project.", "should_trigger": false },
    { "query": "Rewrite our README so the first command runs inside a minute.", "should_trigger": false },
    { "query": "Design a certification program and learning path for our product.", "should_trigger": false }
  ]
}

# Worked ecosystem memos

Two illustrative memos for fictional products. Every number here is invented for the example and none of it is a benchmark - the shape of the argument is what to copy.

Case A ends in yes. Each of its sections shows the **weak** version teams actually write - the negative example - followed by the **strong** version. Read the weak lines as the failure to avoid, not as an acceptable first draft.

Case B ends in no, because most honest runs of this skill do, and a decision to stay a product is a deliverable rather than a non-event.

## Contents

- Case A - an ecosystem approved
  - Hypothesis
  - Evidence
  - Gates
  - Rung
  - Complementor case
  - Flywheel
  - Obligations
  - Measurement
  - Kill criteria
- Case B - an ecosystem declined

# Case A - an ecosystem approved

A hosted feature-flag and experimentation service selling to engineering organizations.

## Hypothesis

**Weak** - "Becoming a platform will make us the system of record for experimentation and drive stickiness across the developer ecosystem."

**Strong** - "Because our customers need **experiment result sinks into their own warehouses and BI tools** that we will not build, **data-tooling vendors and their implementation partners** will build them on **our event export and webhook surfaces**, earning **implementation revenue and pull-through of their own product**, which makes our product more valuable to **the analytics-owning buyer** by **removing the last reason experiments get analysed outside our tool**."

Commoditized complement: warehouse delivery. It is the piece every buyer needs, nobody wants to own, and we do not want to maintain across a dozen destinations.

## Evidence

**Weak** - "Integrations are one of the top themes in customer feedback."

**Strong** - Seven named complements requested in two quarters, with customers attached: warehouse export (4 customers, 2 of them blocking renewals), a BI template pack (3), a mobile SDK for a framework we do not support (2), and four single-customer requests. Three customers already run unsupported export scripts against our API; one shared theirs publicly.

## Gates

**Weak** - "We have an API, so we are ready."

**Strong**

- G1 counted demand: **pass**.
- G2 externalizable interfaces: **pass** for export, **fail** for evaluation hooks (still an internal library call).
- G3 identified builders: **pass**, three vendors contacted, two interested.
- G4 commoditized complement: **pass**.
- G5 staffing: **unknown** - resolver: platform team headcount decision at the next planning round, 6 weeks.
- G6 envelopment: **fail-with-cap** - the observability vendor most customers already run could bundle flag delivery; we cap investment at rung 3 until we see them move.
- G7 complement readiness: **pass**.

## Rung

**Weak** - "We will launch an app marketplace in Q3."

**Strong** - Chosen: **rung 3, partner-built integrations that we list**.

Rejected:

- Rung 4: evaluation hooks fail G2, so the surface does not exist yet.
- Rung 5: G5 unknown and G6 capped; an app model would oblige us to run security review with no team.
- Rung 6: no complement needs our execution context.

Reopen rung 5 when the platform team exists and five listed integrations are live.

## Complementor case

**Weak** - "Partners will benefit from access to our customer base."

**Strong**

- Data-tooling vendor: ~40 of our 300 accounts overlap their ICP, expected attach 25%, ~$8k ARR pull-through each, ~6 person-weeks to build, ~2 weeks a year to maintain - clearly positive against their alternative of a generic webhook recipe.
- Agency: monetizes 3-5 implementation days per deployment, needs referral flow, not revenue share.
- Internal teams: no business case needed, and they will build the first three exports if we document the surface.
- Value share: no take-rate at this rung; the offer is referral flow, a listed slot and a named contact.

## Flywheel

**Weak** - "More integrations attract more customers, which attracts more integrations."

**Strong**

- Loop: listed exports remove the analytics objection → analytics-owning buyers sign → account overlap grows → the next vendor's arithmetic improves.
- Subsidized side: complementors (free sandbox tenancy, free listing, engineering support during the first build).
- Founding cohort: two warehouse vendors and one BI vendor, hand-recruited to cover the top demand line. We build the first export ourselves as the reference implementation, then hand the pattern over.
- Minimum credible pool: five live integrations covering warehouse, BI and alerting before we promote the directory publicly.
- Honest read: for the first two quarters we are pushing this wheel, not riding it.

## Obligations

**Weak** - "We will support our partners."

**Strong**

- Export surface stability: 12 months minimum, 90 days' notice on breaking changes. Owner: platform lead.
- Roadmap boundary: we will not build warehouse connectors ourselves; if that changes, 90 days' notice to listed partners before announcement. Owner: head of product.
- Partner escalation path with a 1-business-day acknowledgement. Owner: support lead.
- Listing review pass before any integration is published. Owner: platform lead.
- Wind-down: 6 months' notice, documented export of configuration. Owner: head of product.
- Liability register: two published surfaces at launch, reviewed each planning round.

## Measurement

**Weak** - "Track integrations and partner satisfaction."

**Strong**

Baseline today:

- 0 partner-built integrations.
- 0% of accounts with an active complement.
- 4 unsupported customer scripts known.

Targets:

- 5 live integrations by end of Q3.
- 20% of accounts with at least one active complement by end of Q4.
- Time from partner signup to first working integration under 3 weeks.
- Top-five concentration reported each quarter with no target (a diagnostic, not a goal).
- Retention delta between accounts with and without an active complement, reported from Q4 once the sample is large enough to mean anything.

## Kill criteria

**Weak** - "We will review the program annually."

**Strong**

- Stop recruiting if fewer than three integrations are live by 31 December.
- De-escalate to rung 2 (we build the connectors ourselves) if, by 31 March, fewer than 10% of accounts have an active complement or the two founding vendors have not shipped an update in six months.
- Wind down with the 6-month notice above if the observability vendor bundles flag delivery and our overlap accounts start churning.

Any of these triggers a written re-decision, not a quiet continuation.

# Case B - an ecosystem declined

A CI runtime-security scanner selling to platform-engineering teams. The exec team asked for an app marketplace. The memo says no, and says it in a form the next person can reopen.

**Hypothesis** - Could not be completed. The complement blank filled as "policy packs", the builder blank as "the security community", the return blank as "reputation". Two of three blanks are vague, so the hypothesis was sent back once and still could not name a builder with a reason of their own.

**Evidence** - Three complements requested in two quarters, all three by the same customer, none tied to a stalled deal. No customer has built unsupported glue against the API. The most-requested item - a policy pack for one compliance regime - was requested by four customers and is a content problem, not an extension-surface problem.

**Gates**

- G1 counted demand: **fail** (three complements, one customer).
- G3 identified builders: **fail** (no organization contacted has a revenue reason).
- G4 commoditized complement: **fail**, and in the worst direction - policy packs _are_ the differentiated part of what we sell, so an abundant free supply of them commoditizes us, not our complements.

G2, G5, G6, G7 not evaluated; G1, G3 and G4 already decide it.

**Decision** - No ecosystem. Stay at rung 2: we write the policy packs ourselves and ship the top-requested regime as a roadmap item. The marketplace question is closed for two quarters, not forever.

**Reopen conditions** - Re-run this skill when any one of these holds:

- Eight or more distinct complements requested by five or more customers.
- A named security vendor asks in writing to publish against us.
- A competitor ships a pack ecosystem and we start losing deals to breadth of coverage.

Owner: head of product. Review date: 31 March.

**Why this is a real deliverable** - The failing gates are written down with the evidence that failed them, so the next exec who asks for a marketplace gets a dated answer instead of a fresh six-week study. Recording G4's failure matters most: it is the one failure that no amount of demand would fix.

# Ecosystem readiness gates and complementor economics

Two instruments. The gates decide whether to open anything at all; the worksheet decides whether anyone will build once you do. Report every gate as pass, fail or unknown - an unknown carries a resolver and a date, and never counts as a pass.

**Where the numbers come from.** Every count and cut-off on this page is a default this skill sets so the gate can be argued about, not an industry benchmark. Replace any of them with your own historical data when you have it, and record that you did.

The gates take their concepts from named work:

- Yegge on externalizable interfaces (G2).
- Spolsky on commoditizing complements (G4).
- Eisenmann/Parker/Van Alstyne on envelopment (G6).
- Adner on complement readiness (G7).

## Contents

- The seven gates
- Complementor economics worksheet
- Scoring the worksheet
- Value-share principle

## The seven gates

### G1 - Counted demand

**Pass**: at least five specific complements requested by named customers in the last two quarters, with at least two requested by more than one customer.

**Evidence, best first**:

1. Unsupported glue customers already built.
2. Requests you refused.
3. Deals slowed or lost for a missing complement.
4. Feature requests.
5. Sales anecdotes.

**Fail means**: no market for complements exists yet. Stay at rung 1–2 and re-run in two quarters.

### G2 - Externalizable interfaces

**Pass**: the capability complementors need is already reachable through an interface you would be willing to publish unchanged, and your own features use it.
**Fail means**: the platform work is an architecture project, not a partnership project. Cost it as such before promising dates.

### G3 - Identified builders

**Pass**: you can name at least three real organizations or teams - not personas - with a reason of their own to build, and you have spoken to two of them.
**Fail means**: supply is hypothetical. Test it with interviews before designing surfaces.

### G4 - Commoditized complement, not commoditized core

**Pass**: abundance of the complement raises demand for what you sell.
**Fail means**: the ecosystem would turn your product into the cheap layer. Refuse it explicitly and record the reasoning.

### G5 - Staffing

**Pass**: the standing obligations of the chosen rung have named owners and committed capacity for the next four quarters - not a launch project team.
**Fail means**: pick the rung below.

### G6 - Envelopment exposure

**Pass**: you can name the larger platform most able to bundle your category and state what makes your ecosystem non-generic to it - proprietary data, workflow ownership, a regulated surface, an install base it cannot reach.
**Fail means**: the complements you attract may be building for your successor. Not automatically disqualifying; it caps how much you should invest.

### G7 - Complement readiness

**Pass**: every external dependency the bet needs - standards, adjacent vendors' APIs, customer-side prerequisites - either exists today or has a dated, credible arrival.
**Fail means**: the launch date is a guess. Sequence around the slowest dependency.

## Complementor economics worksheet

Fill one column per builder archetype you are counting on. Numbers may be rough; ranges are fine, blanks are not.

| Line                                                         | Independent software vendor | Agency / integrator | Customer's internal team |
| ------------------------------------------------------------ | --------------------------- | ------------------- | ------------------------ |
| Reachable customers wanting this complement                  |                             |                     |                          |
| Expected attach rate                                         |                             |                     |                          |
| Their revenue per customer (licence, hours, or avoided cost) |                             |                     |                          |
| Annual return to them                                        |                             |                     |                          |
| Build cost (person-weeks)                                    |                             |                     |                          |
| Annual maintenance cost, including migrations you force      |                             |                     |                          |
| Their best alternative                                       |                             |                     |                          |
| Net return versus alternative                                |                             |                     |                          |
| What they need from you that you are not offering yet        |                             |                     |                          |

## Scoring the worksheet

- At least one archetype must show a clearly positive net return against its alternative. If none does, the ecosystem has no supply and no messaging fixes that.
- If the only positive column is the customer's internal team, you have an extension-point case (rung 4), not an app-ecosystem case (rung 5).
- If the positive return depends on you sending customers to them, that traffic is part of the offer - write it into the obligations, not into the pitch.
- Recompute after any change to the take-rate, the migration schedule or the category crowding rules; all three move the result.

## Value-share principle

Set this before any rate exists. These four are principles this skill asserts, not measured results - argue with them explicitly rather than treating them as settled:

1. The surplus left with the complementor must make building on you the rational choice against their alternative.
2. Keep the take-rate at zero until liquidity is real - a tax on a market that does not exist yet only deters the supply you are trying to recruit.
3. Crowding a category is a value transfer from complementors to you; do it deliberately, and say so.
4. When you eventually charge, charge for something that grew because of you - distribution, billing, trust - not for the right to exist on your surface.

Rates, billing mechanics and listing economics are downstream execution, not part of this decision.

# Extension surface ladder

Six rungs of openness, listed here in inheritance order - which is not the order they are recommended in. `SKILL.md` step 3 ranks them by value per unit of effort and that is the ordering to recommend from; this file carries the per-rung detail behind it. Walk all six and mark each _justified by the evidence_, _premature_, or _unstaffable_ before recommending one.

The ladder itself is this skill's own construction, and the time windows in "Signals you are on the wrong rung" are defaults, not measured norms.

## Contents

- Rung 1 - Documented public API and webhooks
- Rung 2 - Vendor-built integrations
- Rung 3 - Partner-built integrations, listed by you
- Rung 4 - In-product extension points
- Rung 5 - Installable third-party apps
- Rung 6 - Runtime platform
- Signals you are on the wrong rung

## Rung 1 - Documented public API and webhooks

- **Who builds**: your customers' own engineers, and integrators writing point-to-point glue.
- **You operate**: reference docs, versioning and deprecation policy, rate limits, keys, request logs.
- **Reversibility**: high. Interfaces can still be versioned out with notice.
- **Use it when**: demand is real but scattered, and no single complement is requested repeatedly.

## Rung 2 - Vendor-built integrations

- **Who builds**: you.
- **You operate**: the connectors themselves, forever, against other vendors' API changes.
- **Reversibility**: high - it is a roadmap line item.
- **Use it when**: demand is concentrated in a handful of named systems, or when you need evidence before opening anything. This is the cheapest instrument for discovering which complements customers actually adopt, and skipping it is the most common way teams over-commit.

## Rung 3 - Partner-built integrations, listed by you

- **Who builds**: agencies, integrators, and vendors of adjacent products.
- **You operate**: listing standards, a review pass, a partner support escalation path, and co-marketing expectations you will be held to.
- **Reversibility**: this is where it ends. Another company's revenue now depends on your surface.
- **Use it when**: the demand list is longer than your roadmap and outside parties already have a reason of their own to build.

## Rung 4 - In-product extension points

- **Who builds**: customers' internal teams first, then partners.
- **You operate**: a stable contract per extension point, a safety boundary, and the discipline to keep shipping without breaking them.
- **Reversibility**: low. Each point freezes an internal seam permanently.
- **Use it when**: customers need behaviour changed inside your product, not data moved between products - custom fields, hooks, event handlers, embedded UI slots, rules, templates.

## Rung 5 - Installable third-party apps

- **Who builds**: independent software vendors with their own product roadmaps.
- **You operate**: consent and scopes, security review, revocation, tenant isolation, incident handling for someone else's bug, and a developer support function.
- **Reversibility**: none in practice. Removing an app model breaks customers who depend on apps you did not write.
- **Use it when**: the complements customers want are products in their own right, big enough to fund a vendor's roadmap.

## Rung 6 - Runtime platform

- **Who builds**: vendors and customers deploying code you execute.
- **You operate**: multi-tenant isolation, resource governance, metering, a developer toolchain, and an SLA - effectively a second product.
- **Reversibility**: none. Shutting it down is a migration event for every complementor.
- **Use it when**: complements cannot work outside your execution context, and you can fund a dedicated platform team indefinitely.

One property does not appear in the ranking and belongs here: who the customer blames when a complement fails. At rungs 1 and 2 they blame themselves or the partner; from rung 3 up they blame you, whoever wrote the code.

## Signals you are on the wrong rung

- **Too high**:
  - Extension points with no complements after two quarters.
  - A review queue with nothing in it.
  - Complementors who built once and never updated.
- **Too low**:
  - The same integration requested by many customers while your roadmap keeps deferring it.
  - Customers shipping unsupported wrappers and scrapers.
  - Partners asking for permission to list something they already built.
- **Wrong builder**: you designed for independent software vendors and only internal teams show up, or the reverse. Fix the offer, not the surface.

---
name: developer-ecosystem-strategy
description: Decides whether, when and how far a developer product should open into a platform other companies build on - extension points, partner-built integrations, third-party apps, a complement ecosystem - and what that permanently obliges you to. Use whenever someone asks if the product should become a platform, whether to open extension points or an app model to third parties, how to start an integration ecosystem, why nobody builds on the API, whether partners should build the connectors, or how much value complementors must keep  -  even if they only say "we want an integrations story". Not marketplace operations or API design. Do NOT use for the revenue model  -  use samber/developer-relations-skills@devtools-business-model.
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.1"
---

# Developer Ecosystem Strategy

You are a platform strategist for developer-facing products. Working with the founder or exec, you decide:

- Whether outsiders should build on this product.
- How far the door opens.
- What the company permanently owes them once it does.

Then you name the evidence that would prove the bet wrong.

The seductive half of a platform is the leverage: other people extend your product for free. The costly half is the trade it demands:

- Every surface you publish freezes an internal seam.
- Every complementor who earns money from you acquires a claim on your roadmap.
- None of it can be quietly withdrawn.

**Deliver:**

- A commitment decision with its obligations.
- A seeding plan.
- Kill criteria.

**Don't deliver:**

- An API spec.
- A marketplace design.
- A partner contract. These are downstream execution.

## Typical invocations

- "Should we build an app marketplace?" → run the full workflow; expect step 2 to reject or defer it more often than not.
- "We opened our API a year ago and nobody built anything. What went wrong?" → steps 2 and 4 diagnose it; the answer is usually no counted demand or no complementor business case.
- "Customers keep asking for integrations we don't have time to build." → steps 3 and 5; the answer is often a lower rung than a platform.
- "A partner wants to resell an extension built on us. What do we owe them?" → steps 4 and 6 alone.

## Interview

Ask one question at a time, multiple-choice where you can. Confirm the rest as you go, but stop early once you can name:

- The product.
- The complement customers are missing.
- Who would build it.

**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. 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.**
1. What is the product, and who uses it day to day?
2. Which complements do customers ask for that you do not build - name the last five requests and the customers behind them.
3. Is anyone already building against you unofficially: scripts, scrapers, internal glue, unsupported wrappers?
4. What exists today: a public API, webhooks, vendor-built integrations, any extension point?
5. Who would the builders be - your own customers' internal teams, agencies and integrators, or independent software vendors with their own products?
6. What do you sell, and what would become more valuable if complements were abundant and free?
7. Which larger platform could bundle your category and absorb the same complements?
8. What engineering and review capacity can stand behind this every quarter, indefinitely?
9. What is off the table - no security review function, no partner contracts, an architecture that cannot expose stable interfaces, a promise already made publicly?
10. What would count as success in twelve months, in a number someone already tracks?
11. By when must the first result land, and what forces that date - a renewal, a partner deal, a board review?
12. Do you want a one-off win on the complements customers are asking for now, or a compounding asset outsiders keep adding to?
13. What is the effort ceiling - hours per week you can commit indefinitely, whether you can carry a standing team, and whether you can sign an obligation you cannot withdraw?

Answers 11 to 13 re-rank the rungs in step 3. Say which answer moved which rung:

- A near date promotes vendor-built integrations, the only rung whose delivery you control.
- A compounding mandate promotes partner-built integrations.
- No standing team deletes installable apps and the runtime platform.
- An unwillingness to sign an unwithdrawable obligation deletes every rung above the documented API.

Record the answers. If your harness has persistent memory, store:

- The complement demand list.
- The chosen rung.
- The obligations accepted.
- The refused options.

Every downstream integration, marketplace and partner decision reuses them.

## Step 1 - State the ecosystem hypothesis in one sentence

Force the claim into this shape and check that every blank is filled with something specific:

> _Because our customers need **[complement]** that we will not build, **[builder type]** will build it on **[surface]**, earning **[their return]**, which makes our product more valuable to **[buyer]** by **[mechanism]**._

A hypothesis is not yet a strategy when any blank stays vague:

- A vague builder ("developers").
- A vague return ("exposure").
- A vague mechanism ("stickiness").

Send it back before continuing.

Name the complement you are deliberately commoditizing. Joel Spolsky's Strategy Letter V (2002) puts the economics plainly: "Demand for a product increases when the prices of its complements decrease," so "smart companies try to commoditize their products' complements." An ecosystem drives the price of your complements toward zero.

If the abundance it creates would commoditize _you_ instead, stop here - the answer is no, and that is a valid outcome of this skill.

## Step 2 - Gate on demand and readiness before designing anything

Run the gates in [references/ecosystem-readiness-gates.md](./references/ecosystem-readiness-gates.md) and report each one as pass, fail or unknown. The gates cover:

- Counted demand.
- Architectural readiness.
- Complementor supply.
- Staffing.
- The envelopment threat.

An unknown is not a pass: say what would resolve it and how long that takes.

Two gates decide most cases:

- **Counted demand.** A named list of requested complements with the customers attached. Requests you refused are the best evidence; unsupported glue customers already built is better still. Nothing here means the ecosystem has no market, and no amount of developer marketing invents one.
- **Externalizable interfaces.** Steve Yegge's 2011 account of Amazon's internal mandate - second-hand by nature, but the standard citation - states the requirement: "All service interfaces, without exception, must be designed from the ground up to be externalizable." His retrofit figure, roughly an order of magnitude over building it in up front, is an estimate rather than a measurement, but the direction is uncontested. Dogfood the surfaces you publish: a privileged internal path guarantees the public one stays second-class.

## Step 3 - Brainstorm the rung, do not jump to "platform"

Enter brainstorming mode explicitly and say so. Openness is a ladder, not a switch, and the six rungs are this skill's own taxonomy, but what they order is real: each rung admits different builders, costs a different standing team, and is harder to reverse than the one below. Rank only the rungs that survived step 2; a rung whose gate failed is not a cheaper option, it is unavailable.

Two axes drive the ranking:

- **Effort** - the standing team the rung requires, the review and partner coordination it adds every week, and how hard it is to withdraw. Never a budget figure.
- **Value** - complement supply you do not build yourself, the leverage the whole bet is for.

- efficiency: `partner-built integrations > documented API > vendor-built integrations > extension points > installable apps > runtime platform`
- value: `runtime platform > installable apps > extension points > partner-built integrations > documented API > vendor-built integrations`
- effort: `runtime platform > installable apps > extension points > partner-built integrations > vendor-built integrations > documented API`
- compliance cost: `runtime platform > installable apps > extension points > partner-built integrations > documented API == vendor-built integrations`

1. **Partner-built integrations, listed by you** - outsiders' engineering for the price of a review queue, listing standards and an escalation path. Best ratio on the ladder, and the first rung you cannot walk back: another company's revenue now rides on your surface, so withdrawal is public breakage rather than an edit.
2. **Documented public API and webhooks** - a week of docs, versioning, and rate limits, then a small ongoing cost, reversible with notice. Admits your customers' own internal teams, the cheapest complementor supply there is. Below partner-built only because publishing a surface buys the possibility of complements, never the complements themselves.
3. **Vendor-built integrations** - you build every connector and maintain it forever against other vendors' API changes. Zero on the leverage axis by definition, and its effort grows with each connector, but it is the cheapest instrument for discovering which complements customers actually adopt and it stays a roadmap line item you can drop.
4. **In-product extension points** - a stable contract per point plus a safety boundary, and each point freezes an internal seam permanently. Buys the one thing no integration can: behaviour changed inside your product rather than data moved between products.
5. **Installable third-party apps** - a standing team for consent and scopes, security review, revocation, tenant isolation, incident handling for someone else's bug, and developer support. Buys complements that are products in their own right, funded by their vendor's roadmap. Not reversible: removing the app model breaks customers who depend on apps you did not write.
6. **Runtime platform** - multi-tenant isolation, resource governance, metering, a toolchain and an SLA; effectively a second product with its own permanent team. Buys the deepest complementor value on the ladder, because complements can exist that work nowhere else. Shutting it down is a migration event for every complementor.

The compliance axis separates the rungs by what you owe people outside the company.

- Rungs 4 to 6 run third-party code or configuration inside your boundary, so each triggers a security review, a consent and revocation model, and a data-handling review that is far easier to add than to remove.
- Rung 3 triggers partner contracts and listing terms instead.
- Rungs 1 and 2 tie: neither publishes anything a third party's own customers rely on, so the only terms in play are your own, and no outside party has to approve them.

**What this order starves: the runtime platform.** It creates the most complementor value on the ladder and carries the largest permanent obligation, so it loses on efficiency every single time.

Promote it anyway only when all three hold:

- The complements customers ask for genuinely cannot run outside your execution context.
- A dedicated platform team is funded indefinitely rather than borrowed.
- You would actually be willing to run the shutdown migration you are signing up for.

Missing any one of the three, recommend the highest rung you can staff and write the promotion condition as an observable event.

Delete the rungs the answers rule out instead of listing them below the recommendation, and say which you deleted:

- No security review function deletes installable apps and the runtime platform.
- An architecture that cannot expose stable interfaces deletes everything above vendor-built integrations.

A rung parked at the bottom as "phase two" reappears as scope.

This ordering is a default, not a law - it shifts with context and with who executes it. Re-rank it against what you already know:

- Unofficial builders already shipping wrappers against you have pre-paid the demand and the supply for partner-built integrations.
- A company that already runs a security review function for another product has pre-paid most of rung 5's standing cost.
- Answers 11 to 13 move it again.

Walk every rung in [references/extension-surface-ladder.md](./references/extension-surface-ladder.md) and mark it _justified by the evidence_, _premature_, or _unstaffable_. Then present **two or three candidate rungs**, never one, in efficiency order. For each, cover:

- Who builds.
- What they get.
- What you must operate.
- What it forecloses.
- The earliest signal that it is working.

Close with your recommendation and the reason, and let the user choose before you detail anything further.

## Step 4 - Test the complementor's economics and the value share

A complement gets built when an outsider's arithmetic works, not when your strategy deck says it should. Fill the worksheet in [references/ecosystem-readiness-gates.md](./references/ecosystem-readiness-gates.md) for each builder archetype you are counting on. Four inputs decide it:

- **Reachable demand** - how many of _your_ customers plausibly want this complement, not how many customers you have.
- **Their return** - license revenue, implementation hours, deal flow, or an internal cost they avoid.
- **Build and maintain cost**, including every migration you will force on them.
- **Their alternative** - building the same thing on a bigger platform, or not building at all.

The value share falls straight out of that arithmetic. The builder builds only if the surplus left on their side beats their alternative, and a take-rate imposed before liquidity exists eats exactly that surplus - so keep the take-rate at zero until there is a market worth taxing.

That last step is this skill's own design rule, reasoned from the arithmetic rather than measured; argue with it explicitly instead of treating it as settled. Rates, billing and listing mechanics are downstream, not here.

The same worksheet prices out differently per archetype, so the offer differs too:

- Independent software vendors need a market big enough to fund a product line, and predictability more than generosity.
- Agencies and integrators monetize hours, so offer referral flow and certification, not revenue share.
- Your customers' internal teams need no business case at all, only low friction, and they are the cheapest first supply.

Then qualify each prospective builder with one question: _if we do not do this, what changes for you?_

- "We lose a certification we need" is a reason to build.
- "Nothing really changes" means you have a logo, not a complementor.

Apply the mirror test to yourself: if both sides can walk away at zero cost, this is a handshake, not an ecosystem. Both tests are practitioner heuristics.

## Step 5 - Design the flywheel and the first turn

Write the loop as cause and effect, then say honestly whether it turns on its own or whether you are pushing it every quarter - a partnerships program is a legitimate answer, just a different one.

Seeding is not optional generosity. Gawer and Cusumano put it at the center of the platform aspirant's business challenge: either make key complements yourself, or give third-party companies incentives to create them (_MIT Sloan Management Review_, January 2008).

Doing neither is why a published surface stays empty. The plan below does both:

- **Pick the subsidized side.** Subsidize the more price-sensitive side; charge the side whose demand rises most when the other side grows - Rochet and Tirole's two-sided-market pricing rule (_Journal of the European Economic Association_, 2003). That the price-sensitive side is nearly always the complementor in devtool ecosystems - free tooling, free sandbox tenancy, free listing - is this skill's judgment on top of that rule, not part of it.
- **Recruit a founding cohort by hand**, chosen to cover the complements customers ask for most - not for logo value.
- **Build the first complements yourself** to prove the surface and set the pattern, then hand them over or retire them.
- **Route your own distribution at them** - in-product placement, onboarding, docs, sales conversations. Complementors leave when the platform stops pointing at them.
- **Define the minimum credible pool**: the count and category coverage below which a customer browsing the ecosystem reads it as abandoned.

Close the step by listing what the bet depends on that you do not control, and date each item. Complement readiness is a real risk, not a detail: Ron Adner's _Harvard Business Review_ article on innovation ecosystems (April 2006) opens on high-definition television stalling for years because complementary pieces - production equipment, compression standards, broadcast infrastructure - were not ready.

## Step 6 - Price the obligations you are signing

The rung you chose creates permanent duties. Name them, with an owner, before committing:

- **Surface stability and deprecation policy** - how long a published interface lives and how much notice a breaking change gets.
- **Roadmap boundary** - where your own building stops. Absorbing a complement into the core is sometimes right, but doing it unannounced teaches everyone else that investing in you is unsafe. Publish the line, promise notice before crossing it, and admit the line can move rather than pretending otherwise.
- **Support and escalation** - a third party's bug arrives as your outage.
- **Review and safety** - security review, scopes and consent, revocation, at the rungs that need them.
- **Wind-down terms** - notice period, migration path, data export, written now while it is cheap.

Add each published extension point to a liability register. That register, not the architecture diagram, is what tells you whether the next refactor is affordable.

## Step 7 - Write the memo, validated section by section

Produce a decision the team can execute without you:

```markdown
# Ecosystem strategy - <product>

## Hypothesis the one-sentence claim from step 1

## Evidence counted demand, with customers named

## Gates each gate: pass / fail / unknown, with the resolver for unknowns

## Rung the chosen rung, the rungs rejected, and why

## Complementor case the arithmetic per builder archetype, and the value-share principle

## Flywheel the loop, the subsidized side, the founding cohort, the minimum pool

## Obligations what we permanently owe outsiders, with owners

## Measurement the metrics, the baseline today, the target and its date

## Kill criteria what makes us stop, de-escalate or wind down, with dates
```

Present each section and get agreement before writing the next. A wrong call on the builder archetype invalidates everything below it, and that is far cheaper to catch at the fifth heading than at the ninth.

Two worked memos are in [references/ecosystem-memo-example.md](./references/ecosystem-memo-example.md): one that approves an ecosystem, with the weak version of each section shown next to the strong one, and one that declines it. Write the decline memo when the gates fail - a documented "no" with reopen conditions is the deliverable, and skipping it is why the same marketplace question comes back every two quarters.

## Organizations versus individual developers

Before the memo is final, check every section against the two audiences an ecosystem always has - they respond to different things.

- **Organizations** - the buyers of your product and the employers of most complementors. They need risk removed:
  - A stability guarantee.
  - A security review they can show an auditor.
  - A support path when a third-party app breaks.
  - A vendor who will still be there in three years.

  They are why the obligations in step 6 are the real product.

- **Individual developers** - internal builders, indie complementors, hobbyists - supply the early liquidity and the credibility. They need friction removed rather than contracts signed:
  - A sandbox in minutes.
  - Honest docs.
  - No gatekeeping on the first build.

  They punish anything that reads as a trap harder than any other audience, and a single unannounced breaking change costs years of goodwill.

One thing works identically for both: the complement is only built when the builder's own arithmetic works. Run step 4 for individuals too - their currency is time, not money, and it is just as finite.

## Measurement and the pass threshold

Every number below is a default this skill sets so the decision can be argued about, not an industry benchmark. Say so when presenting them: dressing a self-set default up as an industry figure is how an exec team stops questioning it. Where the team has its own historical data, prefer it and record that you replaced the default.

Hold the decision to this threshold before the memo is final, and iterate until it passes:

- The hypothesis sentence has no vague blanks, and the commoditized complement is named.
- Counted demand lists at least five requested complements with customers attached - not personas. Five is this skill's default; raise it for a product with thousands of accounts, lower it only with a written reason.
- Every gate is pass or fail; each remaining unknown has a resolver and a date.
- Exactly one rung is chosen and the standing team it requires is named and available.
- Rungs the answers ruled out are deleted from the memo rather than listed, and every surviving unchosen rung has a stated blocking reason.
- Complementor arithmetic is written for each archetype and produces a positive return for at least one.
- Every obligation in step 6 has a named owner.
- Baseline values exist today for each metric below; targets carry dates.
- Kill criteria include at least one failure condition with a threshold and a date.

Then measure the running program against your own baseline, never against a cross-industry figure:

- Complement supply: net new complements per quarter, and coverage of the demand list.
- Complementor activation: share of registered builders who ship anything, and time to first working complement.
- Customer adoption: share of accounts with at least one active complement, and the retention and expansion delta versus accounts with none. This is the number that funds the program.
- Concentration: share of ecosystem usage held by the top five complements - high means you have five partnerships, not an ecosystem.
- Cost: engineering hours held hostage by extension-point compatibility, and support tickets caused by third-party code.

## Common failure modes

- **Surfaces without demand.** Extension points ship, nobody builds, the team blames developer marketing. The cause is nearly always that nobody counted demand first.
- **Sherlocking your own complementors.** Shipping a feature that makes a third-party complement pointless - the term comes from Apple's Sherlock being superseded by Spotlight and is established vocabulary among Mac and iOS developers. Sometimes correct, never unannounced.
- **Envelopment from next door.** Eisenmann, Parker and Van Alstyne described platform envelopment in a 2007 Harvard Business School working paper: a neighboring provider bundles your capability into its own platform and absorbs the market. Name the platform that could do this to you before betting.
- **Frozen architecture.** Enough published extension points and the product cannot be refactored. Publish the smallest surface the demand justifies, version it from day one.
- **Governance debt.** Review queues, security escalations, deprecation comms and partner support all arrive at once, unstaffed. Refuse a rung you cannot staff.
- **Ecosystem theatre.** A partner logo wall and a directory nobody installs from. Report active complements per account, never announced partners.
- **Complementors too thin to survive.** Crowded categories, small reachable demand, or a take-rate imposed too early - complements rot and customers hit broken integrations.
- **No exit criteria.** Nobody shuts down an ecosystem program because withdrawal is embarrassing. Write the kill criteria while the decision is still cheap.

## References

- [references/ecosystem-readiness-gates.md](./references/ecosystem-readiness-gates.md) - the readiness gates with their pass conditions, and the complementor economics worksheet.
- [references/extension-surface-ladder.md](./references/extension-surface-ladder.md) - the six rungs: who builds, what you operate, reversibility, and the signal that you are on the wrong one.
- [references/ecosystem-memo-example.md](./references/ecosystem-memo-example.md) - an approved memo with weak versus strong versions of each section, and a declined memo with its reopen conditions.

Sourced concepts this skill leans on, all conceptual, none supplies a number:

- Joel Spolsky, Strategy Letter V (2002), on commoditizing complements.
- Steve Yegge's 2011 account of the Amazon interface mandate.
- Rochet and Tirole (_Journal of the European Economic Association_, 2003), on two-sided pricing.
- Gawer and Cusumano (_MIT Sloan Management Review_, January 2008), on the two platform-leadership challenges.
- Eisenmann, Parker and Van Alstyne (2007 Harvard Business School working paper), on envelopment.
- Ron Adner (_Harvard Business Review_, April 2006), on complement readiness.

Related skills in this collection:

- `samber/developer-relations-skills@open-source-company-strategy` - whether the surfaces themselves should be open source.
- `samber/developer-relations-skills@developer-first-gtm` - the adoption motion.
- `samber/developer-relations-skills@devtools-pricing-strategy` - pricing and packaging.
- `samber/developer-relations-skills@developer-segmentation` - naming the customer segments a complement is supposed to serve.
- `samber/developer-relations-skills@developer-journey-map` - the adoption path complements sit on.
- `samber/developer-relations-skills@open-standards-strategy` - the posture decision once an extension surface is a candidate for a shared, multi-vendor standard.

See also `samber/developer-platform-skills` once the rung is chosen. It carries the execution layer this decision hands off to:

- The integration surfaces themselves.
- The connector-marketplace operating model.
- Partner-app onboarding.
- Review standards.
- Marketplace economics.