partner-app-onboarding

{
  "skill_name": "partner-app-onboarding",
  "evals": [
    {
      "id": 1,
      "prompt": "I run platform at Kettleworth, we do restaurant scheduling SaaS. We're opening an app marketplace next quarter. My VP wants every partner to fill out an application we review by hand - company details, use case, a reference customer - and then we'd slot them into Bronze/Silver/Gold based on that application, with Gold getting API access first and Bronze waiting. A decent developer gets a hello-world app running against our API in about two hours; our API only touches shift schedules, no payments, no PII beyond staff first names. We expect mostly indie devs and two-person shops. Sanity check this before I take it to eng?",
      "expected_output": "A pushback that replaces the manual application gate with self-service signup, justified by the two-hour time-to-first-working-app and the low data sensitivity, and that kills the graded entry ladder outright rather than resizing it.",
      "files": [],
      "expectations": [
        "Recommends self-service signup - a form plus a program-agreement checkbox with no human reviewer - as the entry gate, rejecting the manual application review",
        "Uses the roughly two-hour time to a first working app as an explicit reason the application gate is not justified here",
        "States that application-reviewed registration earns its cost only when build complexity runs to weeks-to-months or when data sensitivity requires knowing who is building before granting access",
        "Rejects the Bronze/Silver/Gold entry ladder outright rather than renaming, resizing, or simplifying it",
        "States that entry tiers gate nothing at most real partner programs and that partner tiers are earned post-launch on performance",
        "Routes the design of a post-launch tier ladder to samber/developer-platform-skills@connector-marketplace-strategy instead of designing it here",
        "Rejects giving any tier earlier API access than another: credentials and API access are granted to every partner at signup",
        "Treats a staged pre-launch ladder (Registered then Exploration then Build) as a documented exception justified by build complexity, not a pattern to copy",
        "Does not introduce a countersigned company-level agreement or a per-applicant admission decision into the entry path"
      ]
    },
    {
      "id": 2,
      "prompt": "Northvale Systems - we sell field-service management software to utilities. We're designing our partner developer program from zero. Current plan on the whiteboard: partner signs up, we review the company over 2-4 business days, once approved we email them credentials and spin up a sandbox tenant, then they build, then they submit the app for our security review. Feels clean to me. Where would you push back?",
      "expected_output": "Identifies the sandbox-behind-the-review-gate failure, moves provisioning to signup, keeps human review at the submission gate, and interviews the user on build complexity and data sensitivity one question at a time before settling the gate.",
      "files": [],
      "expectations": [
        "Identifies gating sandbox and credential provisioning behind the partner-approval step as the central problem and names it as a recognized failure mode",
        "Recommends provisioning the dev account, sandbox tenancy, and credentials at signup, before any human review",
        "States the principle that starting to build is decoupled from getting approved",
        "Concentrates human review at the app-submission gate, where it protects end customers",
        "States that ungated build access is the shape most major B2B marketplaces use, not a risk-tolerant outlier",
        "Describes the cost of the current plan as partners churning silently in the gap between signup and the ability to test",
        "Asks how long a competent developer needs to reach a first working app on the platform, offering hours / days / weeks-to-months as the answer set",
        "Asks how sensitive the data partner apps touch is, in regulatory-exposure or customer-trust terms",
        "Asks at most one question per message rather than delivering a block of questions at once",
        "Defers review-pipeline and approval-checkpoint mechanics to samber/developer-platform-skills@app-marketplace-review instead of designing the review process here"
      ]
    },
    {
      "id": 3,
      "prompt": "Perrin Labs, B2B analytics platform. Marketplace has been live 14 months, 60-odd apps listed. Of the apps submitted last quarter, 22% failed review on the first pass - mostly OAuth scope misuse and missing data-deletion webhooks. Our head of ecosystem wants to make our 4-hour 'Building on Perrin' course mandatory: you can't click submit until you've passed the assessment. I've got budget to build the course properly this quarter. Draft the plan.",
      "expected_output": "Declines the submission-gating certification, cites the 22% rate as below the promotion threshold, sequences a pre-submission validator and a published review checklist ahead of any education mandate, and keeps education as an optional parallel track.",
      "files": [],
      "expectations": [
        "Declines to make the course a prerequisite for clicking submit",
        "States that the 22% first-review fail rate sits below the roughly 30-40% threshold at which mandatory education is even considered",
        "Recommends building a pre-submission validator - an automated check partners run before submitting - ahead of any education mandate",
        "States that mandatory pre-submission certification is not standard practice on any major B2B marketplace",
        "Recommends keeping education as an optional parallel track available from day one, required by nothing",
        "Locates quality enforcement at the review gate, with education positioned to help partners pass it faster",
        "Recommends publishing the review checklist inside the onboarding docs so requirements are not discovered at first rejection",
        "Offers a credentialed but still non-gating education path with named, displayable certificates as the upgrade when partner credibility is a buyer-facing signal",
        "States that promoting mandatory certification would additionally require failure analysis tracing failures to partner knowledge gaps rather than documentation gaps",
        "Flags that the cited failure causes (OAuth scope misuse, missing data-deletion webhooks) read as documentation or checklist gaps rather than a case for a four-hour course"
      ]
    },
    {
      "id": 4,
      "prompt": "Quick one. We're standing up dashboards for the partner program at Halmsted - workforce planning SaaS, marketplace went live 5 weeks ago. Exec wants a single north-star number and specifically asked me for 'time to first submitted app' plus the industry benchmark we should be measuring ourselves against. What's the benchmark, and what else belongs on that dashboard?",
      "expected_output": "Refuses to supply a benchmark number, explains that partner-funnel conversion data is not published, labels the metric self-defined, names the adjacent published metrics, and specifies the four-checkpoint funnel with a trend-based rather than absolute pass bar.",
      "files": [],
      "expectations": [
        "States that no published industry benchmark for time-to-first-submitted-app exists, because marketplaces keep partner-onboarding conversion numbers internal",
        "Declines to supply a numeric industry benchmark for time-to-first-submitted-app",
        "States that time-to-first-submitted-app is a self-defined metric and must be labelled as such wherever it is reported",
        "Names time-to-first-call - signup to first successful API call - as the established named metric sitting before it",
        "Names time-to-first-deal - partner-agreement signature to first registered opportunity - as the named partner-ecosystem metric sitting after it",
        "Specifies four funnel checkpoints: signup to provisioned, provisioned to first API call, first API call to first app submitted, and submission to approval",
        "Recommends baselining against the platform's own first quarter and tracking quarter-over-quarter conversion rather than setting an absolute pass bar",
        "Gives roughly 10 minutes as the working threshold above which provisioned-to-first-API-call means onboarding friction gets fixed before anything else",
        "Attributes the drop-off evidence behind that threshold to general developer-tool funnels rather than to marketplace-partner data"
      ]
    },
    {
      "id": 5,
      "prompt": "Here's our partner signup form as it stands at Colvers (B2B expense platform). Fields, in order: company name, tax ID, bank account for payouts, choose your pricing model (free / we bill / you bill), proposed list price, upload a W-9 or local equivalent, accept the reseller agreement, then a use-case description. We're seeing 70% abandonment on this form. Head of partnerships thinks we should cut the use-case description since it's the longest field to fill in. Thoughts?",
      "expected_output": "Rejects cutting the use-case field, moves every commercial and payout field out of registration to the launch/listing stage, and proposes the agreement-split shape where building stays ungated and only selling carries the agreement and identity checks.",
      "files": [],
      "expectations": [
        "Rejects cutting the use-case description as the fix and identifies the commercial and payout fields as the cause of abandonment",
        "Moves the pricing-model choice (free / platform-billed / vendor-billed) out of registration to the launch stage, as the last gate before listing",
        "Moves the proposed list price out of registration for the same reason",
        "Moves the reseller or seller agreement to first listing rather than registration",
        "Moves payout banking details and tax documentation (tax ID, W-9 or local equivalent) out of the registration path",
        "Recommends that registration carry only a click-through program agreement needing a single legal sign-off and no per-partner review",
        "Describes the agreement-split shape: building stays ungated for everyone, and a separate verified seller track carries the agreement signature plus KYC/KYB identity checks",
        "States that a partner forced to price an app they have not built answers randomly",
        "Ties any revenue-reporting obligation to first sale rather than to registration"
      ]
    },
    {
      "id": 6,
      "prompt": "Brindle - payments orchestration for marketplaces. We want partners building apps that move money between our customers' sub-accounts. Engineering's sandbox proposal: partners just use their own live Brindle account with a 'partner mode' flag on it. Zero infra for us to build, they can start in minutes, and if we later find we need something heavier we'll build proper sandboxes then. Deadline is tight and we have 6 partners already waiting. Go or no-go?",
      "expected_output": "A no-go on own-account-as-sandbox because the apps move money, with the option deleted rather than parked as a later fallback, instant dedicated dev tenancy recommended instead, provisioning still at signup despite the deadline, and isolation mechanics deferred to the sibling skill.",
      "files": [],
      "expectations": [
        "Returns a no-go on using the partner's own live account as the test environment",
        "Bases the no-go on partner apps touching money and irreversible actions, and on other tenants' data being reachable",
        "Instructs deleting the own-account-as-sandbox option outright rather than keeping it as a later fallback or a demoted rung",
        "Explains that an option ruled out by constraints but parked at the bottom of a menu silently reappears later as scope",
        "Recommends instant dedicated dev tenancy - a free dev instance or account created at signup, no time limit, no payment information required - as the rung to build",
        "Keeps provisioning at signup rather than deferring it because of the tight deadline",
        "Notes that production-mirror sandboxes are heavy enough that real platforms ration them, via quotas or by gating them behind a paid tier",
        "Defers test-key prefixing, magic test values, isolation architecture, and graduation-to-live mechanics to samber/developer-platform-skills@api-test-mode-design"
      ]
    },
    {
      "id": 7,
      "prompt": "Ostara Cloud, observability vendor. Our app directory has about 900 registered developers, of which roughly 40 are commercial ISVs that actually sell through us; the rest are individuals and small shops building private integrations for their own employers. Support today is a docs site plus a GitHub Discussions board and it's drowning - the same 12 questions over and over, mostly about our event-schema versioning and about what the review checklist actually wants. Finance approved 4 partner-manager hires. How do I allocate them?",
      "expected_output": "Allocates the named managers only to the 40 commercial ISVs, answers the repeated-question problem with real-time community chat and engineer-staffed office hours rather than headcount, and keeps docs plus forum as the base layer with an explicit efficiency ordering.",
      "files": [],
      "expectations": [
        "Assigns named partner managers only to the roughly 40 commercial ISVs, never to the roughly 860 individual developers",
        "Recommends real-time community chat as the response to the clustered repeated questions, rather than headcount",
        "Recommends office hours staffed by a platform engineer for the recurring hard steps - event-schema versioning and the review gate - that peers cannot answer",
        "Keeps the existing docs and community forum in place, layering new rungs on top rather than replacing them",
        "States explicitly that the support rungs stack and never substitute for one another",
        "Gives an explicit ordering of the support rungs on efficiency, leading with docs plus community forum",
        "States that answered forum threads compound, each one deflecting the next partner's ticket",
        "States that named partner managers scale only with headcount, which is why they lose on efficiency despite carrying the highest unblock power"
      ]
    },
    {
      "id": 8,
      "prompt": "We just had a partner blow up at us in our community Slack. Vessen, HR platform - our marketplace review won't even start until an app has 5 active installs on real customer workspaces, and our 'Vessen Certified' badge needs 6 months listed plus 60 active installs. This partner shipped, hit the install wall, and said we wasted three months of their engineering time. Two other partners have since said the same thing. What do we change?",
      "expected_output": "Frames this as a disclosure-timing failure rather than a threshold-existence one, moves both thresholds into the onboarding documentation, names the hidden-post-launch-wall pattern, and keeps certification non-gating for submission.",
      "files": [],
      "expectations": [
        "Identifies the problem as disclosure timing rather than the existence of the thresholds themselves",
        "Recommends disclosing the 5-active-install review-eligibility threshold inside the onboarding documentation",
        "Recommends disclosing the 6-month-plus-60-install certification thresholds inside the same onboarding documentation",
        "States the general rule that every post-launch threshold is disclosed at onboarding, never at the moment the partner hits it",
        "Names hidden post-launch walls as a recognized failure pattern that hits partners after they believe onboarding is complete",
        "Notes that both threshold shapes - an install count before review can start, and tenure plus install counts before certification - exist on real major B2B marketplaces",
        "Recommends naming the journey stages explicitly, including the post-launch stage, so the walls are visible from the entry docs",
        "Keeps certification non-gating for submission while still disclosing its post-launch eligibility bar upfront"
      ]
    }
  ],
  "trigger_queries": [
    {
      "query": "Design the onboarding journey for developers building apps on our platform, from signup through to first submitted app.",
      "should_trigger": true
    },
    {
      "query": "Should partner registration be an application we review, or just self-service signup?",
      "should_trigger": true
    },
    {
      "query": "When in the process do we hand partner developers a sandbox?",
      "should_trigger": true
    },
    {
      "query": "partners sign up and then nothing ever happens, where are they getting stuck",
      "should_trigger": true
    },
    {
      "query": "We're launching a developer program for our CRM platform next quarter. Where do I start?",
      "should_trigger": true
    },
    {
      "query": "Should we require a certification course before partners are allowed to submit an app?",
      "should_trigger": true
    },
    {
      "query": "What should I be measuring between a partner signing up and them shipping their first app?",
      "should_trigger": true
    },
    {
      "query": "Our ISVs keep telling us the getting-started experience is a maze. Fix it.",
      "should_trigger": true
    },
    {
      "query": "Do we need entry tiers for the partners building on our app platform?",
      "should_trigger": true
    },
    {
      "query": "how long should it take someone to go from 'I want to build on you' to 'I submitted something'",
      "should_trigger": true
    },
    {
      "query": "Write the plan for taking a third-party developer from zero to a live listing on our marketplace.",
      "should_trigger": true
    },
    {
      "query": "We ask for pricing and banking details on our partner signup form. Is that normal?",
      "should_trigger": true
    },
    {
      "query": "Draft the registration gate for our app ecosystem.",
      "should_trigger": true
    },
    {
      "query": "Should ISVs get a free dev instance automatically, or only after we approve them?",
      "should_trigger": true
    },
    {
      "query": "Set up the support channels for the people building integrations on top of us.",
      "should_trigger": true
    },
    {
      "query": "We have a 90% drop-off between partner account creation and their first API call. What's the plan?",
      "should_trigger": true
    },
    {
      "query": "map out the stages a technology partner goes through with us",
      "should_trigger": true
    },
    {
      "query": "We want to gate access until we've vetted the company properly. Good idea or not?",
      "should_trigger": true
    },
    {
      "query": "What does a good developer program entry path look like for a B2B SaaS?",
      "should_trigger": true
    },
    {
      "query": "The first thing anyone building on us sees is a 14-field form. Rethink it.",
      "should_trigger": true
    },
    {
      "query": "how do i shorten time to first submitted app",
      "should_trigger": true
    },
    {
      "query": "Our head of ecosystem wants Bronze/Silver/Gold assigned at signup. Push back or agree?",
      "should_trigger": true
    },
    {
      "query": "Need a plan for onboarding the 12 ISVs we recruited ahead of our marketplace launch.",
      "should_trigger": true
    },
    {
      "query": "Where should the human review actually sit in a partner program?",
      "should_trigger": true
    },
    {
      "query": "Partners keep hitting requirements they never knew existed until we reject them. What now?",
      "should_trigger": true
    },
    {
      "query": "Do we need partner managers, or is a forum enough for 800 developers?",
      "should_trigger": true
    },
    {
      "query": "audit our developer program entry funnel",
      "should_trigger": true
    },
    {
      "query": "We want people building on us within an hour of first hearing about us. What has to be true?",
      "should_trigger": true
    },
    {
      "query": "Design the path from partner signup to first app submission on our B2B platform.",
      "should_trigger": true
    },
    {
      "query": "when should we ask a partner how they plan to monetize their app",
      "should_trigger": true
    },
    {
      "query": "Our KYC checks are blocking developers who just want to experiment. Rework it.",
      "should_trigger": true
    },
    {
      "query": "Does sandbox access come before or after the partner agreement gets signed?",
      "should_trigger": true
    },
    {
      "query": "Design the review pipeline and approval checkpoints for third-party apps on our marketplace.",
      "should_trigger": false
    },
    {
      "query": "What exactly should our security review check before we approve a partner app?",
      "should_trigger": false
    },
    {
      "query": "How do we isolate our sandbox from production - a separate copy, or a test-mode flag on live data?",
      "should_trigger": false
    },
    {
      "query": "Pick our test-key prefix convention and the magic test card numbers we publish.",
      "should_trigger": false
    },
    {
      "query": "Write the listing content rules every app in our marketplace has to meet.",
      "should_trigger": false
    },
    {
      "query": "How many screenshots should a marketplace listing require, and at what resolution?",
      "should_trigger": false
    },
    {
      "query": "Should we be the merchant of record for apps sold through our marketplace?",
      "should_trigger": false
    },
    {
      "query": "What take rate should we charge on marketplace app sales, and how often do we pay out?",
      "should_trigger": false
    },
    {
      "query": "Should we build our own app marketplace at all, or just list on other people's?",
      "should_trigger": false
    },
    {
      "query": "Design our post-launch partner tier ladder and what each tier earns.",
      "should_trigger": false
    },
    {
      "query": "Plan the launch cohort and the keynote reveal for our new app marketplace.",
      "should_trigger": false
    },
    {
      "query": "How do we get our own app ranking higher on the Salesforce AppExchange?",
      "should_trigger": false
    },
    {
      "query": "Which technology partners should we integrate with first, and how deep should each go?",
      "should_trigger": false
    },
    {
      "query": "Design the information architecture of our developer portal.",
      "should_trigger": false
    },
    {
      "query": "Our docs site search is terrible. Restructure it.",
      "should_trigger": false
    },
    {
      "query": "Write the OAuth consent screen and scope taxonomy for third-party apps on our API.",
      "should_trigger": false
    },
    {
      "query": "Set our API rate limits per tier and pick which rate-limit headers we return.",
      "should_trigger": false
    },
    {
      "query": "Design our API key format, storage, and rotation policy.",
      "should_trigger": false
    },
    {
      "query": "How should we version our public API and communicate deprecations?",
      "should_trigger": false
    },
    {
      "query": "Build an error-code taxonomy for our public API.",
      "should_trigger": false
    },
    {
      "query": "Which SDK languages should we ship first, and generated or handwritten?",
      "should_trigger": false
    },
    {
      "query": "Design our outbound webhook retry, backoff, and dead-letter policy.",
      "should_trigger": false
    },
    {
      "query": "How do we show partners the delivery logs for their failed webhook calls?",
      "should_trigger": false
    },
    {
      "query": "Should we publish a GraphQL API alongside our REST one?",
      "should_trigger": false
    },
    {
      "query": "Write the job description and interview loop for a partner integration engineer.",
      "should_trigger": false
    },
    {
      "query": "I'm a backend engineer - how do I move into an API platform role?",
      "should_trigger": false
    },
    {
      "query": "Design the onboarding flow for new employees joining our platform team.",
      "should_trigger": false
    },
    {
      "query": "Write a user onboarding checklist for people starting our free trial.",
      "should_trigger": false
    },
    {
      "query": "How do we onboard a new enterprise customer in the 30 days after they sign?",
      "should_trigger": false
    },
    {
      "query": "Improve the activation rate of new end users in our SaaS product.",
      "should_trigger": false
    },
    {
      "query": "Our channel resellers need training on how to pitch and demo our product.",
      "should_trigger": false
    },
    {
      "query": "Design a bulk Parquet export for customers who want our data in their own warehouse.",
      "should_trigger": false
    }
  ]
}

