How to build an Upwork-style request marketplace

What you’re building

A reverse marketplace: instead of vendors publishing services and buyers shopping a catalog, buyers post requests (“Need a Python developer for a 2-week scraping project, $3,000 budget”), vendors send proposals, and buyers pick one.

Upwork and Freelancer.com work this way. The plugin ships it as a first-class mode alongside the Fiverr-style browse-and-buy. Both modes are always on, and you choose which one to lead with. The Upwork alternative comparison is the honest version of where a hosted site beats your own.

When request mode wins over browse mode

Request mode works best when:

• The job is custom by nature. Web development, legal work, plumbing, custom illustration. No two requests are identical.
• Budget varies wildly. A “build me a website” brief might be $500 or $50,000. Vendors quote per brief, not per fixed package.
• Buyers need to qualify vendors. Reviewing 3-5 proposals lets them assess fit before committing money.
• The deliverable is hard to package upfront. “Audit my codebase” doesn’t fit a 3-tier price card cleanly.

When the job is standardized (logo design, 1-hour tutoring, voiceover), browse-and-buy converts better because it removes the “wait for proposals” step. The two modes article and the freelance marketplace playbook cover the other side.

The 30-minute setup

1. Wizard. Marketplace name + currency + commission. For request marketplaces, commission is typically charged on the accepted proposal value (e.g., 10% of the $3,000 quote).
2. Lead with requests. There is nothing to switch on: buyer requests and the catalog are both always available. Put the post-a-request page in your main menu so buyers start there.
3. Categories. Apply to requests, not just services. Buyers categorize their brief (Development, Design, Writing, Legal, etc.) so vendors can spot the relevant ones.
4. The brief form. Its fields are fixed: title, description, category, budget, delivery days, attachments, required skills and an expiry date. It is separate from the per-service requirements form.
5. Who can propose. Any approved vendor can see an open brief and send a proposal. There is no category or level gate, so your quality control happens when you approve vendors. New installs default to open registration, so set Vendor Registration to “Requires Approval” if you want a gate.

The proposal flow

1. Buyer posts a brief (free, no charge to post).
2. Approved vendors see it in the list of open requests.
3. Vendors send a proposal: cover letter, price, delivery time in days, optional file attachments (case study, portfolio sample). A vendor can also offer a milestone plan instead of one fixed price. The buyer gets an email when a proposal arrives.
4. Buyer reviews proposals side by side, can message a vendor from their profile with questions, and picks one.
5. Buyer pays the accepted quote → standard order workflow runs (requirements, delivery, revisions, complete).

What a vendor sends

A proposal needs a cover letter, a price and a delivery time. Files are optional, and so is a link to one of the vendor’s own services, which brings that service’s reviews and ratings along. A vendor gets one proposal per request. It can be edited while it is pending and withdrawn, and a vendor who withdraws can send a fresh one while the request is open. Vendors only see their own proposals. Only the buyer sees them all.

Fixed price or milestones

The vendor picks a contract type before the buyer sees the proposal, so the buyer compares like with like.

With milestones, phase one is payable straight away and each later phase opens only after the one before is approved. When every phase is approved the project completes. A vendor can propose extra phases later from the order page. Milestones work on the built-in checkout and on WooCommerce, so pick one of those two if you need staged payment.

Why not a generic RFQ plugin

Most “request a quote” WordPress plugins drop after step 3. They don’t have the order workflow that runs after acceptance. WP Sell Services treats an accepted proposal as the trigger that converts the brief into an order. From there, the same delivery / revision / dispute / review machinery runs as for a browse-and-buy order.

That’s what makes it one plugin that handles both halves of the marketplace.

How buyers and vendors find each other

On the buyer side, a request has a category, a budget as a fixed amount or range, a delivery time, skills and attachments. It stays open for 30 days by default, and you can change that period. Buyers can edit an open request, close it, or repost it after it expires. A request that has proposals cannot be deleted, only closed.

On the vendor side, open requests can be filtered by category, searched by keyword and sorted by budget or date. A vendor who prefers browsing a catalog of ready-made services has the same search, category pages, price and rating filters and sorting that a catalog-first marketplace has. Buyers who like a vendor can also message them from their profile or save a service to favorites.

Request attachments are visible to every vendor who can browse the request, so tell buyers not to attach anything private. Before a vendor is chosen, nobody can negotiate inside the proposal: questions go through the vendor’s profile contact form.

Vendor behavior to design for

Request marketplaces have a quality problem: low-effort vendors send template “I can do this, $50, message me” proposals on every brief. This kills buyer trust fast.

Counters built into the plugin:

• Vendor approval. You approve vendors before they can sell, so low-effort accounts never reach your briefs.
• Vendor reputation carries from completed orders. Ratings and the vendor’s level (New, Rising, Top Rated or Pro Seller) sit on their profile, so buyers can check before they accept.

Levels are earned. Rising needs 5 completed orders, a 4.0 average rating, 3 reviews, 80% on-time delivery and 30 days since joining. Top Rated needs 25 orders, 4.7, 10 reviews, 90% on time and 90 days. Pro Seller is one you award yourself. The seller levels article explains the reasoning.

A new marketplace has no reputation yet, so give early vendors a way to start: a lower commission for the first months is a per-vendor setting. Members can also report a vendor, and the reports gather in one admin screen. If a vendor sends spam proposals, you can suspend the account.

Disputes are higher in request mode

Custom work + bigger budgets = more disputes. The plugin’s dispute system carries the full proposal + message history + delivery files + revision requests. Build a clear policy:

• Refund triggers: vendor missed deadline by >5 business days, deliverable doesn’t match accepted scope.
• Partial refund triggers: scope creep, mid-project pivot, mutual cancellation.
• No-refund triggers: buyer didn’t respond after delivery (the order completes by itself after 3 days by default, and that number is a setting).

