etl-connector-strategy

{
  "skill_name": "etl-connector-strategy",
  "evals": [
    {
      "id": 1,
      "prompt": "I'm head of platform at Cadenza, a workforce-scheduling SaaS with about 1,400 business customers and $18M ARR. Our CFO wants a one-page business case before she'll fund a source connector for the big ELT platforms. She's asked specifically for the revenue line and the payback period, because that's how she evaluated our reseller and referral partnerships last year. Engineering quoted roughly 9 weeks for a first build. Write the case.",
      "expected_output": "A business case with no platform revenue line, built on support-cost deflection and retention, carrying a recurring maintenance percentage and an explicit statement that no ETL/ELT platform pays source vendors.",
      "files": [],
      "expectations": [
        "The business case contains no projected revenue-share, commission, or catalog-placement income line from the ETL/ELT platform.",
        "States explicitly that no ETL/ELT platform pays a source vendor for its connector.",
        "Any revenue-share program mentioned is described as announced but never delivered as described, not as an existing precedent to plan around.",
        "Describes the program that actually shipped as flat one-time per-task bounties rather than a revenue share, citing at least one amount in the $10-$150 range (for example $150 for a new sync mode or $50 for a minor bug).",
        "Ranks the payoff sources with support-ticket deflection and customer retention first and revenue share last.",
        "Places competitive-parity distribution above co-marketing or partner-tier demand-gen in that same ranking.",
        "Notes that co-marketing and partner-tier benefits require an active partnership relationship, not merely a listed connector.",
        "Budgets recurring annual maintenance at 15-30% of the original build cost, and notes it can reach roughly 50% in mature, high-change phases.",
        "States that each additional connector is an independent recurring obligation and that nothing amortizes across connectors.",
        "Frames the connector as a cost center bought for distribution, retention, and support-cost deflection rather than as a revenue source.",
        "Treats any build-cost benchmark figures as order-of-magnitude ranges rather than as quotes.",
        "Answers the payback request without inventing an ROI figure or a modeled revenue number."
      ]
    },
    {
      "id": 2,
      "prompt": "Our marketing site has a 'Data sync' page and our PMM wants to add a 'CDC support' checkmark to the comparison table, because two competitors show it and a prospect asked about it on a call. We're Lumenstack, B2B contract-management SaaS. Everything a customer can get out of us goes through our public REST API, which has updated_at on most objects. The ELT platforms our customers use pull from us every 6 hours. Give me the copy for that page and tell me whether the checkmark stays.",
      "expected_output": "Customer-facing copy using incremental-sync and eventual-consistency wording with the poll interval and its known gaps named, plus a refusal of the unqualified CDC checkmark and the reason it is structurally unavailable.",
      "files": [],
      "expectations": [
        "Rejects an unqualified 'CDC support' claim or checkmark for this product.",
        "Explains that CDC as the ETL platforms mean it is log-based: reading the database's own transaction log, such as a write-ahead log, binlog, or redo log.",
        "States that this product cannot use that mechanism because neither an external platform nor a public API has access to the internal transaction log of a multi-tenant SaaS backing database.",
        "Frames that limitation as a structural boundary rather than a maturity gap or a roadmap item.",
        "Uses 'incremental sync' or eventual-consistency language in the customer-facing copy instead of 'CDC'.",
        "States the 6-hour sync or poll interval in the customer-facing copy.",
        "Names changes made and overwritten within a single poll interval as something the model misses.",
        "Names hard deletes as undetectable wherever no deletion feed exists.",
        "Does not propose Debezium or any other log-based CDC tool as a path for this API-only product.",
        "Any webhook proposal is scoped as a freshness supplement that is not a backfill substitute and captures nothing before the connection date.",
        "Presents the honest substitute ladder in order of completeness: timestamp/cursor polling, then webhooks, then a vendor-side change/deletion feed, then periodic full re-import reconciliation.",
        "Treats a vendor-side deletion feed as a later completeness upgrade triggered by reported missed deletes, not as a launch-day promise."
      ]
    },
    {
      "id": 3,
      "prompt": "Northwind Fleet here, telematics SaaS, 320 customers, mostly mid-market logistics. Our VP Sales noticed our closest competitor sitting in a major ELT catalog and wants us listed before the Q4 board meeting. Support hasn't logged any requests for it that I'm aware of, and nothing came up in renewals this year. Engineering has capacity in November. Put the plan together.",
      "expected_output": "A stop at the demand-validation gate: no build approval, a named list of evidence to collect, a concrete reopening signal, and an alternative investment recommendation.",
      "files": [],
      "expectations": [
        "Refuses to approve a connector build on the evidence given, classifying it as an internal hypothesis rather than observed customer pull.",
        "Names the categories of verifiable demand evidence to collect first: support tickets naming a platform, lost-deal or churn notes citing data-stack mismatch, API-log evidence of hand-rolled extraction, and security or procurement questionnaires asking about warehouse sync.",
        "Describes the API-log evidence concretely as high-frequency paginated scans from data-team service accounts.",
        "States a concrete signal that would reopen the decision, such as a specific number of named-platform tickets within a quarter or one lost deal citing the gap.",
        "Recommends improving the raw API or a direct-to-storage delivery path as the alternative investment instead of building the connector now.",
        "Warns that a connector shipped without evidence still bills its annual maintenance percentage every year regardless of use.",
        "Treats competitive parity as a documented business driver but not as a substitute for named demand evidence.",
        "Does not produce a build plan, platform pick, or delivery timeline as the primary deliverable.",
        "Conducts the intake as an interview asking one question at a time rather than delivering a single block of questions.",
        "Requires the demand evidence to be attached to the decision record, with each claimed driver citing at least one verifiable artifact."
      ]
    },
    {
      "id": 4,
      "prompt": "Veridian Labs, clinical-trial ops SaaS, 40 enterprise customers. We have a 900k EUR renewal on the line where the customer's data team made 'available in our ELT tool' a written condition, and their procurement review closes in about five months. We can spare maybe 3 engineer-weeks up front and realistically 4 hours a month after that. Two of our four backend engineers write Python daily. Our object schema barely changes. Which way do we build it?",
      "expected_output": "A ranked build-path menu across several axes, the platform-managed listing recommended as default with its costs named, the compliance-cost inversion stated, and 2-3 candidate strategies ending in one recommendation and an explicit pick request.",
      "files": [],
      "expectations": [
        "Recommends the platform-managed listing, where the platform builds and maintains the connector, as the default path for this case.",
        "Shows an explicit ranked ordering across more than one axis rather than a flat list of options.",
        "Orders maintenance-tax exposure with the custom outside-platform path highest and the platform-managed listing lowest.",
        "States that compliance cost runs in the opposite direction to effort: highest on the platform-managed path, lowest on the custom path.",
        "Justifies that inversion by the platform-managed path's external source review, which can reject the source outright, and by its binding release-phase promotion clock.",
        "States that control over quality and cadence ties between the custom and vendor-SDK paths, and justifies the tie by the vendor keeping every implementation decision on both.",
        "Names the platform-managed path's real costs: a review gate of weeks that can reject the source, zero control over feature scope and cadence, and a fit limited to stable, non-dynamic schemas.",
        "Explicitly ties the hard renewal deadline to promoting the platform-managed queue in the ranking.",
        "Explicitly ties the 4-hours-per-month ceiling to demoting the higher-effort paths, or to the option of not building yet.",
        "Notes that the team's existing Python fluency lowers the effort of the vendor-SDK path and re-ranks against that fact rather than applying the default order unchanged.",
        "Checks the platform-managed path's own clock, including weeks of initial API-documentation analysis plus its advertised post-acceptance turnaround, against the five-month deadline instead of assuming it lands in time.",
        "Presents 2-3 candidate strategies, each combining a platform, a build path, and a resource scope, with trade-offs stated.",
        "Ends with one argued recommendation and asks the user for an explicit pick before moving on to the API readiness audit."
      ]
    },
    {
      "id": 5,
      "prompt": "Here's what our API looks like at Palladia, a B2B expense platform. List endpoints use page= and per_page= offset pagination. modified_at exists on expenses and reports but not on approvals or vendors. Deleting an expense sets is_active=false and the record keeps returning for 90 days, then it disappears from the API entirely. Rate limit is 600 req/min and we return a bare 429 with no body. First sync for a big customer is roughly 4M expense rows. We want to start writing the connector next sprint - anything we should know?",
      "expected_output": "An extraction-readiness audit sequenced before the connector build, grading each resource against the checklist and naming the cursor, delete-signal, backfill, rate-limit-signaling, and versioning fixes with their reasons.",
      "files": [],
      "expectations": [
        "Sequences the API fixes ahead of the connector build rather than alongside it or after it.",
        "States that fixing the extraction API cuts build and maintenance cost on every build path simultaneously, including customers' own hand-rolled pipelines.",
        "Flags offset pagination as unsafe under concurrent writes, because offsets shift under mid-scan inserts and deletes, and recommends an opaque stable cursor instead.",
        "Flags approvals and vendors as unable to sync incrementally until they expose a cursor or modification timestamp stable across syncs.",
        "Identifies the absent delete signal as the single most common gap, noting that most application APIs do not return deletes as changes so connectors silently miss them.",
        "Flags that records hard-deleted past the 90-day soft-delete window are lost permanently from the extraction path.",
        "Recommends a durable 'changes or deletes since <cursor>' feed as the buildable upgrade over relying on the is_active flag alone.",
        "Recommends a bulk or async backfill export endpoint separate from the UI-grade paginated endpoints, citing the 4M-row first sync and rate-limit exhaustion.",
        "Requires the 429 response to carry Retry-After so a connector can back off programmatically.",
        "Prescribes the overlap-window reconciliation pattern: persist the last cursor, re-query a small overlap window, upsert by stable key, and pair it with periodic full reconciliation.",
        "Grades each resource pass/fail against the checklist, with any resource that cannot pass carrying an explicit exclusion note rather than a silent skip.",
        "Raises versioning and deprecation discipline, noting that the large majority of breaking API versions ship with no deprecation notice at all (87.3% across 1,068 specifications), so monitoring rather than changelog-watching is the detection mechanism."
      ]
    },
    {
      "id": 6,
      "prompt": "Good news - our connector PR got merged and we're live in the marketplace as of Tuesday. Sales wants 'Certified connector, supported by the platform' on our integrations page and in our security questionnaire boilerplate. Separately our CTO is asking what the Partner Certified badge costs, because he'd like it in hand before our user conference in March. We're Sablefin, B2B payments reconciliation.",
      "expected_output": "A refusal of the certified/supported claim with the marketplace tier's actual support status, the listing-versus-certification distinction, the destination-only limit on the Partner Certified tier, and the quantitative bars adopted as SLOs.",
      "files": [],
      "expectations": [
        "Rejects both the 'certified' and the 'supported by the platform' claims for a freshly merged marketplace-tier connector.",
        "States that marketplace-tier connectors are explicitly outside the platform's support SLAs and may ship backward-incompatible breaking changes with no notice.",
        "Distinguishes listing, which is passing the platform's standard test suite, from certification, which is optional and earned.",
        "States that the Partner Certified tier covers destination connectors only, so a source connector cannot earn that badge.",
        "States that no platform charges a source vendor a fee for certification and none pays for it either: the cost is engineering time.",
        "Names the quantitative bars: at least 95% first-sync success, at least 95% overall sync success, first response within 3 business days, and the connector updated at least every 6 months.",
        "Recommends adopting those bars as the connector's own SLOs and feeding them into the maintenance plan even where the tier does not formally require them.",
        "States the certification framing that reliability and usability beat feature count, rather than treating certification as a feature-completeness bar.",
        "Lists the certification-grade behaviors to build regardless: every supported sync mode integration-tested, incremental sync wherever the source allows it, and failures that are fast and actionable rather than a configuration the platform accepts but that is guaranteed to break.",
        "Advises targeting certification only once the connector holds up across real syncs, rather than scheduling it backwards from the March conference date."
      ]
    },
    {
      "id": 7,
      "prompt": "One of our backend engineers, Tomas, is keen to write an open-spec tap for our product in his Friday time. Zero budget, ships in maybe three weeks, and it gets us listed on the community hub immediately. That looks strictly better than waiting two months for a platform review. We're Brightloom Analytics, 90 customers, mostly data-forward startups running their own open-source ELT. Sign off?",
      "expected_output": "A conditional approval that confirms the segment fit but refuses the volunteer-ownership arrangement, naming the decay record, the full maintenance-tax exposure, the month-13 owner requirement, and active monitoring.",
      "files": [],
      "expectations": [
        "Does not sign off on the plan as stated, despite the customer segment genuinely matching the open-source-first archetype.",
        "States that the custom or open-spec tap path carries 100% of the maintenance tax, with no part of it absorbed by a platform.",
        "Identifies the volunteer side-project arrangement as the documented decay path and requires a named owner with standing budget for month 13.",
        "Notes that the open-spec ecosystem has no entry gate and therefore no quality floor.",
        "Cites the ecosystem's decay record: taps of unknowable quality until used, several breaking upstream changes per year, and maintainers disappearing once sponsor attention moved.",
        "Notes that the open spec solved initial connector coverage but never ongoing maintenance.",
        "Confirms the one condition that does promote the custom path here: a strategic customer segment composing open-source-first stacks that the commercial platforms do not reach.",
        "Requires active monitoring and alerting on sync failures and schema-drift errors rather than waiting for customer tickets to surface breakage.",
        "Notes that upstream APIs will not announce their breaking changes, so changelog-watching is not a viable detection mechanism.",
        "Does not present the three-week, zero-budget estimate as the total cost of the path."
      ]
    },
    {
      "id": 8,
      "prompt": "Three things landed on my desk this week at Corvid, B2B logistics visibility. One: two customers' data teams want our shipment data as Parquet files dropped nightly into their own S3 buckets. Two: a prospect's analyst asked whether they can point Tableau at our data and query it live. Three: separately, two of our own integration partners want to build connectors into our app directory so joint customers can flip them on. The board deck calls all of this 'the connector strategy'. Sort it out.",
      "expected_output": "A separation of the three requests by direction and surface, routing the file-drop and live-query asks away from ETL source-connector work and identifying the inbound-marketplace request as the opposite problem.",
      "files": [],
      "expectations": [
        "Separates the three requests instead of treating them as one connector strategy.",
        "Routes the nightly Parquet-to-S3 request to a bulk or direct-to-storage data-sharing surface rather than to an ETL source connector.",
        "Routes the live-query-from-Tableau request to a SQL or JDBC access surface rather than to an ETL source connector.",
        "Identifies the partners-building-into-our-app-directory request as the opposite direction: third parties building into the vendor's own marketplace, a different problem from being a source in someone else's catalog.",
        "States the direction distinction explicitly: ETL connector strategy covers the vendor being extracted from by platforms the customer runs.",
        "Does not design an ETL/ELT source connector for the Parquet file-drop or the live-query request.",
        "Notes that none of the three requests as described constitutes demand evidence for ETL catalog presence.",
        "Asks which extraction platforms the customers' data teams actually run before recommending any catalog target."
      ]
    },
    {
      "id": 9,
      "prompt": "We got budget approved: 2 FTE for four quarters to 'cover the data ecosystem'. My plan is to ship source connectors on the six biggest ELT platforms in year one so we're never the reason a deal stalls. I'll admit I don't actually know which of them our customers use - we've never asked. Kestrel Compliance, 600 customers. Poke holes in this.",
      "expected_output": "A reduction to one platform first gated on measured maintenance load, a blocking finding on the unknown customer stacks, and the archetype framing that decides platform choice.",
      "files": [],
      "expectations": [
        "Reduces the plan to one platform first, with a second only after the first connector's maintenance load has been measured.",
        "States that the maintenance obligation compounds linearly with connector count and that nothing amortizes across connectors.",
        "Cites the threshold that self-built connector maintenance is manageable at roughly three to five sources and punishing beyond about ten.",
        "Treats the unknown customer stacks as a blocking gap: commissions the finding through a customer or prospect survey or a pass through integration-request tickets, and suspends the rest of the workflow until it lands.",
        "States that platform choice follows where customers' data teams actually run, never where the vendor's own engineers would prefer to build.",
        "Names the three platform archetypes and how each gates differently: the curated platform gatekeeps entry, the open-contribution platform gatekeeps labels, and the open-spec tap ecosystem has no gate at all.",
        "Notes that only customers with a warehouse and a data team extract anything, so the addressable segment is narrower than the 600-customer base.",
        "Requires a named owner for each connector before its launch, rather than treating the 2-FTE headline as the ownership answer."
      ]
    }
  ],
  "trigger_queries": [
    { "query": "Should we build a Fivetran connector for our product?", "should_trigger": true },
    {
      "query": "Customers keep asking when we'll show up in their ETL platform's catalog - what do I tell them?",
      "should_trigger": true
    },
    { "query": "how do we get listed on Airbyte as a source", "should_trigger": true },
    {
      "query": "Our data-sync page claims CDC support. Is that honest for an API-only SaaS?",
      "should_trigger": true
    },
    {
      "query": "what's the business case for a source connector if nobody pays us for it",
      "should_trigger": true
    },
    {
      "query": "we want our customers' data teams to pull our data into Snowflake without writing any code",
      "should_trigger": true
    },
    {
      "query": "Do we build the connector ourselves on their SDK or go through the platform's request program?",
      "should_trigger": true
    },
    { "query": "should we write a Singer tap for our API", "should_trigger": true },
    { "query": "planning our ELT catalog presence for next year", "should_trigger": true },
    {
      "query": "our API really isn't built for being extracted from - what do we fix first?",
      "should_trigger": true
    },
    { "query": "who maintains a data connector after year one", "should_trigger": true },
    {
      "query": "customers are hand-rolling their own extraction jobs against us, it's all over our logs",
      "should_trigger": true
    },
    { "query": "what does it actually cost to keep a data connector alive", "should_trigger": true },
    {
      "query": "is it worth getting certified on the ELT platform or is a plain listing enough",
      "should_trigger": true
    },
    {
      "query": "security questionnaires keep asking about warehouse sync and we have no answer",
      "should_trigger": true
    },
    { "query": "how do I word incremental sync honestly on our marketing site", "should_trigger": true },
    {
      "query": "Our competitor shows up in the connector catalog and we don't. What now?",
      "should_trigger": true
    },
    { "query": "would publishing a tap on MeltanoHub be worth it for us", "should_trigger": true },
    {
      "query": "data teams want to extract our product data on a schedule into their lake",
      "should_trigger": true
    },
    { "query": "which ELT platform should we target first", "should_trigger": true },
    { "query": "how many source connectors should we commit to building", "should_trigger": true },
    {
      "query": "our product needs to be a source in our customers' data pipelines",
      "should_trigger": true
    },
    { "query": "can we support change data capture out of our REST API", "should_trigger": true },
    {
      "query": "the platform's by-request program rejected us as a source, now what",
      "should_trigger": true
    },
    {
      "query": "we told customers deleted records would sync and they don't, how do we fix the story",
      "should_trigger": true
    },
    {
      "query": "we need catalog presence before a sales cycle closes in six weeks",
      "should_trigger": true
    },
    { "query": "budgeting connector upkeep for next fiscal year", "should_trigger": true },
    {
      "query": "there's no revenue share anywhere in this - how do I justify the spend to finance",
      "should_trigger": true
    },
    {
      "query": "do they build and maintain it, or do we? trying to work out the trade",
      "should_trigger": true
    },
    {
      "query": "our object schema changes constantly, will the managed connector path even take us",
      "should_trigger": true
    },
    { "query": "make me a plan for showing up inside our customers' data stacks", "should_trigger": true },
    {
      "query": "we want to stop customers writing their own scrapers against our endpoints",
      "should_trigger": true
    },
    {
      "query": "getting our SaaS into the warehouses our customers already run",
      "should_trigger": true
    },
    { "query": "what SLAs do we owe once we list a connector somewhere", "should_trigger": true },
    {
      "query": "what's the clock on promoting a connector from private preview to beta",
      "should_trigger": true
    },
    {
      "query": "I need a strategy doc for our data-pipeline integration investment",
      "should_trigger": true
    },
    {
      "query": "are webhooks enough for customers syncing our data, or do they need polling too",
      "should_trigger": true
    },
    { "query": "one platform or several for our data-integration presence?", "should_trigger": true },
    {
      "query": "prospects keep saying we don't fit their modern data stack and I'm not sure what that means for us",
      "should_trigger": true
    },
    {
      "query": "can the connector be a side project for one of the engineers or does it need a real owner",
      "should_trigger": true
    },
    {
      "query": "support keeps fielding questions about pulling our data out on a schedule",
      "should_trigger": true
    },
    { "query": "we want to become a source connector - where do I start", "should_trigger": true },
    {
      "query": "design our own app marketplace so partners can build connectors into our product",
      "should_trigger": false
    },
    {
      "query": "set up the review and approval process for third-party apps submitted to our marketplace",
      "should_trigger": false
    },
    {
      "query": "rewrite the listing copy and screenshots for our Salesforce AppExchange page",
      "should_trigger": false
    },
    {
      "query": "should we ship Parquet exports to customers' S3 buckets as a product surface",
      "should_trigger": false
    },
    {
      "query": "design a JDBC endpoint so customers can query our data live from their BI tool",
      "should_trigger": false
    },
    { "query": "set up Debezium CDC from our Postgres primary into Kafka", "should_trigger": false },
    {
      "query": "configure Airbyte in our infra to ingest Stripe and Zendesk into our Snowflake",
      "should_trigger": false
    },
    {
      "query": "write dbt models to transform our raw ingested tables into marts",
      "should_trigger": false
    },
    {
      "query": "our outbound webhook deliveries keep failing - design retries and a dead-letter policy",
      "should_trigger": false
    },
    {
      "query": "define our API deprecation notice window and the sunset headers we send",
      "should_trigger": false
    },
    {
      "query": "which integration surfaces should we offer at all - REST, GraphQL, gRPC, SDKs?",
      "should_trigger": false
    },
    {
      "query": "which technology partners should we integrate with, and how deep should each one go",
      "should_trigger": false
    },
    {
      "query": "set the rate-limit tiers and 429 headers for our public API",
      "should_trigger": false
    },
    {
      "query": "design our OAuth2 authorization server and consent screen for third-party apps",
      "should_trigger": false
    },
    {
      "query": "build a machine learning feature pipeline with scheduled retraining",
      "should_trigger": false
    },
    {
      "query": "our Airflow DAG keeps failing on the nightly load, help me debug it",
      "should_trigger": false
    },
    {
      "query": "what take rate and fee stack should our app marketplace charge developers",
      "should_trigger": false
    },
    {
      "query": "design an MCP server so AI agents can take actions in our product",
      "should_trigger": false
    },
    {
      "query": "audit our API reference docs for undocumented parameters and missing response codes",
      "should_trigger": false
    },
    {
      "query": "how do we onboard partner developers into sandbox accounts and certification",
      "should_trigger": false
    },
    {
      "query": "add idempotency-key support so integrators can retry POSTs safely",
      "should_trigger": false
    },
    {
      "query": "build a CI/CD deployment pipeline with staged rollouts for our service",
      "should_trigger": false
    },
    {
      "query": "what should our status page show during a partial outage of one component",
      "should_trigger": false
    },
    {
      "query": "which languages get official SDKs and in what order should we ship them",
      "should_trigger": false
    },
    {
      "query": "we're hiring a partner integration engineer - write the interview loop and scorecard",
      "should_trigger": false
    },
    {
      "query": "design the error-code taxonomy and problem-details envelope for our public API",
      "should_trigger": false
    },
    {
      "query": "our developer portal's signup-to-first-call path takes way too long, fix the IA",
      "should_trigger": false
    },
    {
      "query": "set up a test mode with magic values so integrators can build without real charges",
      "should_trigger": false
    },
    {
      "query": "ingest a folder of PDFs and spreadsheets into our internal knowledge base",
      "should_trigger": false
    },
    {
      "query": "plan the co-marketing launch cohort for the apps going live on our marketplace",
      "should_trigger": false
    },
    {
      "query": "write the listing content standards every third-party app on our marketplace must meet",
      "should_trigger": false
    },
    {
      "query": "how should we store, prefix, and rotate the API keys we issue to customers",
      "should_trigger": false
    },
    {
      "query": "review our REST resource naming, URI structure, and status-code usage",
      "should_trigger": false
    },
    {
      "query": "design Relay cursor connections and complexity limits for our public GraphQL schema",
      "should_trigger": false
    },
    {
      "query": "surface per-integration failure logs with replay to the partners who built against us",
      "should_trigger": false
    },
    {
      "query": "should we publish a gRPC surface externally or keep it internal behind REST",
      "should_trigger": false
    },
    {
      "query": "our recruiting pipeline is leaking candidates at the technical screen, diagnose it",
      "should_trigger": false
    },
    {
      "query": "write an Elasticsearch ingest pipeline to parse and enrich our application logs",
      "should_trigger": false
    },
    {
      "query": "we're migrating our internal warehouse from Redshift to Snowflake, plan the cutover",
      "should_trigger": false
    },
    {
      "query": "wire up a Google Calendar connector so our agent can read my schedule",
      "should_trigger": false
    },
    {
      "query": "I have a developer-platform task and no idea which of these skills covers it",
      "should_trigger": false
    },
    {
      "query": "build an internal pipeline that moves our product telemetry into our own analytics warehouse",
      "should_trigger": false
    }
  ]
}

