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

> After you buy the Marketplace kit: buyer browse/hire/Stripe/orders/chat plus seller earnings, services, and analytics in one owned repo.
> By Dave · 2026-09-18
> Source: https://otf-kit.dev/blog/marketplace-kit-two-sided-stripe

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](/blog/booking-kit-own-the-repo) (slots, confirmations, double-book guards). It is not the fitness SKU walkthrough at [/blog/fitness-kit-after-purchase](/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](https://otf-kit.dev/templates/marketplace-kit) and in the [templates catalog](https://otf-kit.dev/templates). Standalone price is $99. The kit is also included in the Everything Bundle on [https://otf-kit.dev/pricing](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 hire flow: browse, pay, then order chat as three icon steps](https://cdn.otf-kit.dev/blog/marketplace-kit-two-sided-stripe/inbody-01-hire-20260918d.png)

*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](https://docs.stripe.com/payments/checkout) and [custom success / redirect behavior](https://docs.stripe.com/payments/checkout/custom-success-page). 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):

```ts
// 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 panels for earnings, orders, and analytics beside an owned repo crate](https://cdn.otf-kit.dev/blog/marketplace-kit-two-sided-stripe/inbody-02-seller-20260918d.png)

*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:

| Kit lane | Primary object | Buyer-ish path | Provider-ish path |
| --- | --- | --- | --- |
| Marketplace | Service hire + order | Browse → hire → Stripe → orders/chat | Earnings, services, analytics, customers |
| Booking | Appointment slot | Discover → book → confirm | Hours / time off, no-double-book |
| Fitness | Member workouts / progress | Rings, logs, goals, profile | N/A as a two-sided hire market |

Use [booking-kit-own-the-repo](/blog/booking-kit-own-the-repo) when the appointment is the product. Use [fitness-kit-after-purchase](/blog/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](/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:

```bash
# 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
```

```text
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](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](https://otf-kit.dev/templates/marketplace-kit)
- Templates catalog: [https://otf-kit.dev/templates](https://otf-kit.dev/templates)
- Pricing (kits $99, Everything Bundle $149): [https://otf-kit.dev/pricing](https://otf-kit.dev/pricing)
- Stripe Checkout: [https://docs.stripe.com/payments/checkout](https://docs.stripe.com/payments/checkout)
- Stripe Checkout custom success / redirect: [https://docs.stripe.com/payments/checkout/custom-success-page](https://docs.stripe.com/payments/checkout/custom-success-page)