How to Build a Two-Sided Marketplace Without Code on Creatr

A two-sided marketplace is one of the harder apps to build because it is actually four apps stitched together: a supply side, a demand side, a matching layer, and a payments system that splits money between parties. This tutorial walks you through each layer in order, using plain-English prompts you hand to Creatr. No code required at any step.

Before you start

Spend ten minutes answering these questions in writing before you touch Creatr. The clearer your answers, the less back-and-forth you will have during the build.

What are the two sides? Name them explicitly - for example, "service providers" and "clients," or "hosts" and "guests," or "sellers" and "buyers." Creatr uses the names you give throughout the app.

What is the transaction? Is it a booking, a purchase, a bid, or a contract? One transaction type keeps the data model simple. You can add more later.

What does the platform keep? Decide your take rate now - for example, 10% to the platform, 90% to the provider. This goes directly into your payment split prompt.

What builds trust? Reviews, identity verification, response time badges - pick one or two for v1. More is not better here.

Once you have answers, you are ready to describe the full system to Creatr.

Step 1 - Describe both sides and the transaction

Your first prompt defines the shape of the entire app. Be explicit about both roles, what each role can do, and what a completed transaction looks like.

Build a two-sided marketplace. One side is providers - people who list a service or product for sale. The other side is buyers - people who browse listings and place orders. A transaction is complete when a buyer pays for a listing and a provider fulfills the order. Both sides need separate accounts and separate dashboards. The platform takes a percentage fee from each completed transaction.

Creatr will ask clarifying questions about your specific domain - answer them in plain English. At this stage, do not worry about the payment percentage or the exact fields on each listing. You are establishing the two roles and the core transaction flow.

Step 2 - Model the supply side (providers and listings)

The supply side is your inventory. Providers create and manage listings. A listing has a title, description, price, category, and availability state (active, paused, sold out). Keep it simple in v1.

Add a provider account type. Providers can sign up, create a profile with a name, bio, and profile photo, and publish listings. Each listing has a title, description, price, category, and an active/paused toggle. Providers can edit or delete their own listings. Providers can see all their listings in a dashboard table with columns for title, status, total orders, and total earnings.

If your marketplace involves bookable time slots rather than fixed products, add that:

Each listing also has an availability calendar. Providers set which dates and times they are available. A listing cannot be booked outside of available slots.

Availability calendars add complexity. Only add them if your transaction actually requires scheduling.

Step 3 - Model the demand side (buyers and requests)

Buyers need an account, a way to browse, and a way to save or shortlist listings before they commit. Do not skip the shortlist - users who cannot save listings before buying convert at a lower rate.

Add a buyer account type. Buyers can sign up, browse all active listings, and save listings to a shortlist. A buyer's account page shows their shortlist and their order history. Buyers can leave a review on any completed order.

If your marketplace supports buyer-initiated requests (a buyer posts what they need and providers respond), add that in this step:

Buyers can also post a request - a short description of what they need, a budget range, and a deadline. Providers can see open requests and submit a quote. The buyer receives all quotes and can accept one, which converts the request into an order.

Buyer-posted requests are a separate matching pattern from provider-posted listings. Build one or the other in v1, not both.

Step 4 - Build discovery and search

A listing that cannot be found does not exist. Discovery is the link between supply and demand. At minimum, you need text search and category filtering. Faceted filters (price range, location, rating) come after you have real listings to test against.

Add a search and discovery page. Buyers can search listings by keyword, filter by category, and sort by price (low to high, high to low) or by newest. Each listing card in the results shows the title, a thumbnail image, the price, the provider's name, and the average review rating. Clicking a card opens the full listing detail page.

If your marketplace is location-dependent:

Listings also have a location field (city and country). Buyers can filter by location. The search results page shows a map alongside the listing cards, with each listing pinned on the map.

Location search adds significant scope. Include it only if geography is a core part of how buyers find providers.

Step 5 - The matching logic

Matching is the mechanism that connects a specific buyer to a specific provider. In a fixed-price marketplace, matching is simple: the buyer clicks buy, the provider gets notified. In a bid or quote marketplace, there is a negotiation loop between the two. Define which pattern you are using and describe it explicitly.

Fixed-price pattern:

When a buyer clicks "Book" or "Buy" on a listing, the system creates an order with status "pending payment." The buyer is taken to a checkout page. Once payment is confirmed, the order status changes to "confirmed" and the provider receives an email notification with the order details. The provider can then mark the order as "in progress" and later "complete."

Quote/bid pattern:

When a buyer accepts a provider's quote, the system creates an order with status "pending payment." The buyer receives a payment link. Once payment is confirmed, both sides receive an email confirmation and the order status changes to "confirmed."

Also describe what happens when an order falls through:

If a buyer does not pay within 48 hours of an order being created, the order automatically expires and the listing becomes available again. Providers can also cancel an order if the buyer is unresponsive, which triggers a refund and returns the listing to active status.

Step 6 - Payments with splits between the platform and providers