# Extraction-readiness checklist and the honest-CDC ladder

## The extraction-friendly API checklist

Audit every resource in connector scope against these properties. Each one holds on every build path - platform-managed, vendor-SDK, or custom - and for every customer pipeline hand-rolled against the raw API, which is why fixing the API precedes building any connector.

1. **Cursor-based pagination over offset-based.** An opaque, stable cursor eliminates duplicate/missed records under concurrent writes; offsets shift under insert/delete mid-scan. Time-window pagination (start/end timestamp) is the fallback, with the caveat that records sharing a timestamp can duplicate.
2. **A cursor or timestamp guaranteed stable across syncs**, so a connector checkpoints it and resumes exactly where it stopped instead of re-scanning from zero. This single property is what makes incremental sync possible at all - and it is what platform certification bars like "supports incremental sync wherever possible" implicitly grade.
3. **An explicit overlap/reconciliation story for soft-incremental sources.** Where no hard guarantee exists:
   - Persist the last cursor.
   - Re-query a small overlap window.
   - Upsert by stable key so the overlap can't duplicate.
   - Pair with periodic full reconciliation to catch what incremental structurally misses.
4. **Purpose-built bulk/incremental export endpoints, separate from real-time CRUD.** A dedicated "records changed since <cursor>" endpoint - instead of the same paginated endpoint the human UI uses - is the unlock vendors point to for reliable sync. It matters most at first sync: paginated-REST-only backfill is slow and rate-limit-prone; a bulk/async export job backfills once, then hands off to incremental.
5. **Webhooks as a freshness supplement, never a backfill substitute.** Push events cut polling lag for event-shaped data, but the platform-side limitation is stated plainly: webhooks cannot sync historical data - nothing before the connection date is captured. The working pattern is both: webhooks for freshness, a polling/bulk path for backfill and reconciliation.
6. **Rate-limit signaling a connector acts on programmatically:**
   - Standard 429 with `Retry-After`.
   - Where feasible, a 304/not-modified path for polled endpoints that doesn't spend rate-limit budget - connectors poll far more predictably and frequently than interactive clients.