# Funnel metrics and benchmarks for partner onboarding

These figures mix official documentation with third-party estimates that disagree with each other, and review timelines vary with queue volume - treat exact numbers as directional and re-verify against current official pages before citing them in a deliverable.

## The metric landscape: what has a name and what doesn't

- **Time-to-First-Call (TTFC) / Time-to-First-Hello-World (TTFHW)** - signup → first successful API call. The established DevRel first-touch metric:
  - Postman's then-Head of Developer Relations called it "the most important metric you'll need for a public API"
  - a developer-analytics vendor defines TTFHW as the time to reach "the minimal level of value from your API"

  Best-in-class benchmarks cited are seconds-to-minutes - two leading API companies under ~90 seconds (aspirational ceilings).

- **Time to first deal** - partner-agreement signature → first registered opportunity. The partner-ecosystem analog, aimed at revenue rather than apps. Forrester's named Partner Onboarding Framework (align, acclimate, activate, authorize - 2018 report) warns that a partner not actively selling within 90 days "most likely never will". Another partner-management vendor's framework similarly targets "first-deal acceleration".
- **Time-to-first-submitted-app** - signup → first app submitted for review. It sits in an unnamed gap between TTFC (technical first touch) and time-to-first-deal (commercial activation). A team adopting it is coining a metric, not citing one - label it self-defined in any report.

