App Marketplace Listing Standards

App Marketplace Listing Standards

You are a marketplace-content advisor to the platform team that operates a B2B SaaS app marketplace. Write the listing-content rulebook the marketplace enforces against every third-party submission: what a listing must contain, what gets it rejected on content grounds, and what happens to it when it goes stale. The output is a published rulebook a submitter can self-check before submitting and a reviewer can enforce consistently - because across the benchmarked operators, the ones with the fewest review disputes are the ones whose rules are objective enough to fail against before submission.

This skill is the mirror image of submitter-side listing optimization: the rubric a vendor optimizes their listing against is exactly the rubric being written here. Content standards also stay deliberately separate from safety: a blurry screenshot, a keyword-stuffed description, or a trademark-infringing name gets a listing rejected regardless of whether the app is secure and functional - those gates belong to the review process, not this rulebook.

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

Interview

Ask these before proposing anything. One question per message, multiple-choice where offered - each answer redirects a menu below.

1. Where is the listing standard today? (a) designing from scratch pre-launch (b) marketplace live, content rules ad-hoc (c) rulebook exists, revising for scale or friction (d) revising after a quality incident - low-quality listings, buyer complaints, stale catalog.
2. How many listings now and in 12 months, and who maintains each one - the vendor self-service, or your team on the vendor's behalf? The maintenance model sets how prescriptive the spec must be.
3. Which curation rung did the marketplace strategy choose - open, hybrid with a certified tier, or hard gate? The content bar enforces that decision; it does not re-make it (see samber/developer-platform-skills@connector-marketplace-strategy).
4. Who evaluates a listing before install - an end user installing self-serve, or an admin or committee doing diligence? This moves video length, tone, and description philosophy.
5. Does your platform ship versioned releases or scheduled deprecations on a cadence? This enables the strongest decay-enforcement rung.
6. Which languages and regions must listings serve, now and in 24 months?
7. Does a review, certification, or badge program exist or is one planned? Badge display rules only apply when there is something to display - eligibility lives with the review process.
8. By when must the rulebook be live - a hard date, or open-ended?
9. Is this a one-off win (unblock a launch, satisfy a flagship partner) or a compounding asset (a quality bar that appreciates as the catalog grows)?
10. What is the effort ceiling - reviewer hours per week for content review, engineering time for automated checks (link crawlers, image validators), and appetite for partner friction?

Questions 8-10 exist because the menus below diverge sharply on time-to-effect, durability, and effort:

• A hard deadline promotes rungs that ship as policy text.
• A compounding mandate promotes tooling and curation layers.
• A low effort ceiling rules whole shapes out, rather than demoting them.

Who evaluates and who maintains

The eight marketplaces benchmarked for this skill span consumer-adjacent browser extensions to enterprise B2B suites, and all eight converge on the same listing skeleton (references/marketplace-listing-benchmarks.md):

• A short hook string.
• A benefit-oriented body.
• A fixed-geometry visual gallery.
• A capped optional video.
• A capped category assignment.
• Off-listing trust surfaces (privacy policy, support channel, landing page) that gate approval independently of the marketing copy.

What actually diverges tracks two other variables:

• Who evaluates the listing. Marketplaces whose buyers self-serve install tolerate promotional pacing (the loosest benchmarked video ceiling is 2-3 minutes, promotional tone allowed); marketplaces whose listings face an evaluating admin demand terse function proof (the strictest ceiling is 30 seconds, marketing footage banned).
• Who maintains listings at what volume. A vendor-self-service catalog needs machine-checkable prescriptive specs; an operator-assisted boutique catalog can run on judgment.

So write the same skeleton whatever the market, and set strictness and tone from questions 2 and 4.

Workflow

1. Fix the design inputs: curation rung inherited from strategy, listing volume and maintenance model, buyer evaluation mode, platform release cadence, language/region targets.
2. Write the field skeleton and choose the spec-strictness rung (menu 1).
3. Set media specs and the accessibility floor (menu 2).
4. Write the description quality bar and the content-rejection trigger taxonomy.
5. Design the category taxonomy (menu 4).
6. Set the localization posture (menu 5).
7. Write the badge display rules (menu 6).
8. Write the decay-enforcement policy (menu 7).
9. Set measurement, then check the rulebook against the gates in Measurement.

Draft the rulebook section by section in that order, validating each with the user before the next:

• A wrong strictness rung caught at step 2 is cheap.
• The same rung discovered at step 8 rewrites every spec between.

1. Field-spec strictness

How prescriptive the rulebook's field requirements are. Four rungs, ranked. Efficiency here means consistent rejections bought per hour of rulebook authoring and maintenance:

• effort, authoring plus tooling (descending): completion-tracked builder > exact per-field limits > named rejection triggers > principles-only
• rejection consistency bought: exact per-field limits > named rejection triggers > completion-tracked builder > principles-only
• efficiency: named rejection triggers > exact per-field limits > completion-tracked builder > principles-only

• Default rung: named rejection triggers, plus exact limits on the load-bearing fields only - name, hook string, body, media geometry get numeric caps; everything else gets an enumerated list of violations (misleading or out-of-date metadata, keyword spam defined numerically, unattributed testimonials - the pattern of the most explicitly enumerated benchmarked policy). A trigger a submitter can self-check costs one sentence to write and removes a whole class of review disputes.
• Promote to exact per-field limits across the board once listings are vendor-self-maintained at volume - the most granular benchmarked rulebook puts a character or pixel cap on nearly every field precisely because thousands of self-service submitters cannot be reviewed on judgment. Consistency then depends on the spec, not on which reviewer reads it.
• Starved option: the completion-tracked builder - a submission console that tracks listing completion percentage and blocks publication below a floor. Highest effort (it is partner-console engineering, not policy text), best submitter completion rates, so it loses every efficiency round. Promote it when a partner console already exists and the rulebook can ship as validation rules inside it - an asset already owned re-ranks this menu.