7. **An explicit delete/change signal** - the single most common gap. The platform-side default is blunt: most application APIs don't return deletes as changes, so deletes go undetected and uncaptured. Even sources that expose one have limits - a soft-delete endpoint that stops answering after a hard-delete window loses records permanently. A durable "changes/deletes since <cursor>" feed is the concrete, buildable upgrade over a bare soft-delete flag.
8. **A documented per-resource extraction contract**, instead of leaving connector authors to guess:
   - Which strategy each endpoint actually supports (incremental vs full snapshot).
   - Expected volumes.
   - Whether hard deletes matter.
   - Freshness expectations.
9. **Versioning discipline that assumes connectors aren't watching the changelog.** 87.3% of breaking-change API versions industry-wide ship with no deprecation notice (ICSME 2020, n=1,068 specs). Version the API, publish deprecation/sunset dates, add fields additively, never silently rename or remove. A citable policy shape: date-based versioning where the previous version stays supported for at least 24 more months after a new one ships.

Grade each resource pass/fail per item; a resource that can't pass gets an explicit exclusion note in the strategy document, never a silent skip.

## Why a SaaS source never gets true CDC

"CDC support" as an ETL-platform feature means **log-based CDC**: reading the database's own transaction log (Postgres WAL, MySQL binlog, Oracle redo, SQL Server CDC tables) to reconstruct every insert/update/delete with minimal overhead and near-real-time latency - Debezium being the reference implementation.