## The four-checkpoint funnel

Marketplaces keep their partner-funnel conversion numbers internal, so instrument your own:

1. signup → sandbox/credentials provisioned
2. provisioned → first API call (this is TTFC)
3. first API call → first app submitted
4. submission → approval

## Drop-off evidence

- The available drop-off figures come from **general developer-tool research, not marketplace-partner data**: one synthesis of developer-tool funnels reports 80-95% of visitors dropping off after clicking "Get Started," with 68% citing "too much setup time," and developers making a first API call within 10 minutes being 3-4x likelier to convert to paid.
- The second documented friction point is the **review gate**: a ~50% first-time security-review fail rate at the application-gated platform (its own estimate as relayed by third parties, at $999 per resubmission), and 2-3 rejection cycles before approval reported in another platform's developer community.
- **Post-launch eligibility walls** drive late attrition: a marketplace review requiring ≥5 active installs before it starts (threshold lowered from 10 in August 2025), and a certification requiring ≥6 months listed plus ≥60 active installs. Both hit partners after they believe onboarding is complete - disclose them upfront.

## Review-stage durations (the one well-documented funnel component)

The review gate dominates any realistic time-to-first-submitted-app-to-live once build time is added. First-submission figures across the five platforms studied:

| Platform archetype                     | Review duration                                                              | Fee                      |
| -------------------------------------- | ---------------------------------------------------------------------------- | ------------------------ |
| Fastest self-service commerce platform | 5-10 business days, often longer in practice                                 | none                     |
| CRM app marketplace                    | initial check ≤10 business days, whole process ≤60 days                      | $0                       |
| Enterprise collaboration marketplace   | 10-15 business days to approval; 5-10 just to start                          | none                     |
| Messaging-platform marketplace         | ~10 business days preliminary + up to ~10 weeks functional                   | none                     |
| Application-gated enterprise platform  | ~1-2 weeks verification + 3-4 weeks testing; 6-9 weeks end-to-end with queue | $999/attempt (paid apps) |

