Alchemist Platform

Marketplace Seller Guide: Publish Recipes & Feature Packs

Everything a seller needs to package, price, publish, version, and support a Recipe or Feature Pack in the Alchemist Marketplace. Includes marketplace economics, the configurable platform fee, seller payout, and a worked example.

|View as Markdown
Hunter Hodnett
Hunter HodnettCPTO at Chipp
|1 min read
#alchemist#marketplace#seller#recipes#feature-packs#publishing#economics

The Alchemist Marketplace is open to verified third-party sellers. If you have built a reusable capability — a Feature Pack, a full Recipe, or a thematic bundle — you can publish it, set your price, and earn a seller payout on each purchase.

Getting Started: Seller Onboarding

To sell on the Marketplace:

  1. Apply for a seller account — from the Marketplace browse view, click “Sell a Recipe” in the sidebar. Complete the seller application with your identity, contact details, and intended listing categories.
  2. Complete identity verification — Chipp verifies your identity and establishes a payout account (via Stripe Connect). You cannot receive payouts until verification is complete.
  3. Review the seller agreement — covers licensing terms, content standards, security review expectations, and payout conditions.
  4. Once approved, your seller profile page becomes live and you can publish listings.
ℹ️

Seller profiles are public and linked from every listing you publish. Buyers see your display name, a short bio, published listing count, and your support-contact channel.

Packaging a Recipe or Feature Pack

Pack manifest

Every Feature Pack is defined by a manifest that declares:

  • packId — unique identifier (e.g. supply-chain-visibility)
  • name — human-readable display name
  • description — what the pack does and what it provides
  • version — semantic version of this pack release
  • dependencies — other pack IDs (and version ranges) this pack requires
  • configSchema — the configuration knobs buyers can set at install time
  • files — the source files the pack contributes
  • migrations — database migration scripts (if any)
  • agentGuidance — notes the Alchemist agent uses when working inside a project that has this pack installed

Pack manifests are validated by the platform at publish time. Undeclared dependencies, missing required fields, or files that overwrite another pack’s protected files will fail validation with an actionable error message.

Recipe manifest

A Recipe manifest wraps one or more Feature Packs into a cohesive composition:

  • recipeKey — unique key (e.g. supply-chain-ops)
  • name and description — what the recipe builds
  • version — semantic version
  • packs — ordered list of pack IDs this recipe composes
  • configSchema — top-level knobs promoted from underlying packs
  • defaults — default values for knobs
  • workflows — named workflow templates bundled with this recipe
  • prompts — agent-prompt templates
  • assets — screenshots, demo links, and branding for the listing

Dependencies and version ranges

Declare dependencies conservatively. If your pack only works with specific versions of another pack, express that as a version range (e.g. >=1.0.0 <2.0.0). Overly narrow ranges block buyers from using your pack alongside newer dependencies; overly broad ranges may expose your pack to breaking changes.

Writing the Listing

When you publish a pack or recipe, you supply:

FieldRequiredNotes
Display nameYesShort, descriptive
Outcome descriptionYesPlain-language “what this builds” (max 500 chars)
Detailed descriptionYesMarkdown, shown on the listing detail page
Screenshots / demo URLRecommendedBuyers convert higher with visuals
ChangelogYes for updatesRequired for every version bump
Compatibility notesYesWhich pack versions and runtimes you have tested against
Support channelYesHow buyers with active Maintenance reach you
One-time priceYesIn USD cents; 0 for a free listing
Maintenance price (annual)OptionalLeave blank if you do not offer Maintenance
First-year Maintenance included?OptionalCheck if purchase price includes first-year Maintenance

Setting Prices

One-time license price

This is what buyers pay at purchase to receive the source code and perpetual use rights. You set this in your seller dashboard. There is no platform minimum or maximum, but Chipp may flag listings with prices that appear inconsistent with the declared content.

Maintenance subscription price

Maintenance is priced annually by the seller. You may include first-year Maintenance in the one-time price (common for premium listings) or price it separately. Buyers who cancel Maintenance keep their source and license.

Pricing recommendations

The seller dashboard includes an intelligent pricing recommendation based on:

  • The complexity of included Feature Packs (number, lines of code, migration count)
  • Comparable listings in the same use-case category
  • Historical conversion rates at different price points

Recommendations are advisory. You set your own price.

ℹ️

Free listings (price = $0) are fully supported. Sellers use free listings for open-source packs, promotional tiers, or community contributions. Free listings still go through the review process.

Marketplace Economics

Platform fee

Chipp charges a platform fee on each transaction. The fee is configurable and currently set at 30% of the gross purchase price (3000 basis points).

The fee is:

  • Applied at transaction time and snapshotted to the transaction record. A later fee change never retroactively alters a historical transaction.
  • Transparent: your seller dashboard shows the gross amount, the fee amount, and your net payout for every transaction.
  • Per-listing overridable: Chipp may negotiate a different fee rate for specific listings or programs (e.g. launch promotions, verified publisher programs). Any override is applied per-listing and documented on the transaction record.

Seller payout

Seller payout = gross purchase price - platform fee

At the default 30% fee: a 100listingpurchaseresultsina100 listing purchase results in a 30 platform fee and a $70 seller payout.