A SaaS vendor offering itself as a source connector **cannot use this mechanism**: log-based CDC requires access to the internal transaction log of the system being read, which an external ETL platform - or the vendor's own public API surface - by definition does not have for a multi-tenant SaaS backing database. This is a structural boundary, not a maturity gap. The platforms' own CDC tooling applies log-based CDC only to databases customers point them at directly; every SaaS application source in their catalogs runs API polling.

The platforms say so themselves, under the CDC label: "for most application connectors, Fivetran performs a change data capture (CDC) strategy… based on a last modified date column. Because Fivetran does not receive every change to a row, but only the deltas… Fivetran supports a model of **Eventual Consistency**" (default 6-hour sync). A practitioner essay names the industry-wide pattern: connector platforms are, at bottom, "**pseudo-CDC**: change data capture reconstructed from webhooks and polled list APIs, one bespoke connector at a time."

## The honest substitute ladder, in order of completeness

1. **Timestamp/cursor incremental polling** via the API's own fields (`updated_at`, a stable cursor) - the practical default the checklist above exists to support. Structural weaknesses: changes made and overwritten within one poll interval are invisible; hard deletes are undetectable without a deletion feed.
2. **Webhooks as a push supplement** - genuinely closer to CDC's latency profile, but only as complete as the event catalog, and never a backfill.
3. **A vendor-side change/deletion feed endpoint** - the closest a SaaS gets to log-based completeness: implement internal CDC yourself and republish it as a stable, versioned API contract. Build it when customers report missed deletes or missed rapid updates, and treat it as the upgrade path from bare polling.
4. **Periodic full re-import reconciliation** - a backstop, not a strategy: platforms re-import certain tables specifically because deletes can't be captured from them, accepting a full re-scan to catch what incremental misses.

