Marketplace kit: buyer hire flow, seller workspace, and Stripe checkout you own

A two-sided services marketplace is not an appointments calendar and it is not a fitness member app. After you buy the Marketplace kit, you get a buyer path (browse, hire, Stripe checkout, orders, order chat, saved services) and a seller workspace (earnings, orders, service editor, revenue analytics, customers) in one product tree you own — plus agent configs so Cursor or Claude Code can extend that tree without inventing a second marketplace.

This post is that inventory. It is not the booking ownership tour at /blog/booking-kit-own-the-repo (slots, confirmations, double-book guards). It is not the fitness SKU walkthrough at /blog/fitness-kit-after-purchase (rings, workouts, goals). If your primary object is hire → pay → fulfill a service order with chat on both sides, stay here.

What the Marketplace kit actually ships

OTF lists the Marketplace kit (Aperture) on https://otf-kit.dev/templates/marketplace-kit and in the templates catalog. Standalone price is $99. The kit is also included in the Everything Bundle on https://otf-kit.dev/pricing. The storefront describes a dark-first, two-sided services product: buyer browse/hire/checkout/chat plus a full seller workspace, delivered as one codebase for phone and web, with typed API routes, Postgres schema/migrations/seed, and agent handoff files (CLAUDE.md, .cursorrules, tested prompts).

Public product claims that matter for buyers (from the live kit page — treat demo chrome as demo UI):

• Buyer path: home with featured listings, full-text discovery, service-detail pages, Stripe checkout, an orders tracker, order chat, and saved services
• Seller path: earnings overview, incoming orders, service editor, revenue analytics, and a customer list
• Account: email, Google, and one-tap demo sign-in, plus a profile with switchable accent themes
• Delivery: one product tree for iOS, Android, and web; commercial source after purchase
• Agent handoff: CLAUDE.md, .cursorrules, and tested prompts so the first session opens a map, not a blank interview

Purchase path matches other OTF kits: Stripe checkout, license email with a private GitHub invite, then clone and run locally. Inspect the storefront and sibling kit previews before you buy; do not invent a marketplace preview hostname that is not listed on the product page.

Buyer path: discovery, checkout, then orders and chat — owned in your repo.

Buyer hire flow: browse, pay, track, chat

Searchers who ask “what do I get on the buyer side?” want a concrete loop, not a feature list. The kit’s buyer loop is:

1. Discover — featured listings and full-text search surface services.
2. Decide — service-detail pages carry the hire decision (what is offered, what is paid).
3. Checkout — Stripe Checkout collects payment on a privileged path you control after purchase.
4. Fulfill — orders tracker plus order chat keep the job in-product instead of bouncing to email threads.
5. Return — saved services shorten the next hire.

That loop is the product. It is not a scheduling-link embed, and it is not a single-player fitness log. If you only need “pick a slot and get a calendar invite,” you are in the booking lane. If you need “hire a provider, pay, track the order, and message inside the app,” you are in this lane.

Stripe’s own Checkout docs describe the payment surface the kit wires toward: a Checkout Session that hosts (or embeds) the payment UI, then returns the customer to your confirmation flow. See Stripe Checkout and custom success / redirect behavior. The durable part after purchase is not the hosted payment chrome — it is that the order row, chat thread, and seller earnings live in schema and screens you keep editing.

Illustrative shape only (not a kit file dump — use the repo’s real checkout route after clone):

// illustrative — pattern only; wire to your kit’s Checkout Session create + webhook confirm
type HireCheckoutInput = {
  serviceId: string;
  buyerId: string;
  successUrl: string; // e.g. https://YOUR-PRODUCTION-DOMAIN/orders/success
  cancelUrl: string;  // e.g. https://YOUR-PRODUCTION-DOMAIN/services/:id
};

async function startHireCheckout(input: HireCheckoutInput) {
  // Server creates a Checkout Session, returns URL or client secret
  // Webhook confirms paid → order row → seller earnings update
  return { checkoutUrl: session.url }; // Stripe Checkout Session URL from your server
}

Keep money confirmation on the webhook path. UI can change under an agent; “paid” should not be a client-only claim.

Seller workspace: earnings, services, analytics

The seller side is why this SKU is two-sided instead of a catalog storefront with a fake “provider” tab. The live page names a complete provider surface: earnings overview, incoming orders, service editor, revenue analytics, and customers — one codebase for both roles.

Operationally that means:

• Catalog ownership — services are editable product records (title, offer, pricing presentation), not copy pasted into a Notion page beside the app.
• Order intake — sellers see work arrive where buyers already tracked it.
• Money visibility — earnings and revenue analytics sit next to the order list, so “what did we sell?” is a product screen, not a spreadsheet export you rebuild every Monday.
• Customer list — repeat hire paths stay inside the same app story as first-time discovery.

When an agent opens the repo, the failure mode to avoid is inventing a second seller admin (a Vite-only dashboard, a Google Sheet sync, a Slack bot that becomes the real order system). Point the agent at the shipped seller screens and the existing order/chat/checkout seams first. Bounded prompts beat “rebuild marketplace from scratch.”

Seller workspace and the owned-repo outcome after both sides ship from one kit.

How this differs from booking and fitness kits

Three OTF kits look adjacent in a catalog and diverge in the primary object:

Use booking-kit-own-the-repo when the appointment is the product. Use fitness-kit-after-purchase when the member wellness loop is the product. Use Marketplace when hire/fulfill and sell/measure share one tree.

Pricing: $99 per kit, or the $149 Everything Bundle when you want more than one full-stack product — see /blog/everything-bundle-vs-single-kit. Free MIT SDK pieces (@otfdashkit/ui and siblings) are the shared component layer; the paid Marketplace kit is the finished two-sided product plus agent configs.

Agent configs and a boring first session

Every kit ships with CLAUDE.md, .cursorrules, and tested prompts so Cursor, Claude Code, Lovable, or Bolt understand the codebase from the first prompt — that claim is on the Marketplace kit page itself. Treat those files as the continuity layer: each agent session starts fresh; the repo memory does not.

After the GitHub invite lands, keep the first hour boring on purpose (same purchase pattern as other kits: invite → clone → install → local run). Do not open with “rebuild a two-sided marketplace from zero.” Prefer a constrained handoff:

# illustrative first-boot shape — follow the kit README after clone
git clone YOUR_PRIVATE_MARKETPLACE_KIT_REPO_URL
cd marketplace-kit
# install + env + migrate/seed per README
# then open in Cursor or Claude Code

Read CLAUDE.md and the tested prompts. Then:
1) Keep buyer browse → detail → Stripe checkout → orders/chat in that order
2) Extend seller earnings/orders/services only where the kit already patterns them
3) Do not invent a second admin for sellers
4) Prefer existing screens over a parallel hire flow
5) Confirm paid orders on the webhook path, not only in UI state

That prompt works because the hard seams are already named on the storefront: listings, discovery, detail, checkout, orders, chat, seller workspace, service editor, analytics. You are reskinning and extending a services market, not interviewing the model about marketplace information architecture.

When to buy versus a blank scaffold or a rented storefront

Stay on a blank scaffold or a hosted marketplace SaaS when the primary object is a weekend spike, a vendor domain is acceptable, and you are not ready to keep orders and earnings in schema you migrate. Prefer the Marketplace kit when most of these flip true:

• Buyers discover services, hire, pay, track orders, and chat inside your app
• Sellers need earnings, order intake, service editing, and analytics in the same product
• Phone and web ship from one tree you keep editing
• Maintenance happens in Cursor or Claude Code on disk, with project memory versioned beside the code
• The live URL should serve your clone, not a chat project that resets continuity every billing cycle

Sandboxes remain useful for spikes. Buy the kit when hire, checkout, orders, chat, and seller metrics belong in a repository you keep — screens named, agent configs tested, first session extends instead of invents.

All kit sales are final; inspect the storefront before checkout. Sibling proof: saas.otf-kit.dev is a live SaaS Dashboard preview — do not invent a Marketplace preview hostname the product page does not list.

Own both sides, then keep editing

Ownership is operational: buyer hire and seller workspace share one repository; Stripe Checkout confirms money on a path you control; agent docs reload so the next tweak is a constrained edit, not a greenfield rebuild. If that matches, start on https://otf-kit.dev/templates/marketplace-kit, compare both sides to your PRD, and buy when the market belongs in source you keep.

Sources

• Marketplace kit product page: https://otf-kit.dev/templates/marketplace-kit
• Templates catalog: https://otf-kit.dev/templates
• Pricing (kits $99, Everything Bundle $149): https://otf-kit.dev/pricing
• Stripe Checkout: https://docs.stripe.com/payments/checkout
• Stripe Checkout custom success / redirect: https://docs.stripe.com/payments/checkout/custom-success-page