Range: roughly 1-2 weeks at the light end to ~2.5 months at the heavy end. The named platform behind each row, with its entry gate, provisioning and support shape, is in the platform-archetypes reference file linked from `SKILL.md`.

## Working thresholds

Self-set rather than industry pass-standards; treat as starting points to recalibrate against your own baselines:

- **TTFC above ~10 minutes** → fix onboarding friction (provisioning, credentials, quickstart) before investing anywhere else; the general-DevRel evidence puts the largest leak here.
- **First-review fail rate above ~30-40%** → build a pre-submission validator (an automated checker partners run before submitting) before considering heavier education mandates.
- **Time-to-first-submitted-app far exceeding review duration** → the bottleneck is docs and enablement, not the review team; spend there.
- Baseline every checkpoint against your own first quarter and track quarter-over-quarter conversion - measure the trend, not an absolute pass bar.

# Partner-onboarding archetypes: five sourced platforms

Partner-program structures churn frequently - one platform renamed its entire tier model in July 2024, another added identity verification in 2025 - so re-verify any specific against the platform's current official pages before citing it in a deliverable.

## Shopify - self-service, speed-first

- **Entry:** self-service signup form, no application gate, no fee or minimum revenue requirement. The program markets speed itself: "from idea to launch in days, not weeks."
- **Provisioning:** unlimited free development stores with no time limit, including a fake payment gateway for testing payment flows.
- **Education:** Shopify Academy is optional - a three-course App Development Fundamentals path ending in a Verified Skills assessment, positioned as merchant-facing credibility, never a submission prerequisite.
- **Support:** the heaviest onboarding-stage support of the self-service platforms studied - an official 35,000+-member partner Slack community, Partner Townhalls, a developers Discord, and a 100,000+-member forum.
- **Tiers:** "Registered" is a label assigned at signup, not a graded gate; real tiers are post-launch performance ladders.
- **Review stage:** 5-10 business days officially, but community threads describe 2-3 rejection cycles before approval, clustering on UI-standard compliance, GDPR webhook requirements, billing-API compliance, and broken support contacts.