## Wording for customer-facing material

- Say "incremental sync" or "eventual-consistency extraction"; never an unqualified "CDC support" checkbox next to database sources whose CDC is log-based.
- State the sync/poll interval and name what the model misses: intra-interval overwrites, and hard deletes wherever no deletion feed exists.
- If the deletion feed ships later, announce it as the completeness upgrade it is - that framing is credible precisely because the earlier language didn't overclaim.

# Connector maintenance economics and the revenue-share reality

## Build-cost baselines

Vendor-published estimates from integration-tooling vendors (both sell integration products - treat as order-of-magnitude, never as quotes): a single moderately complex API integration at $10,000-$50,000 to build (Albato); $50,000-$150,000+ for a single advanced integration (Bindbee). Use the ratio these imply, not the figures, when sizing a specific build.

## The maintenance tax

- **Annual maintenance runs 15-30% of the original build cost, and can reach 50% in mature, high-change phases** (Bindbee: "annual maintenance runs 15–25% of the original build cost, and can reach 50% in mature phases"; their cited example puts ten in-house integrations' upkeep at roughly $150,000/year - keep the ratio, drop the figure outside that context).
- The tax compounds linearly with connector count: each connector is an independent recurring obligation sharing no fixed cost with the others. Practitioner framing: self-built connector maintenance is "manageable at three to five sources" but "punishing across more than ten" - the point where it becomes specialist work.
- **Four cost drivers** account for most of the spend:
  - Authentication changes.
  - Schema drift - fields renamed, retyped, or restructured without notice.
  - Rate-limit shifts.
  - Pricing/compliance overhead.

## The one peer-reviewed figure in this domain

Yasmin, Tian & Yang, "A First Look at the Deprecation of RESTful APIs: An Empirical Study" (ICSME 2020): across 1,068 specifications spanning 212 multi-version APIs, 251 versions introduced breaking changes - and **219 of those (87.3%) shipped with no deprecation information at all**; only 32 (12.7%) carried any prior signal. The same study found on average 46% of a REST API's operations are deprecation-related at some point in its lifecycle. Even a "generous" notice window in industry commentary is often only 30 days.

Two planning consequences:

1. Budget for upstream breakage arriving unannounced - monitoring, not changelog-watching, is the detection mechanism.
2. The vendor's _own_ API change discipline directly sets this cost for every connector and every customer pipeline built against it - which is why the extraction-readiness audit sequences before any build.

## Who absorbs the tax, per build path

- **Platform-managed listing**: the platform absorbs it. The managed platforms' own pitch is connectors that "require zero maintenance, and automatically adjust to source changes," and customer-side quotes credit exactly this (Strava's data scientist on being freed from maintaining connectors and handling API changes).
- **Vendor-SDK connector**: split - the platform hosts and runs the code and centralizes shared logic (a low-code layer ships cursor-handling fixes once for every connector built on it), but the vendor must validate data, notify the platform of upcoming source changes, and redeploy.
- **Custom outside-platform connector**: 100% with whoever built it. Meltano's own warning about the "benevolent community member" model is the documented failure shape.

## Revenue share: essentially does not exist

- **No ETL/ELT platform pays a source vendor for a connector.** Fivetran charges its customers on Monthly Active Rows; the customer pays, the source vendor is not paid, and no public program shares that revenue back. Stitch/Singer and Meltano run on free contributions - historically Singer contributors received swag, not money.
- **Airbyte is the only platform that ever proposed revenue share, and it did not ship as announced.** September 2021, tied to its license change: a floated "participative model" where connector maintainers "would have the option to get a revenue share" in exchange for owning SLAs and fixes - explicitly conditional language. Cite it as announced-but-never-delivered-as-described, never as an existing precedent.

  What shipped in April 2022 was a bounty-based Maintainer Program of flat one-time fees, a shape the current Contributor Program still keeps:
  - New sync mode: $150.
  - Missing streams: $150.
  - Full unit-test coverage: $150.
  - Critical bug: $100.
  - Minor bug: $50.
  - Docs: $10-$25.

- **Certification is not charged either**, on any platform: the cost of a badge is the vendor's engineering time, not a listing fee.

## What exists instead: co-marketing and partner programs

Real, but not connector pay:

- Fivetran's enhanced Partner Program (announced 2025) offers partner tiers, resell/co-sell motions, co-branded marketing and demand-gen tools, and a partner academy.
- Airbyte's partner program (launched 2024) targets technology-services providers with co-sell support.

Both are primarily consulting/reseller/SI and technology-alliance motions - **neither platform publicly offers a SaaS source vendor paid premium catalog placement or expedited engineering priority**. Treat that as "not publicly stated," not as proof private arrangements never happen.

## Payoff ranking for the internal pitch

By realistic, attributable value: **support-ticket deflection and customer retention (real, direct, immediate once the connector ships) > competitive-parity distribution (real but hard to attribute) > co-marketing/demand-gen via a partner tier (available, but requires an active partnership relationship, not just a listed connector) > revenue share (essentially does not exist - do not plan around it)**.

Lead the internal business case with support-cost and retention math. A case built on a hoped-for revenue line fails at its first finance review - and deserves to.

# Platform programs for source-connector vendors

Snapshot dated 2026-08-30. Programs, gates, and tier names change; re-verify against each platform's current partner documentation before committing to a path.

## Fivetran (curated archetype - gatekeeps entry)

| Path                  | Status                                 | Who builds/maintains                                                                                                             | Gate                                                                                                                                                                                                             | Notes                                                                                                                                                                                                             |
| --------------------- | -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Partner-Built program | **Closed to new source partners**      | Vendor builds on Fivetran's partner SDK; support triaged by root cause                                                           | Manual code review (repo access, "allow up to a week")                                                                                                                                                           | Remains documented for destination connectors only. Live Partner-Built sources are few and database-leaning (Convex, Datastreamer, PlanetScale, SingleStore, Tracksuit) - it was a narrow track before it closed. |
| Connector SDK         | **Active - the live self-build path**  | Vendor writes a Python connector (`fivetran-connector-sdk`, gRPC-based); listed as a "community connector" alongside native ones | Standard listing, no badge                                                                                                                                                                                       | Ships templates and a mock/local test environment - build and validate without a live Fivetran account. Actively maintained; 100+ community connectors already listed.                                            |
| By Request (Lite)     | **Active - the platform-managed path** | Fivetran builds and maintains                                                                                                    | Six phases (submission, validation, consultation, development, rollout); "two to eight weeks" of initial API-documentation analysis; **can reject**: "if the source is not a great candidate… the process stops" | Advertised turnaround as fast as 30 days once accepted. Fits "SaaS APIs that produce a non-dynamic schema"; dynamic/custom schemas get steered to the SDK.                                                        |

