Blueprint Advanced

Build a Marketplace with AI

The full path to a two-sided platform — define the buyer-and-seller requirements, model the data, design the API, build roles and permissions, wire integrations, design the UI, then test, secure, and ship it.

Overview

A marketplace is two products in a trench coat: a seller experience and a buyer experience, joined by listings, permissions, and the integrations that move money and messages between strangers who don't trust each other yet. That two-sidedness is what separates it from a SaaS app, a CRM, or an internal tool — and it's where the hard decisions live. This blueprint builds it in the order those decisions demand: pin the requirements for both sides, model the data that ties buyers, sellers, and listings together, design the API, build the roles and permissions that keep each side in its lane, wire the third-party integrations, design the UI components both sides share, and ship. It owns the marketplace outcome specifically — not a CRM (internal sales data), not an internal tool (one audience), not a generic SaaS MVP — so every stage serves a platform with two audiences and the trust boundaries between them. Each stage is a NewPrompt playbook you can run on its own; together they carry a marketplace from concept to a platform real buyers and sellers can use. You own the marketplace model and the code; the blueprint keeps the two-sided decisions in the right order.

The journey

Each stage runs a NewPrompt playbook, with a supporting resource and tool. Work them in order — the output of each stage feeds the next.

  1. Define the two-sided requirements

    Pin what both sides need — sellers listing and managing, buyers discovering and transacting — and the rules that govern their interaction. A marketplace built from one side's requirements fails the other.

    Outcome Requirements covering buyers, sellers, listings, and their rules.

  2. Model the marketplace data

    Design the schema that ties users, listings, and orders together — the relationships and constraints a two-sided platform lives on — and the indexes the search and discovery queries will actually need.

    Outcome A data model connecting buyers, sellers, listings, and orders.

  3. Design the API

    Design the API surface both sides build against — listings, search, orders, messaging — as a contract before code, so the seller tools and buyer experience develop against something stable.

    Outcome An API contract for listings, search, and orders.

  4. Build roles and permissions

    Design the access control that keeps each side in its lane — buyer, seller, admin — so a seller can't touch another's listings and a buyer can't reach the admin panel. On a marketplace, permissions are the trust model.

    Outcome Roles and permissions that enforce the trust boundaries.

  5. Wire the integrations

    Connect the third parties a marketplace runs on — payments, notifications, shipping or messaging — via webhooks and events, with the retries and idempotency that keep a payment or order event from being lost or double-processed.

    Outcome Third-party integrations wired with reliable event handling.

  6. Design the UI components

    Design the reusable component system both sides share — listings, dashboards, search, checkout — so the seller and buyer experiences stay consistent instead of diverging into two mismatched products.

    Outcome A shared component system for both sides of the platform.

  7. Lock behavior down with tests

    A marketplace moves money and listings between strangers — build a test suite that fails for real reasons across the order, payment, and permission paths, so you can keep shipping without breaking a transaction someone depends on.

    Outcome Tests that catch real regressions in the money and permission paths.

  8. Run a security review

    A marketplace handles money, personal data, and two distrusting sides — review the auth, payment, and input paths the way an attacker would, and back the findings with tests, before real users and real transactions arrive.

    Outcome The money, auth, and data paths reviewed for vulnerabilities and guarded by tests.

  9. Ship the marketplace

    Cross from built to live — readiness checked, rollback planned, monitoring in place — because launching a platform that handles other people's money and listings is exactly where a careful release earns its keep.

    Outcome The marketplace shipped with a rollback path and monitoring.

Expected outcome

A marketplace platform built on its two-sided reality — requirements for both audiences, a data model tying buyers, sellers, and listings together, an API, roles and permissions that hold the trust boundaries, integrations, a shared UI component system, and the whole thing shipped — a real platform, not a single-audience app with a marketplace label.

Recommended playbooks

Playbook · Operations Workflows AI Product Requirements Workflow Turn a fuzzy business need into requirements a team can build from — interrogate the need into concrete requirements, shape them as user stories, and write the PRD. View Playbook → Playbook · Coding Workflows AI Database Design Workflow Design a schema on its data, not a hunch — model the entities and relationships, set the constraints that protect integrity, plan indexes around real queries, then document the schema and migration. View Playbook → Playbook · Coding Workflows AI API Design Workflow Design an API on its contract instead of discovering it endpoint by endpoint — model the resources, design the endpoints and payloads, pin the contract, then review it before code locks it in. View Playbook → Playbook · Coding Workflows AI Auth & Identity Workflow Design access control before you build it, not after a breach — choose the authentication approach, model the roles and permissions, review the design for gaps, then document the identity model. View Playbook → Playbook · Coding Workflows AI Integration & Webhook Workflow Connect systems so they don't break each other — map the integration boundaries, design the event and webhook contracts, plan retries and failure handling, then document the integration. View Playbook → Playbook · Operations Workflows AI UI & Component Design Workflow Structure a UI so it stays consistent as it grows — inventory the screens, break them into reusable components, specify the component system and its rules, then review the structure for drift. View Playbook → Playbook · Coding Workflows AI Test Generation Workflow Build a test suite that fails for real reasons, not green decoration — coverage across unit, integration, and edge cases, then a review for the gaps. View Playbook → Playbook · Coding Workflows AI Security Review Workflow Review code for what an attacker would do, not just what tests catch — anchor the model as a security engineer, run a threat-focused review, then back the findings with auth and input tests. View Playbook → Playbook · Coding Workflows AI Deployment & Release Workflow Cross the gap between 'tests pass' and 'safe in production' — assess release readiness, plan the deploy and its rollback, and set up the monitoring and launch checks before you ship, not after. View Playbook →

Supporting resources

Recommended tools

Recommended next blueprint

Build this next Build an AI Support Agent with AI The full path to a support agent you can put in front of customers — write its instructions, ground it in your docs, route and handle tickets, then evaluate and cost-control it before it goes live. Open Blueprint

Related blueprints

Tip: Each stage opens its playbook — work them in order and carry the output forward.

All blueprints