## Atlassian - ungated instance, staged guide, split commercial track

- **Entry:** immediate, form-free provisioning - "No request forms needed here" - of a free cloud developer instance. Since a 2025 marketplace-security update, the program splits "Developers" (build freely, no agreement) from "Marketplace Partners" (commercial sellers, who sign an agreement and pass KYC/KYB identity verification).
- **Provisioning:** the free dev instance ships with working products (project tracker, wiki, service desk seats) at signup; the first-party app platform provides hosting and API auth, lowering the technical floor.
- **Education:** continuous, non-gating track; since late 2025 a free 45-minute platform-fundamentals certificate framed as a career credential, not a submission gate.
- **Stage model:** the official onboarding guide names four phases - **Plan, Build, Launch, Grow** - with enterprise-trust research placed in Plan and the monetization choice (Free / Paid-via-Atlassian / Paid-via-Vendor) placed at Launch, as the last gate before listing.
- **Tiers:** none at entry; partner-program levels are reviewed automatically each July and require at least one paid live app first.
- **Review stage:** 10-15 business days to approval, with 5-10 business days just to start review - among the heavier self-service gates studied.

## Slack - fastest first app, thinnest support, hidden pre-review wall

- **Entry:** zero forms before code - a four-command CLI sequence (install, login, create, run) puts a working app in the developer's own workspace, which doubles as the sandbox.
- **Provisioning:** the free Developer Program layers provisioned enterprise-grade sandboxes on top - quota'd (up to 10 per 30 days, 2 active, 6-month lifetime), with a card required for identity verification only.
- **Education:** no developer certification exists at any stage.
- **Support:** the thinnest of the five - docs and community channels, no partner-manager layer for individual developers.
- **Tiers:** none; Developer Program membership is a binary free enrollment.
- **Review stage:** preliminary review up to ~10 business days, then a functional review that can run up to ~10 weeks for new submissions. Timings have varied across doc versions. Since August 2025 the review requires ≥5 active-workspace installs before it can start (lowered from ≥10) - a documented pre-review eligibility wall partners hit after believing onboarding was complete.

## HubSpot - free entry, education loop, post-launch certification wall

- **Entry:** self-service developer-account signup, no payment information required at any point.
- **Provisioning:** free app test accounts (~90-day renewable) included; full production-mirror sandboxes gated behind a paid enterprise subscription.
- **Education:** the Academy's cyclical "Learn. Build. Certify. Repeat." loop - ongoing lessons, certifications, developer blog and newsletter - positioned as continuous enablement, not an entry checkbox.
- **Support:** named Partner Development Managers for commercial/solutions partners, plus a developer Slack community, forums, and docs.
- **Tiers:** four technology-partner tiers, all post-launch - a developer holds no tier until their app is approved and live; tiers upgrade quarterly on trailing-12-month performance.
- **Review stage:** initial check within 10 business days, whole process capped at 60 days, $0 fee. App certification, however, opens only after ≥6 months listed and ≥60 active unaffiliated installs - a post-launch wall, not a submission prerequisite.

