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:
- Discover — featured listings and full-text search surface services.
- Decide — service-detail pages carry the hire decision (what is offered, what is paid).
- Checkout — Stripe Checkout collects payment on a privileged path you control after purchase.
- Fulfill — orders tracker plus order chat keep the job in-product instead of bouncing to email threads.
- 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:
| 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 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
Top comments (0)