Release-phase clock, all paths: in-dev (hidden) → Private Preview → Beta → GA, with a hard rule that source connectors "must be promoted to Beta within six months of entering Private Preview." Support splits by root cause, not badge: Fivetran fixes Fivetran-side issues; partner-side issues go to the partner, at the partner's own SLA.

## Airbyte (open-contribution archetype - gatekeeps labels)

Three build tiers, least to most code - reach is roughly flat across them (listing never requires certification); the real limit is how much of the API's quirks the declarative layer can express before forcing a move up:

1. **No-code Connector Builder**: UI-driven; one-click "Contribute to Marketplace" opens the submission PR directly.
2. **Low-code declarative manifest**: YAML-like spec on the Python CDK for streams/pagination/auth; no Python for most sources. Centralizes shared logic (cursor handling, resumable refresh) so fixes ship once for every connector built on it.
3. **Full CDK** (Python; community-maintained Java/TypeScript): for sources too custom for the manifest. Starts as a GitHub discussion so design conflicts surface before code.

Quality tiers:

- **Marketplace inclusion**: pass the standard test suite, get merged. Deliberately a low bar: certification would add "a barrier to entry" the platform doesn't want on every contribution.
- **Airbyte Certified**: optional, earned. Principles:
  - Reliability and usability beat feature count - "one solid connector is better than two finicky ones."
  - Fail fast and actionably - never accept a configuration guaranteed to break.
  - Every supported sync mode integration-tested.
  - Incremental sync wherever the source allows.
- **Partner Certified**: _destination connectors only_, the closest analog to Fivetran's closed badge. Quantitative bars:
  - ≥95% first-sync success.
  - ≥95% overall sync success.
  - ≤3-business-day first response.
  - Connector updated at least every 6 months.

Support taxonomy, four levels:

- **Airbyte (Certified)**: platform-built, covered by Airbyte's support SLAs.
- **Enterprise**: Airbyte-built premium connectors (SAP/Oracle/Workday/NetSuite-class).
- **Marketplace**: community-maintained, "not covered by Airbyte support SLAs… may experience backward-incompatible, breaking changes with no notice."
- **Custom**: build-your-own, workspace-exclusive.

The trade this buys: a much larger catalog (600+ advertised) than a curated one, at variable maturity.

## Singer / Stitch / Meltano (open-spec ecosystem - no gate, no floor)

- **Singer** (2017, StitchData): open tap/target spec over stdin/stdout newline-JSON - minimal by design, which enabled a large uncoordinated ecosystem. Stitch open-sourced the _spec_ to crowdsource coverage but withheld the _operational_ tooling (orchestration, state, monitoring), so community taps still needed a paid Stitch subscription to run reliably.
- **Meltano** (GitLab-born) filled the withheld layer as open source, plus a Singer SDK scaffolding spec-compliant taps and MeltanoHub as the catalog (200+ taps/targets).
- **Decay record**: the cautionary case for any custom-path plan, after Stitch's acquisition:
  - Community investment dropped.
  - Each tap is an independent project with no enforced quality bar - "you never know the quality of a tap until you've used it."
  - Most see multiple breaking upstream changes a year, and many go unmaintained.

  Even Meltano's docs warn the "benevolent community member" model "is great in the short-term, but… individuals may not always be able to maintain a connector."

- Stitch itself layers the same certified-vs-community split all three ecosystems converged on:
  - **Certified** taps are commercially supported - "a guarantee that the Stitch team will fix bugs and adapt to new versions of third-party APIs."
  - **Community** taps get commercial support only under an Enterprise contract.

When this path is worth it anyway: a strategic customer segment already composes open-spec stacks the commercial platforms don't reach, and the vendor commits a named owner - the decay record is what happens without one.

## Choosing between them