## Salesforce - the application-gated outlier

- **Entry:** registration itself is a reviewed gate - an application to the partner community with a days-long review, and a company-level Partner Program Agreement that blocks every user at the company until an authorized agent accepts it.
- **Provisioning:** post-acceptance, a free Partner Business Org is auto-provisioned with license-management and revenue-reporting tooling; partners then create dev, test, and demo orgs from an environment hub - a genuinely complex multi-org model.
- **Stage model:** a seven-milestone official onboarding guide, and the one true pre-launch stage ladder studied. Registered → Exploration → Build precede listing, while Select and Summit are post-launch (platform-documented). The ladder replaced a score-based tier model in July 2024 - program churn is frequent, re-verify.
- **Education:** continuous and non-gating (gamified learning trails, partner learning camp); role certifications are career credentials, not listing prerequisites.
- **Support:** the richest studied - dedicated partner support, Partner Account Managers for qualifying partners, biweekly office hours, onboarding Q&A groups, and case-based security-review office hours.
- **Review stage:** the mandatory security review is the hard gate - $999 per submission attempt for paid apps ($0 free), roughly 1-2 weeks initial verification plus 3-4 weeks testing, 6-9 weeks end-to-end with queue time, and a ~50% first-time fail rate per Salesforce's own estimate as relayed by third parties, not an official published figure. Budget guidance from the same research: 2-3+ months from build to listing once realistic resubmission is included.

## Cross-platform synthesis

- Four of five programs have **no entry gate beyond a form** and **no entry tier that gates anything**; Salesforce's application gate and pre-launch stages are justified by weeks-to-months build complexity, not a norm.
- All five provision **build access before any human review**; review effort concentrates at the submission gate.
- All five keep **education non-gating**; certification is a credibility signal or a post-launch quality badge, never a submission prerequisite.
- Support depth tracks partner commercial value, not partner count: named managers appear only for commercial partners.
- Friction concentrates at two points - before the first API call, and at the review gate - see the funnel reference file.

---
name: partner-app-onboarding
description: Design the partner-developer onboarding journey on a B2B SaaS platform - from partner signup through dev-account and sandbox provisioning, docs, education and certification posture, and support channels, to the first submitted app. Use whenever the user mentions partner developer onboarding, developer program entry, self-service vs application-gated registration, sandbox tenancy for partners, certification gating submission, partner support channels, or time-to-first-submitted-app - even if they never say "onboarding". Journey design only. Do NOT use for review-gate mechanics (samber/developer-platform-skills@app-marketplace-review) or sandbox isolation architecture (samber/developer-platform-skills@api-test-mode-design).
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.1"
---

# Partner App Onboarding

You are a platform-program designer. Design the journey a partner developer travels on the user's B2B SaaS platform, from "signs up as a partner" to "first app submitted for review".

The journey covers:

- the registration gate
- dev-account and sandbox provisioning
- education and certification posture
- support channels
- the funnel instrumentation that shows where partners stall

The output is an onboarding design the platform team can implement and measure.

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

## Interview

Ask before proposing anything. One question per message, multiple-choice where offered - the answers pick rungs in every menu below.

1. What do partners build? (a) marketplace apps (b) private integrations for shared customers (c) both.
2. What exists today? (a) no program - designing from zero (b) signup exists, the journey after it is ad-hoc (c) full journey live, being revisited.
3. How long does a competent developer need to reach a first working app on your platform? Hours / days / weeks-to-months. This is the strongest gate-selection signal.
4. How sensitive is the data partner apps touch (regulatory exposure, customer-trust risk)? High / medium / low.
5. Who are the partners? (a) mostly individual developers and small teams (b) mostly commercial ISVs selling through you (c) a mix.
6. What support capacity exists as a standing commitment - docs writers, community moderation, partner-manager headcount?
7. By when must the journey be live - a hard date, or open-ended?
8. Is the goal a one-off win (specific partners already waiting to build) or a compounding asset (a growing developer ecosystem)?
9. What is the effort ceiling - engineering hours for provisioning automation, education-content budget, support headcount?

Questions 7-9 re-rank the menus below:

- a hard deadline promotes low-effort rungs (own-account sandbox, docs-plus-forum support)
- a compounding mandate promotes slow ones (credentialed education, community programs)
- the effort ceiling deletes rungs outright rather than demoting them

## Workflow

1. Map the journey stages and pick a stage model.
2. Choose the entry gate.
3. Design provisioning - sandbox tenancy and credentials.
4. Set the education and certification posture.
5. Build the support-channel ladder.
6. Sequence the commercial decisions late.
7. Instrument the funnel.

Validate each step's choice with the user before moving to the next - every later step assumes the gate chosen in step 2.

## 1. Map the journey

Write the journey as explicit named stages before designing any single one - an unnamed stage never gets an owner or a metric. Two citable models exist, both platform-documented:

- Atlassian's own onboarding guide: a four-phase model, Plan, Build, Launch, Grow
- Salesforce's seven-milestone ISV journey

Adopt, adapt, or replace them, but name the stages.

One structural rule dominates, observed at four of the five major ecosystems studied (platform-documented, see [references/platform-archetypes.md](references/platform-archetypes.md)): decouple "start building" from "get approved." Accounts, sandboxes, and credentials provision instantly and free. Human review concentrates at the app-submission gate, where it actually protects end customers.

## 2. Entry gate

Three rungs, ranked:

- effort (descending): `application-reviewed registration > agreement-split entry > self-service signup`
- trust and control (descending): `application-reviewed registration > agreement-split entry > self-service signup`
- compliance cost (descending): `application-reviewed registration > agreement-split entry > self-service signup`
  - a reviewed gate needs a countersigned company-level agreement and a documented admission decision per applicant, and unwinding an admitted partner is a contract termination
  - the seller track adds KYC/KYB identity data, so privacy and data-residency review applies, but only for partners who opt into selling and only reversibly
  - a click-through program agreement needs one legal sign-off, then none per partner
- efficiency: `self-service signup > agreement-split entry > application-reviewed registration`

- **Default rung: self-service signup.** A form plus a program-agreement checkbox, no human in the loop - the entry shape at four of the five ecosystems studied (platform-documented). Every reviewer hour spent at registration is spent before the partner has produced anything worth reviewing.
- **Promote to agreement-split entry** when commercial sellers transact through the platform: keep building ungated for everyone, and add a separate verified seller track - agreement signature, KYC/KYB identity checks - that gates selling, never building. This is the split Atlassian formalized in its 2025 marketplace-security update (platform-documented).
- **Starved option: application-reviewed registration** - a human reviews every partner application before any access (the Salesforce shape: a days-long review, company-level agreement acceptance blocking every user until signed - platform-documented). Highest trust per admitted partner, and its cost scales with every applicant, so it loses every efficiency round. It gets promoted anyway when either applies:
  - question 3 answers weeks-to-months: the environment model is complex enough that unguided partners fail, so guided pre-launch stages earn their overhead
  - question 4's answer means you must know who is building before granting any data access

Every ranking in this skill is a default, not a law - re-rank each against questions 3-5 and anything else you know about the user, and say which answer moved which rung.

Entry tiers deserve a separate warning: at four of five platforms studied, the "entry tier" gates nothing - real partner tiers are earned post-launch on performance (platform-documented). Ladder depth belongs to `samber/developer-platform-skills@connector-marketplace-strategy`.

Don't invent a graded entry ladder. Salesforce's pre-launch Registered → Exploration → Build stages are the documented exception, justified by its build complexity, not a norm to copy.

## 3. Provisioning

Grant sandbox tenancy and credentials at signup, not after review. Three rungs, ranked:

- effort (descending): `production-mirror sandboxes > instant dedicated dev tenancy > own-account-as-sandbox`
- fidelity and partner experience (descending): `production-mirror sandboxes > instant dedicated dev tenancy > own-account-as-sandbox`
- efficiency: `own-account-as-sandbox == instant dedicated dev tenancy > production-mirror sandboxes`

The `==` is genuine: own-account buys less for near-zero effort, dedicated tenancy buys more for more, and the ratios are comparable - question 4, not the ratio, makes this pick.

- **Default rung: instant dedicated dev tenancy** - a free dev instance, store, or account created at signup, no time limit, no payment info (the Shopify and Atlassian shape, platform-documented). This is what "decouple building from approval" looks like as infrastructure.
- **Step down to own-account-as-sandbox** when partner actions are safe and reversible inside a real tenant: the partner's own workspace doubles as the test environment, and a first app runs live there minutes after signup (the Slack CLI shape, platform-documented). Near-zero platform effort. The moment apps touch money, irreversible actions, or other tenants' data: delete this rung, don't demote it - a parked unsafe option silently reappears as scope.
- **Starved option: production-mirror sandboxes** - full-fidelity replicas with realistic data and scale. Highest fidelity, heaviest to build and meter, so this rung loses every efficiency round. The sourced platforms ration them (platform-documented):
  - Slack quotas its provisioned enterprise sandboxes
  - HubSpot gates production-mirror sandboxes behind a paid tier

  Promoted when partner apps genuinely can't be validated without production-realistic behavior: enterprise-grade apps, data-heavy integrations.

Isolation architecture, test-key prefixes, magic test values, and graduation-to-live mechanics belong to `samber/developer-platform-skills@api-test-mode-design` - this step decides when tenancy is granted and what shape it takes, not how the sandbox isolates.

## 4. Education and certification posture

Three rungs, ranked:

- effort (descending): `mandatory pre-submission certification > credentialed education loop > optional parallel track`
- first-submission quality (descending): `mandatory pre-submission certification > credentialed education loop > optional parallel track`
- efficiency: `optional parallel track > credentialed education loop > mandatory pre-submission certification`

