Partner App Onboarding

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): 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.