Match the platform to interview answer 2 (where customers' stacks run), not to a platform-quality league table. Where evidence is split, the archetype difference decides:

- The curated platform's gate buys a stronger quality signal at the risk of rejection and no control.
- The open platform guarantees presence but makes the certified tier the actual differentiator.
- The open-spec ecosystem is presence-of-last-resort with the maintenance obligation fully internalized.

---
name: etl-connector-strategy
description: Plan a SaaS vendor's presence as a source connector on third-party ETL/ELT platforms - demand validation before any build, platform selection from where customers' data stacks run, a build-path menu (platform-managed listing, vendor-maintained SDK connector, custom open-source tap) ranked by who absorbs the maintenance tax, an extraction-readiness audit of the product API, honest CDC scoping (API sources ship pseudo-CDC, never log-based), certification targets, and a funded maintenance plan. Use whenever the user mentions an ETL or ELT catalog listing, a source connector, data-pipeline integration, or adding CDC - even if they never say "connector strategy". Do NOT use for the vendor's own inbound marketplace - use samber/developer-platform-skills@connector-marketplace-strategy instead.
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.1"
---

# ETL Connector Strategy

You are a data-integration strategist for a SaaS vendor. Decide whether, where, and how the vendor should appear as a **source** in its customers' ETL/ELT pipelines - and what that presence costs to keep alive. Direction matters: this skill is about being extracted _from_ by platforms the customer runs. Third parties building into the vendor's own marketplace is the opposite problem (see References).

Hold one economic fact in front of every decision below: a source connector is a cost center bought for distribution, retention, and support-cost deflection. No ETL/ELT platform pays a source vendor a revenue share - the one platform that ever proposed it shipped flat per-task bounties instead (see [references/maintenance-and-revenue-economics.md](references/maintenance-and-revenue-economics.md)).

**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

This is a strategy interview: one question per message, multiple-choice where possible. Each answer gates or re-ranks a later step.

1. Demand evidence - what observed customer pull exists? (a) support tickets asking for a named ETL platform; (b) lost-deal or churn notes citing data-stack incompatibility; (c) customers hand-rolling pipelines against your API, visible in API logs or support load; (d) none yet - internal hypothesis only.
2. Customer stacks - which extraction platforms do your customers' data teams actually run? (a) managed commercial ELT; (b) self-hosted or open-source ELT; (c) open-source-first tap ecosystems; (d) unknown - must be found out before anything else proceeds.
3. Extraction-readiness - does your public API already expose a stable incremental cursor (or reliable `updated_at`), a bulk/backfill path, and a delete signal? (a) all three; (b) cursor only; (c) UI-grade CRUD endpoints only; (d) unsure.
4. Maintenance capacity - who owns the connector in month 13? (a) a named team with standing budget; (b) a side-task on an existing team; (c) nobody yet.
5. Deadline - must catalog presence land by a date (a sales cycle to unblock, a competitive evaluation), or is there none?
6. One-off or compounding - is this a checkbox for one deal, or a standing distribution asset?
7. Effort ceiling - engineering weeks available up front, and hours per month sustainable after launch?

Questions 5-7 re-rank the build-path menu in step 3:

- A hard deadline promotes the platform-managed queue.
- A compounding mandate plus real capacity promotes the SDK rung.
- A near-zero effort ceiling demotes everything except the queue - or the decision not to build yet.

## Customer data-stack maturity

The strategy splits by **which stacks customers' data teams run** - only customers with a warehouse and a data team extract anything, whoever the vendor sells to:

- **Managed-ELT shops** - enterprise-leaning teams on commercial managed platforms. Presence means passing that platform's gated listing review, and the platform's curation is the quality signal buyers read.
- **Self-hosted / open-source ELT shops** - cost-sensitive or data-sovereignty-driven teams. Listing is an open contribution process with a low bar; the optional certification tier is the differentiator.
- **Open-source-first tap ecosystems** - teams composing open-spec taps and targets themselves. The cheapest presence to establish and the fastest to decay unmaintained (see Failure modes).

Interview answer 2 decides which segment is served first. Build where the observed customer stacks are, never where the vendor's engineers would prefer to build.

## Workflow

1. Demand-validation gate.
2. Platform selection.
3. Build-path choice (ranked menu + brainstorm).
4. Extraction-API readiness audit.
5. CDC honesty scoping.
6. Certification path.
7. Maintenance plan.

Each step has a section below, in order. Do not reorder: steps 1-2 supply the evidence steps 3-7 spend.

## 1. Demand-validation gate

- Approve no connector build on hypothesis. Collect named, verifiable evidence: support tickets requesting a platform by name, lost-deal notes citing data-stack mismatch, API logs showing hand-rolled extraction (high-frequency paginated scans from data-team service accounts), security/procurement questionnaires asking about warehouse sync.
- The documented business case clusters around four drivers:
  - Relief of customers' non-core maintenance burden.
  - Distribution through the platform's network of destinations.
  - Competitive table stakes in data-stack evaluations - major catalogs run 500-700+ connectors, and absence reads as a gap, not a neutral fact.
  - Retention/support-cost deflection.
- Keep the business case inside what the quotable evidence actually covers: the strongest rationale (ezCater's "a large investment in a platform that's not part of our core business") comes from a data _consumer_ building its own tap, not from a SaaS vendor instrumenting its own product as a source. Promise the driver, never an ROI figure.
- If evidence is thin, stop here. Recommend improving the raw API or direct-to-storage delivery instead (see References), and name the signal that would reopen this decision (e.g. three named-platform tickets in a quarter, one lost deal citing the gap).
- Route mismatched demand out to the sibling skill it actually fits:
  - "files in our bucket" is bulk data sharing.
  - "live SQL against your data" is SQL access.

## 2. Platform selection

- Follow interview answer 2 - target the platform archetype your customers' evidence names, one platform first, a second only after the first connector's maintenance load is measured.
- The three archetypes gate differently:
  - The curated platform gatekeeps _entry_: a multi-week review that can reject a source outright.
  - The open-contribution platform gatekeeps _labels_: anyone lists, and certification is the earned tier.
  - The open-spec tap ecosystem has no gate at all - and no floor either.
- Read [references/platform-program-tables.md](references/platform-program-tables.md) before committing: it holds the named programs, submission paths, review timelines, release-phase clocks, and support-tier taxonomies per platform, as a dated snapshot to re-verify.
- If answer 2 was "(d) unknown", commission the finding first - a short customer/prospect survey or a pass through integration-request tickets - and suspend the workflow until it lands.

## 3. Build-path choice

The decision axis is who absorbs the maintenance tax - annual upkeep running an appreciable fraction of the original build cost, every year, per connector (vendor-published estimates; the figures and their sources are in step 7). Three paths, ranked:

- effort (descending): `custom outside-platform connector > vendor-SDK connector > platform-managed listing`
- maintenance-tax exposure (descending): `custom (100% yours) > vendor-SDK (split: platform hosts, you fix) > platform-managed (platform absorbs)`
- control over quality and cadence: `custom == vendor-SDK > platform-managed`
- compliance cost (descending): `platform-managed > vendor-SDK > custom` - the managed path triggers the platform's own source review, which can reject outright, and a binding release-phase promotion clock; the SDK path commits you to the platform's contribution terms and update cadence; the custom path triggers no external review and stays fully reversible.
- efficiency: `platform-managed > vendor-SDK > custom`

The `==` tie is genuine: on both the custom and SDK paths, every implementation decision (cursor logic, incremental semantics, update cadence) stays with the vendor; the platform only changes who hosts and distributes the code, not who decides.

- **Default rung: the platform-managed listing.** The platform's request program builds and maintains the connector; the vendor supplies API documentation and a contact. Lowest tax exposure, fastest to a badge. Its real costs:
  - A review gate of weeks that can reject the source outright.
  - Zero control over feature scope and cadence.
  - A fit limited to sources with stable, non-dynamic schemas.
- **Promote to the vendor-SDK connector** when any of these hold:
  - Validated demand justifies standing engineering.
  - The managed queue rejected the source, or the schema is too dynamic for the platform's lightweight path.
  - Control over cursor logic and update cadence is worth owning the tax.

  The vendor writes and maintains the connector on the platform's SDK; the platform hosts and distributes it.

- **The starved option: the custom outside-platform connector** (bespoke pipeline or open-spec tap). Highest control and full platform independence, highest effort and 100% of the tax - it loses every efficiency round. It is promoted anyway when no platform covers the need, or when a strategic customer segment runs open-source-first stacks the commercial platforms don't reach. Carry the decay warning with it (see Failure modes).

This ranking is a default, not a law. Re-rank against interview answers 5-7 and anything else known about the vendor, for example:

- A team already fluent in the platform's SDK language gets the SDK rung nearly free, which moves the effort line.
- An API too custom for the platform's declarative layer deletes the platform-managed rung rather than demoting it.

Then brainstorm before deciding: present 2-3 candidate strategies (each a platform × build-path × resource-scope combination) with trade-offs (time to catalog presence, who owns the tax, control retained) and one argued recommendation. Get an explicit pick from the user before step 4.

## 4. Extraction-API readiness audit

Audit the product API against [references/extraction-readiness-and-cdc.md](references/extraction-readiness-and-cdc.md) before any build starts, and sequence fixes ahead of connector work. This is the single highest-ROI investment in the whole strategy: it cuts build and maintenance cost on every path simultaneously - including every customer's hand-rolled pipeline. The checklist headlines:

- A checkpointable cursor the API guarantees stable across syncs - the property that makes incremental sync possible at all.
- A bulk/backfill endpoint separate from UI-grade CRUD pagination, so first sync doesn't burn the rate limit.
- An explicit delete/change signal - the most common gap; most application APIs return no deletes, so connectors silently miss them.
- Programmatic rate-limit signaling (429 with `Retry-After`).
- Additive versioning with published deprecation/sunset dates. An empirical study of 1,068 API specifications found 87.3% of breaking-change versions shipped with no deprecation notice at all (ICSME 2020) - every unannounced break becomes connector maintenance someone pays for. The source API's own change discipline is `samber/developer-platform-skills@api-versioning-policy` territory; hold it to that skill's notice-window standard.

## 5. CDC honesty scoping

- Never promise "CDC support" as if it were log-based CDC. The boundary is structural, not a maturity gap: log-based CDC reads the internal transaction log of the database being extracted, and no external platform - and no public API - gets that for a multi-tenant SaaS. The platforms' own SaaS-source "CDC" is timestamp-cursor polling under an explicit eventual-consistency model: pseudo-CDC.
- What a SaaS source can honestly ship, in order of completeness:
  1. Timestamp/cursor incremental polling - the practical default.
  2. Webhooks as a freshness supplement, never a backfill substitute - they capture nothing before the connection date.
  3. A vendor-side change/deletion feed - the real upgrade: implement internal CDC yourself and republish it as a stable, versioned API contract.
  4. Periodic full re-import as a reconciliation backstop for what polling structurally misses.
- Write customer-facing language as "incremental sync" with an eventual-consistency framing: state the poll interval and name what it misses - intra-interval overwrites, and hard deletes wherever no deletion feed exists. Ship the deletion feed when customers report missed deletes, not as a launch-day promise.
- Details, the platforms' own wording, and the substitute ladder live in [references/extraction-readiness-and-cdc.md](references/extraction-readiness-and-cdc.md).

## 6. Certification path

- Listing and certification are different bars everywhere:
  - **Listing** - passing the platform's test suite gets a connector listed.
  - **Certification** - optional, earned, and framed around reliability over feature count: "one solid connector is better than two finicky ones." Target it only after the connector holds up in real syncs.
- The certification-grade behaviors to build in from day one regardless:
  - Every supported sync mode integration-tested.
  - Incremental sync wherever the source allows it.
  - Failures that are fast and actionable - never a configuration the platform accepts but that is guaranteed to break.
- Enter a program with its clocks understood: platforms impose release-phase deadlines (e.g. a mandatory promotion window from private preview to beta) that turn a listing into a schedule commitment.
- Certification is paid for in engineering time, not fees: no platform charges a source vendor for the badge - and none pays for it either.
- Where a platform publishes quantitative bars (≥95% sync success, first-response SLAs, update cadence), adopt them as the connector's own SLOs even when the tier doesn't formally require them - they feed step 7's plan. Per-platform bars are in [references/platform-program-tables.md](references/platform-program-tables.md).

## 7. Maintenance plan

- Budget annual upkeep at 15-30% of the original build cost, reaching 50% in mature, high-change phases - vendor-published estimates, so treat them as an order of magnitude, not a quote. Each additional connector adds an independent recurring obligation; nothing amortizes across them.
- Plan against the four documented cost drivers:
  - Authentication changes.
  - Schema drift.
  - Rate-limit shifts.
  - Pricing/compliance overhead.
- Name the owner (interview answer 4) before launch. "A benevolent side-task" is the documented decay path - it is exactly how open-spec tap ecosystems rot (see Failure modes).
- Monitor breakage actively: alert on sync failures and schema-drift errors rather than waiting for customer tickets, because upstream APIs won't warn you (the 87.3% figure from step 4) and marketplace-tier listings carry no platform SLA.
- Justify the spend with support-deflection and retention math, never a revenue line. The documented payoff ranking: support-ticket deflection and retention > competitive-parity distribution > partner co-marketing programs > revenue share - the last essentially does not exist; do not plan around it (see [references/maintenance-and-revenue-economics.md](references/maintenance-and-revenue-economics.md)).

## Deliverable and validation

The output is a connector strategy document covering:

- Demand evidence.
- Platform and build-path decision, with the re-ranked menu shown.
- Extraction-readiness findings and their fix sequence.
- The CDC scoping language customers will see.
- The certification target and its clocks.
- The maintenance budget with a named owner.

Present it section by section and validate each with the user before writing the next. Gate the final document on explicit approval.

If your harness has persistent memory, store the chosen platform and path, the demand evidence, and the interview's re-ranking answers, so later tactical runs (building the connector, writing the listing) start from the decision instead of re-interviewing.

## Failure modes

- **A revenue-share line in the business case.** No platform pays source vendors; the one announced revenue-share model shipped as flat $10-150 per-task bounties. A plan that books connector income will be killed at its first finance review - rewrite the case on deflection and retention.
- **Overpromised CDC.** A "CDC support" checkbox implying log-based completeness fails customer data audits the first time a hard delete goes missing. Scope it as step 5 does, in writing, before marketing touches it.
- **Unmaintained-tap decay.** The open-spec ecosystem's history is the case study: taps of unknowable quality, multiple breaking upstream changes a year, maintainers gone once sponsor attention moved - an open standard solved initial coverage, never ongoing maintenance. Any custom-path plan without a month-13 owner is this failure scheduled in advance.
- **Extraction-hostile API under the connector.** A connector built on UI-grade CRUD pagination produces rate-limited backfills, missed deletes, and flaky incremental syncs - then fails the certification bar for reasons no connector code can fix. Step 4 runs before the build, not after the first support escalation.
- **Building on hypothesis.** A connector shipped without step 1 evidence serves nobody measurable and still bills its 15-30% every year.
- **Mistaking a listing for platform support.** Marketplace-tier connectors are explicitly outside platform support SLAs and may break without notice; only the certified/managed tiers carry the platform's commitment. Know which tier the chosen path lands in.

## Measurement

Gates - iterate the strategy until all pass:

- Demand gate: zero build approvals without named demand evidence attached to the decision; each claimed driver cites at least one verifiable artifact (ticket, lost-deal note, log analysis). Binary.
- Honesty gates: the business case contains no revenue-share income line, and no customer-facing claim says "CDC" without the incremental/eventual-consistency scoping. Binary, checked on the final document.
- Readiness gate: every resource in connector scope passes the extraction-readiness checklist or carries an explicit exclusion note - 100% coverage, no silent skips.

These gates are self-set from the documented record above, not an industry standard.

Trends to watch after launch, baselined from the first quarter:

- Connector-attributed support-ticket deflection.
- Sync success rate against the published ≥95% certification bar.
- The share of new customers connecting through the platform versus the raw API.

## Invocation examples

- "Customers keep asking when we'll be in their ETL platform's catalog - do we build the connector ourselves on the SDK or go through the platform's request program?"
- "Product wants 'CDC support' on our data-sync page - what can we honestly ship as an API-only SaaS, and how do we word it?"
- "Draft the business case for our source-connector investment - what pays for it if there's no revenue share?"

## References

- [references/platform-program-tables.md](references/platform-program-tables.md) - named platform programs, build paths, review gates, release-phase clocks, and support-tier taxonomies (dated snapshot).
- [references/maintenance-and-revenue-economics.md](references/maintenance-and-revenue-economics.md) - build-cost baselines, the maintenance-tax figures and drivers, who absorbs the tax per path, and the revenue-share/co-marketing reality.
- [references/extraction-readiness-and-cdc.md](references/extraction-readiness-and-cdc.md) - the full extraction-friendly API checklist and the honest-CDC substitute ladder with the platforms' own wording.

See also, same collection:

- `samber/developer-platform-skills@api-integration-surface-strategy` - the umbrella choice of which integration surfaces to offer at all; this skill runs after ETL-platform presence is chosen as a surface.
- `samber/developer-platform-skills@connector-marketplace-strategy` - the opposite direction: third parties building connectors into _your_ marketplace; this skill is you building into someone else's catalog.
- `samber/developer-platform-skills@bulk-data-sharing-design` - direct-to-storage file delivery when the demand is "data files in my lake", not "rows synced through my ELT tool".
- `samber/developer-platform-skills@sql-jdbc-access-design` - live SQL/JDBC query endpoints when the demand is interactive querying, not pipeline sync.
- `samber/developer-platform-skills@api-versioning-policy` - the versioning and sunset discipline step 4 demands of the source API.
- `samber/developer-platform-skills@webhook-platform-design` - the webhook surface step 5 uses as a freshness supplement, and the webhook-vs-polling extraction trade-offs.