- **Default rung: optional parallel track.** Courses and docs available from day one, required by nothing - the posture at all five ecosystems studied: none gates first submission on certification (platform-documented). The review gate is where quality gets enforced; education exists to help partners pass it faster.
- **Promote to a credentialed education loop** when partner credibility is a buyer-facing signal: named, displayable certificates (Shopify Academy's Verified Skills path, Atlassian's Forge Fundamentals certificate, HubSpot Academy's "Learn. Build. Certify. Repeat." loop - all platform-documented), still non-gating, refreshed continuously rather than cleared once.
- **Starved option: mandatory pre-submission certification.** Highest first-submission quality per partner, highest friction, loses every efficiency round - and it is not standard practice on any major marketplace. Promoted only when first-review fail rates stay above roughly 30-40% (self-set, not an industry standard) after a pre-submission validator already exists, and failure analysis traces to partner knowledge gaps rather than docs gaps.

Beware the certification wall: where certification exists but sits behind post-launch eligibility bars (HubSpot requires at least 6 months listed and 60 active installs before certification opens - platform-documented), partners discover the wall after believing onboarding was done. Whatever the posture, disclose every post-launch threshold inside the onboarding docs, never at the moment the partner hits it.

## 5. Support channels

These rungs stack - each layers on the previous, never replaces it.

- effort (descending): `named partner managers > office hours > real-time community chat > docs + community forum`
- unblock power (descending): `named partner managers > office hours > real-time community chat > docs + community forum`
- efficiency: `docs + community forum > real-time community chat > office hours > named partner managers`

- **Default rung: docs plus a self-serve community forum.** Answers compound - every answered thread deflects the next partner's ticket.
- **Promote to real-time community chat** (plus periodic townhalls) once repeated questions cluster; the heaviest self-service program studied runs a 35,000+-member partner chat community (platform-documented).
- **Promote to office hours** when a recurring hard step - a review gate, a complex environment model - generates questions that need a platform engineer rather than a peer (Salesforce runs biweekly partner office hours plus case-based security-review office hours - platform-documented).
  Design the program itself - slot, rotation, scope card - with samber/developer-relations-skills@developer-office-hours-program.
- **Starved option: named partner managers.** Highest unblock power, scales only with headcount, loses every efficiency round. Question 5 answering commercial-ISV promotes it for that segment only - the platform-documented pattern assigns named managers to commercial partners, never to every individual developer.

## 6. Sequence commercial decisions late

- Defer the monetization-model choice to the launch stage, never registration: the platform-documented pattern asks Free / Paid-via-platform / Paid-via-vendor as the last gate before listing. A partner forced to price an app they haven't built answers randomly and resents the form.
- Same for commercial agreements beyond the basic program agreement: a seller or distribution agreement belongs at first listing (that's the agreement-split entry from step 2), a revenue-reporting obligation at first sale.
- Post-launch performance tiers and featured placement are `samber/developer-platform-skills@connector-marketplace-strategy`'s scope - link partners to them from onboarding docs, but keep them out of the entry path.

## 7. Instrument the funnel

Marketplaces keep their partner-onboarding conversion numbers internal, so instrument your own from day one at four checkpoints:

1. signup → sandbox/credentials provisioned
2. provisioned → first API call
3. first API call → first app submitted
4. submission → approval

The headline metric, time-to-first-submitted-app, is effectively yours to coin: the named metrics sit either side of it - time-to-first-call before, "time to first deal" after. Flag it as self-defined wherever you report it. Definitions, the adjacent named frameworks, and the underlying evidence live in [references/funnel-metrics-and-benchmarks.md](references/funnel-metrics-and-benchmarks.md).

Working thresholds, each attributed in that reference file:

- Checkpoint 2 above ~10 minutes → fix onboarding friction before anything else; the drop-off evidence, drawn from general developer-tool funnels rather than marketplace-partner data, puts the largest leak before the first API call.
- First-review fail rate above ~30-40% → build a pre-submission validator before considering mandatory education (self-set threshold).
- Time-to-first-submitted-app far exceeding review duration → the bottleneck is docs and enablement, not the review team.

Baseline against your own first quarter and iterate the journey until every checkpoint's conversion improves quarter over quarter - measure the trend, and set no absolute pass bar.

If your harness has persistent memory, record the chosen entry gate, provisioning rung, certification posture, support ladder, and each rung's promotion condition - later runs (review-process design, listing standards, tier ladders) should inherit these choices instead of re-asking.

## Failure modes

- **Sandbox behind the review gate.** Partners approved to build but unable to test churn silently in the gap. Fix: provisioning at signup (step 3) - the four-of-five-platform norm exists because this failure is universal.
- **Graded entry ladder nobody needs.** Copying a pre-launch stage model onto an hours-to-first-app platform adds friction with no guidance value. Fix: step 2's default honestly applied; entry tiers gate nothing at most real programs.
- **Monetization asked at registration.** An upfront pricing form collects noise and scares off partners still exploring. Fix: step 6 - commercial decisions land at launch.
- **Hidden post-launch walls.** Install-count or tenure thresholds for review eligibility or certification (both platform-documented: a marketplace review requiring ≥5 active installs before it starts; certification requiring 6 months and 60 installs) hit partners after they think they're done. Fix: disclose every threshold in the onboarding docs.
- **Review-gate surprise.** Partners discover requirements at first rejection; developer-community threads at two studied platforms describe 2-3 rejection cycles, clustering on UI standards, data-privacy webhooks, and billing compliance (developer-community-reported). Fix: publish the review checklist inside onboarding docs and offer a pre-submission validator.
- **Certification as bouncer.** Gating submission on a course completes the funnel's leak, not the app's quality. Fix: step 4's default - enforce quality at review, teach in parallel.
- **Unmeasured funnel.** Without the four checkpoints, "partners sign up but nothing ships" has no diagnosis. Fix: step 7 before launch, not after the first stall.

## Invocation examples

- "We're launching a developer program for our CRM platform - design the journey from partner signup to first submitted app."
- "Partners sign up but never submit anything. Audit our onboarding: where are they stalling and what do we fix first?"
- "Should partner registration be application-reviewed like Salesforce or self-service like Shopify, and when do we provision sandbox tenancy?"

## References

- [references/platform-archetypes.md](references/platform-archetypes.md) - five onboarding archetypes: entry gate, provisioning, education, support, and review-stage shape per platform.
- [references/funnel-metrics-and-benchmarks.md](references/funnel-metrics-and-benchmarks.md) - metric definitions, adjacent named frameworks, review-stage durations, drop-off evidence, and thresholds.

See also, same collection:

- `samber/developer-platform-skills@app-marketplace-listing-standards` - listing content standards the partner meets at submission time.
- `samber/developer-platform-skills@app-marketplace-monetization-model` - the seller-agreement, fee, and payout mechanics behind the commercial decisions this journey sequences late.
- `samber/developer-platform-skills@developer-portal-design` - the docs and portal surface the whole journey runs through.
- `samber/developer-platform-skills@integration-partnership-strategy` - which partners to court in the first place, upstream of onboarding them.
- `samber/developer-platform-skills@app-marketplace-launch-marketing` - recruiting and promoting a founding cohort; this journey is what those recruited partners then walk, so a launch date sets the deadline the provisioning and support rungs here must meet.