Payouts are disbursed on a rolling basis through Stripe Connect. The exact disbursement schedule depends on your Stripe Connect payout settings (typically daily or weekly rolling payouts to your connected bank account).

⚠️

The 30% figure is the current configurable default. Chipp may adjust the platform fee rate over time, with advance notice to sellers. Any adjustment applies only to transactions after the effective date; historical transactions retain their snapshotted fee. Review the seller agreement for current terms.

Maintenance revenue

Maintenance subscription renewals follow the same fee structure as the initial purchase. Your seller dashboard shows Maintenance renewal revenue separately from one-time license revenue.

Coupon and grant impact on payouts

When a buyer uses a coupon issued by Chipp (including 100%-off alpha grants), the fee calculation is applied to the post-discount amount. For 100%-off grants, the gross amount is $0 and neither Chipp nor the seller receives payment — but the buyer receives a full license and optional Maintenance as configured in the grant. Chipp may separately compensate sellers for grant-covered transactions under program agreements.

Versioning and Updates

Releasing a new version

To release a new version of an existing listing:

  1. Bump the version number in your pack/recipe manifest.
  2. Update the changelog with a human-readable description of changes.
  3. Mark breaking changes explicitly (files that buyers who have modified the pack’s source will need AI reconciliation to adopt).
  4. Submit for review.

Existing buyers see the new version in their project’s Marketplace tab only if they have an active Maintenance subscription (or if the update is a free patch within their licensed version range, as declared in your compatibility notes).

Deprecating a listing

You can deprecate a listing from your seller dashboard. Deprecated listings:

  • Are no longer discoverable in browse/search.
  • Remain purchasable by buyers who have a direct link (for transition periods).
  • Do not affect existing licenses — buyers keep their perpetual rights and installed source.

To fully remove a listing from sale, set it to “unlisted.” This does not revoke any existing licenses.

Version branching and forks

If you need to maintain an older major version alongside a newer one (e.g. for buyers who cannot migrate), you can publish parallel listings at different version branches. Label them clearly in the display name and changelog.

Review and Security Requirements

Submission review

Every new listing and every version update goes through Chipp’s review process:

  • Manifest validation — dependency declarations, schema correctness, protected-file rules.
  • Static analysis — automated vulnerability and secret-scanning.
  • Dependency audit — third-party npm/deno packages checked against known CVE databases.
  • Human review — Chipp reviews migration scripts, agent-guidance notes, and listing content for correctness, safety, and policy compliance.

Review typically takes 1-3 business days for first submissions and 1 business day for updates to already-approved listings.

Security disclosures

If a vulnerability is discovered in your published pack:

  1. You will be notified by Chipp’s security team.
  2. You are expected to issue a patched version within a reasonable timeframe (severity-dependent; critical issues may require a faster response).
  3. Chipp may temporarily delist the affected version while the patch is in review.
  4. Buyers with active Maintenance are notified of the security issue and the availability of the patched version.

Content and licensing compliance

You may only publish packs you have the right to distribute. Your listing must not include:

  • Code from open-source projects whose licenses are incompatible with commercial redistribution (check your dependencies carefully).
  • Hardcoded secrets, API keys, or customer data of any kind.
  • Content that violates Chipp’s acceptable-use policy.

Worked Example: Supply-Chain Visibility Pack

The following is a representative example of how a seller might structure a domain-specific Feature Pack. All details are illustrative and contain no private customer data.

Pack: supply-chain-visibility

Imagine you have built an inventory-tracking and supplier-status dashboard used in your own projects. To turn it into a sellable pack:

Manifest excerpt:

json
{
  "packId": "supply-chain-visibility",
  "name": "Supply-Chain Visibility Dashboard",
  "version": "1.0.0",
  "description": "Real-time supplier status, inventory levels, and shipment tracking for e-commerce and manufacturing projects.",
  "dependencies": [
    { "packId": "commerce-catalog", "versionRange": ">=1.0.0 <2.0.0" },
    { "packId": "core-platform", "versionRange": ">=1.0.0" }
  ],
  "configSchema": [
    { "key": "defaultCurrency", "type": "string", "default": "USD", "label": "Default currency" },
    { "key": "lowStockThreshold", "type": "number", "default": 10, "label": "Low-stock alert threshold (units)" }
  ]
}

What the pack contributes:

  • A /admin/supply-chain route with a real-time dashboard (WebSocket-fed inventory updates, supplier status tiles, shipment ETA table).
  • A supply_chain_events Postgres table and a migration script to create it.
  • A Deno API route at /api/supply-chain/events (stream endpoint).
  • Agent guidance notes explaining the data model so the Alchemist agent can write queries and modifications correctly.

Pricing:

  • One-time license: $149
  • First-year Maintenance included, annual renewal: $49/year
  • At 30% platform fee: seller payout is 104.30onfirstpurchase,104.30 on first purchase, 34.30 on each annual renewal.

What sellers must NOT include in the manifest or source files:

  • Real supplier names, purchase orders, customer data, or any non-synthetic test fixtures.
  • Hardcoded API keys or credentials.
  • References to internal proprietary systems by their real names.

This supply-chain example is structural only — distinct supplier status entities, inventory tracking, shipment ETA — and exposes no private details from any real customer’s data.