Workflow
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.
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 project 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 connects to a NewPrompt workflow 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 project keeps the two-sided decisions in the right order.
The journey
Each stage runs a NewPrompt workflow, with a supporting resource and tool. Work them in order — the output of each stage feeds the next.
See the execution map →Define & Scope
Clarify what you're building and for whom.
-
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.
Design
Design the right solution before building.
-
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. -
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. -
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.
Build & Refine
Build, test, secure, and make it production-ready.
-
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. -
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. -
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. -
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.
Ship & Validate
Ship with confidence and validate results.
-
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. -
Validate the product with real evidence
A marketplace only works if both sides show up. Measure real liquidity — listings, matches, GMV — against the success signal you set, render a hit/partial/miss verdict, and decide whether to iterate, pivot, or scale before widening the funnel on either side.
Outcome The shipped outcome measured against its success signal, with an iterate, pivot, or scale decision documented.
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.
Best for
- Building a two-sided platform with buyers and sellers
- Modeling the relationships, roles, and permissions a marketplace needs
- The hardest commerce build — many actors, heavy integration
Not for
- A single-vendor store — that is the E-commerce Store project
- A simple catalog with one seller
FAQ
Store or marketplace?
Marketplace is two-sided: many sellers, many buyers, payouts, and trust between strangers. For your own single catalog, use the E-commerce Store project — it is a lighter build.
Why is this the heaviest project?
Because two-sided platforms compound complexity: buyer and seller requirements, roles and permissions, integrations, and a security review all interact. The journey orders them so they do not collapse on each other.
Do I need payments and payouts?
Typically yes — marketplaces move money between parties. The integration and security stages cover the stack that makes that safe.
How do I build a marketplace with AI?
You run it through the blueprint's ten stages in the order a two-sided platform demands: pin buyer-and-seller requirements, model the data tying users, listings, and orders together, design the API, build roles and permissions, wire integrations, design shared UI, then test, security-review, and ship. AI assists each stage; you own the marketplace model and code.
What should a marketplace MVP include?
At minimum, both sides working end to end: sellers can list and manage, buyers can discover and transact, and the roles and permissions keep each side in its lane. Skip nothing on the trust boundary. A marketplace where only one audience functions is not an MVP, it is a single-audience app with a label.
How do I validate supply and demand for a marketplace?
You measure real liquidity, not signups. The final validation stage tracks listings, matches, and GMV against a success signal you set, renders a hit, partial, or miss verdict, and drives an iterate, pivot, or scale decision before you widen the funnel on either side. A marketplace only works when both sides show up.
Workflows in this project
Workflow
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.
Workflow
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.
Workflow
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.
Workflow
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.
Workflow
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.
Workflow
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.
Workflow
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.
Workflow
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.
Workflow
AI Product Validation Workflow
Find out whether the thing you shipped actually worked — define the success metric, plan the measurement, classify the real evidence, then render a verdict and an iterate / pivot / scale decision.
Resources used in this project
Resource
Product Requirements Assistant
Turn a rough feature idea into a structured requirement: problem statement, acceptance criteria, and what's explicitly out of scope.
Resource
Missing Index Analysis — Which Indexes, at What Cost
Map every predicate, join, and sort to the index that serves it — or doesn't. Composite order rules, covering decisions, and the write tax nobody mentions.
Resource
API Review Checklist Prompt
Architecture review for the public surface: abstractions that earn their place, dependency direction, seams, and the patterns the codebase already has.
Resource
Security Engineer Role Prompt
Make AI act as a security engineer — threat modeling, secure design, risk assessment, and defensive recommendations — instead of a generic assistant.
Resource
Turn a JSON Schema into a Prompt
You have the schema — fields, types, requirements. The translation into a prompt the model actually follows: schema lines, realistic example, and validation rules.
Resource
Software Engineer Role Prompt
Make AI act as a software engineer — design, implementation, and testing trade-offs — instead of a generic assistant that writes whatever you ask.
Resource
Unit Test Prompt — Isolation Done Right
Mock the dependencies, test the business logic, one behavior per test — the unit testing contract that bans plumbing tests.
Resource
Security Code Review Prompt
Twelve security checks — injection, auth, secrets, SSRF, privilege escalation — reviewed the way an attacker would read the code.
Resource
Production Readiness Review Prompt
SHIP or DO NOT SHIP: twelve checks on failure modes, observability, rollback, and load — the review that happens before the incident.
Resource
RBAC Design Prompt
Design a role model that scales — roles derived from real permissions, the role-permission mapping, and the inheritance and edge cases before you hardcode 'isAdmin'.
Resource
Permission Matrix Prompt
Make access auditable — a roles-by-actions matrix that shows exactly who can do what, exposes the gaps and over-grants, and becomes the spec the code is checked against.
Resource
Multi-Tenant Access Control Prompt
Keep tenants out of each other's data — design the isolation model, the tenant-scoping rule every query must obey, and the cross-tenant leaks to test for.
Resource
Rollback Plan Prompt
Turn a deploy into a deploy you can undo — a step-by-step rollback plan with triggers, the reverse of every forward step, and the point of no return named.
Resource
Product Validation Report Prompt
Consolidate the whole validation into one shareable report — the success metric, the evidence, the hit / partial / miss verdict, and the iterate / pivot / scale decision, in a form the team and stakeholders can act on.
Resource
Schema Design & ERD Prompt — Entities, Relationships, and Keys
Turn product requirements and key entities into an ERD-ready schema spec: tables, fields, primary and foreign keys, relationships with cardinality, indexes, and constraints — with the modeling gaps named as open questions.
Resource
Design System Spec Prompt — Components, States, and Accessibility
Turn UI requirements and component needs into a design-system spec: a component inventory with states, variants, responsive behavior, accessibility requirements, microcopy rules, and developer handoff notes.
Tools used in this project
Tool
System Prompt Generator
Build structured system prompts from role, tone, constraints, and model target.
Tool
SQL Optimization Prompt
Build evidence-based SQL optimization prompts — goal, platform, and the evidence you have turn into a query tuning contract.
Tool
JSON Output Prompt Builder
Build prompts that return structured data — JSON first, with YAML, XML, and CSV modes — parseable every time.
Tool
Role Prompt Generator
Generate expert role prompts — perspective, responsibilities, and decision criteria, not just "act as".
Tool
Multi-Step Prompt Builder
Break a big goal into a sequential prompt workflow — each step with an objective, prompt, and expected output.
Tool
Markdown Output Builder
Build prompts that produce documents in a fixed structure — headings, sections, and tables.
Tool
Code Review Prompt Generator
Generate code review prompts for any scope — snippet, file, diff, or full pull request — with focused review rules.
Tool
Test Case Prompt Generator
Build test generation prompts — unit, integration, or E2E — with framework modes and edge-case coverage rules.
Ways to Use This Project Path
Practical project ideas you can build from this base project path — each opens in the Project Advisor.
Recommended next project
Project
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.
Related projects
Project
Build a SaaS MVP with AI
The full path from idea to a shipped SaaS MVP — define and scope the requirements, design the architecture, API, and data model, then build it reviewed, tested, secured, cost-controlled, and deployed.
Project
Build an API Backend with AI
The full path to a backend you can put clients on — define the requirements, design the architecture, API contract, data model, and access control, then build it reviewed, tested, secured, and shipped.
Project
Build a CRM with AI
The full path to a CRM that fits your sales process — define the contacts, deals, and pipeline, model the data that ties them together, then build the roles, integrations, and pipeline UI, and ship.