This is the step that separates a marketplace from a simple e-commerce site. The platform collects the full payment from the buyer and then pays out the provider's share, keeping a fee. Stripe handles this through Stripe Connect, which lets your platform manage payouts to multiple providers.

Integrate Stripe for payments. When a buyer checks out, Stripe collects the full amount from the buyer's card. The platform retains 10% as a platform fee. The remaining 90% is held and paid out to the provider's connected Stripe account. Providers must connect a Stripe account before their listings go live. Payouts to providers happen 7 days after an order is marked complete, to allow for disputes.

Adjust the percentage, the payout timing, and the dispute window to match your business model.

For more detail on wiring Stripe into a Creatr app, see Add Stripe payments to your app.

Compliance note: Marketplace payments that move money between parties may trigger payment processing regulations, KYC (know your customer) requirements, and money transmission rules depending on your jurisdiction and transaction volume. Stripe Connect handles a significant portion of this compliance work, but you are responsible for understanding and meeting any obligations that apply to your platform. This tutorial does not constitute legal or financial advice - consult a qualified advisor before going live with real transactions.

Step 7 - The trust layer (reviews and verification)

Trust is what makes a stranger willing to pay another stranger. Two mechanisms cover most of it in v1: reviews after completed orders, and a simple verification badge for providers who have completed a set number of orders without disputes.

After an order is marked complete, both the buyer and the provider receive an email asking them to leave a review. The review form has a 1-5 star rating and an optional text comment. Reviews are publicly visible on the provider's profile and on the listing page. The average star rating is shown on listing cards in search results.

For the verification badge:

Providers who have completed 10 or more orders with no disputes receive a "Verified" badge on their profile and listing cards. The badge is calculated automatically and updated when the order count changes.

Keep reviews simple. A complicated review system with sub-ratings, photo uploads, and response threads is a v2 feature.

Step 8 - Dashboards for each role

Each side of the marketplace needs a dashboard that surfaces the information relevant to them. Provider dashboards and buyer dashboards are separate - do not merge them into one account page.

Provider dashboard:

The provider dashboard has four sections. The first section shows earnings: total earnings this month, total earnings all time, and pending payouts. The second section shows active listings with a quick toggle to pause or unpublish. The third section shows incoming orders with their current status. The fourth section shows the provider's review score and recent reviews.

Buyer dashboard:

The buyer dashboard has three sections. The first section shows active and past orders with their status. The second section shows the buyer's shortlisted listings. The third section shows reviews the buyer has left and reviews the buyer has received as a provider, if they have a provider account.

Admin dashboard:

Add an admin dashboard accessible only to the platform owner account. The admin dashboard shows total transactions this month, total platform fees collected, a list of all providers with their verification status, and a table of all orders with the ability to manually trigger a refund or flag an account.

The admin dashboard is not optional for a live marketplace. You will need it to handle disputes, refunds, and flagged accounts.

Step 9 - Test the full loop

Before you ask Creatr to deploy, walk through the entire transaction loop in the preview environment. Do this as both a buyer and a provider.

Set up a test provider account with one active listing at a fixed price. Set up a test buyer account. As the buyer, search for the listing, add it to a shortlist, proceed to checkout, and complete a test payment using Stripe's test card numbers. Confirm that the order appears in both the provider's dashboard and the buyer's order history. Mark the order complete as the provider and confirm that the review request is sent to both parties. Check that the payout is queued in the provider's earnings section.

Write down anything that does not match your expectations and send those notes to Creatr as a follow-up prompt before going live.

Also test the failure cases:

Test an expired order by creating an order and not paying within 48 hours. Confirm the listing returns to active status. Test a provider cancellation and confirm the refund is triggered. Test a review submission and confirm it appears publicly on the listing page.

Failure paths are where marketplaces break in production. Testing them in preview costs nothing.

Step 10 - Ship and iterate

Once the full loop works in preview, deploy.

Deploy the marketplace to production. Set up a custom domain. Enable production Stripe keys. Send a welcome email to the first five providers I invite manually.

Do not try to launch with every feature you can imagine. The first version of a marketplace needs to do exactly four things well: let providers list, let buyers find and pay, split the money correctly, and let both sides leave reviews. Everything else - promotions, referral codes, advanced filters, subscription tiers for providers - belongs in the roadmap after you have seen real usage.

For managing your provider relationships and outreach as the platform grows, see Build a custom CRM on Creatr.

Recap

A two-sided marketplace is four systems layered on top of each other. Supply (providers and listings) comes first because without inventory there is nothing to discover. Demand (buyers and discovery) comes second. Matching connects a specific buyer to a specific provider through a defined transaction type. Payments split the money between the platform and the provider at the moment of purchase, with payouts held briefly to cover disputes.

The prompts in this tutorial are starting points. Adapt the names, percentages, and rules to your market. The structure - describe both sides, model each side, wire the matching, split the payment, add trust, build the dashboards, test the loop, ship - holds across nearly every marketplace type.

What changes between a services marketplace and a physical goods marketplace is not the structure, it is the fields on the listing, the payout timing, and the fulfillment steps. Start with the structure, then fill in the specifics.