Publish the policy on a /policy/ page. Apply it consistently.

A dispute runs through open, pending review, an optional escalation, resolved and closed. Both sides add evidence in a thread. You can resolve with a full refund, a partial refund, in favor of the buyer, in favor of the vendor, or a mutual agreement. The money is returned through the original gateway and the vendor’s earnings are reversed in one step. A late order is marked late, and a dispute opens by itself when delivery is overdue by a set number of days (3 by default, and 0 turns it off). Start with the dispute process.

Pricing, payouts and Pro

Pricing the marketplace

Two commission structures work for request marketplaces:

• % of accepted proposal value (10-15%). Default. Scales with deal size.
• Vendor subscription + low commission. Vendors pay $29-99/mo to access briefs + send proposals; you take 5-8% commission. Best LTV per vendor.

For B2B marketplaces (RFQs over $5k average), the subscription model produces the best margins. For consumer-facing (under $500 brief), % commission wins.

The commission rate can be anything from 0 to 50 percent, with a custom rate per vendor. On a fixed proposal it is taken when the order completes. On a milestone it is taken as each phase is paid, so the vendor has the money before the final delivery. Subscription plans are a Pro feature and are built on a monthly or yearly price, a service limit, a featured limit and a commission override.

Paying vendors

Free payouts are by hand. A vendor requests a withdrawal by bank transfer or PayPal, you approve it, send the money and mark it completed. You can hold earnings for a clearance period and export withdrawals as a CSV. Pro adds Stripe Connect and PayPal Payouts. The payouts article and the milestone payments article cover the money flow.

When you’ll need Pro

• WooCommerce checkout for large proposal values where buyers want regional payment methods and whatever invoicing your WooCommerce extensions provide.
• Stripe Connect or PayPal Payouts once you’re paying 50+ vendors a month.
• Vendor analytics so vendors can see revenue, orders, response rate and which services convert. Proposal-level reports are not part of it.
• Vendor subscriptions for the subscription commission model.

See pricing for the plans.

What it does not do

• No private or invite-only briefs. Every open brief is visible to your approved vendors.
• No messaging thread inside a proposal. Questions go through the profile contact form.
• No bidding limits, credits or automatic matching. Vendors can send as many proposals as they like, and the plugin does not rank vendors against a brief.
• No recurring contracts. Monthly billing of a contract is not available.
• No hourly tracking. There is no timesheet or screenshot tracking. Pricing is fixed or by milestone.
• No importer from another marketplace. Moving over is a rebuild or a script against the REST API.

Other plugins on the same site

WP Sell Services is one of several separate, optional plugins from the same team. They run on one WordPress site and one login.

What it connects to is specific: its own standalone checkout with Stripe and PayPal, WooCommerce as a checkout rail on Pro, Razorpay on Pro, Stripe Connect and PayPal Payouts, and cloud storage on Amazon S3, Google Cloud Storage or DigitalOcean Spaces. A request marketplace often wants a place for talent to gather, and the sister products are those places. WP Career Board is a job board for permanent roles, a different thing from project briefs. Jetonomy is a forum and Q&A plugin. BuddyNext is a community plugin. WB Gamification adds points and badges. BuddyX Pro and Reign are themes. They share your site and your login, and we make no claim that any of them is wired into proposals or orders.

The trade is plain. A hosted marketplace is one bill, and it takes a cut. These are separate plugins you install, host and update yourself.

Your first 30 days

1. Days 1 to 3. Run the wizard, create the pages, connect a gateway and put “Post a request” in the main menu.
2. Days 4 to 7. Set Requires Approval, write the dispute policy and publish it.
3. Week 2. Approve 10 vendors in one vertical. Ask each to complete a profile and a portfolio.
4. Week 3. Post five realistic briefs yourself and have vendors answer them. Run one fixed and one milestone contract end to end.
5. Week 4. Open to buyers. Reply to the first briefs the same day.
6. Day 30. Count briefs, proposals per brief and accepted proposals. If briefs get no proposals, you need more vendors.

Try it

The InstaWP demo has buyer requests ready to try. Post a brief as a buyer, propose on it as a vendor, run through accept → pay → deliver. 15 minutes to see if the reverse-marketplace pattern fits. The site owner guide shows the admin side.

Common questions

Can I run only request mode (no browse catalog)?

Both modes are always on, and there is no setting to turn the catalog off. Lead with requests in your menu and leave the catalog out of it. Many B2B marketplaces work this way. The catalog pages still exist if someone finds them, so decide whether to leave them as they are or keep vendors from publishing services.

Can buyers re-engage the same vendor for a follow-up project?

Yes. Built-in messaging persists across orders. A buyer can message a past vendor from their profile and ask them to answer a new brief, or order one of that vendor’s services. A brief itself cannot be addressed to one vendor, because every open brief is visible to your approved vendors.

What about NDAs and private briefs?

There are no private briefs: every open brief is visible to your approved vendors. Keep confidential detail out of the brief and share it in the order messages once you’ve picked a vendor. Files uploaded to an order are kept outside the public web folder and only the people on the order can open them.

Can buyers pay in stages on a big project?

Yes, through milestone contracts. The vendor proposes phases with an amount and days for each, the buyer accepts the plan, and then pays and approves one phase at a time. Later phases stay locked until the earlier ones are approved. This works on the built-in checkout and on WooCommerce, and only for orders that started as a request.

How long does a brief stay open?

Thirty days by default, and you can change the period in settings. After that the request is hidden from vendors and takes no new proposals. The buyer can repost it with changes. A buyer can also close it early, which notifies vendors with pending proposals. Accepting a proposal marks the request as hired and declines the rest.