Marketplace developer

Marketplace Developer with Matchmaking and Escrow expertise.

Two-sided marketplaces on Bubble.io or vibe code: supply and demand profiles, matchmaking algorithms that hold at scale, invite-vs-open flows, ratings, dispute, Stripe Connect escrow. ShareTalent, Construction Marketplace, and FoodIWant are the shipped proof; production-ready, not prototype-quality.

Marketplace development is the discipline of building two-sided platforms where supply finds demand, the match works at the schema layer not in a workflow, and the trust scaffolding (ratings, escrow, dispute, refund) is part of the architecture from day one. The hard parts are not the listing UI. They are the matchmaking algorithm that stays cheap as the catalogue grows, the bid flow that keeps both sides happy, the reputation system that resists gaming, and the payment escrow that releases funds at the right moment to the right party.

Most marketplace builds I see arrive working on the happy path. Two test users, three listings, the demo runs. Then the catalogue grows past fifty rows, the in-memory filter starts to lock up, the open-bidding flow drowns one side in irrelevant invites, and the team discovers their escrow logic has gaps when a refund collides with a dispute. The version that ships with the trust and match scaffolding right from day one is the version that scales without the rewrite. The version that bolts it on later is the rewrite.

What marketplace development means engineering-wise

A marketplace is a small set of structural disciplines, repeated cleanly. The product surface decides what gets matched to what, what the trust signals are, and where the money sits between the parties. The engineering underneath is the same across verticals.

Supply and demand schemas. A Supplier has a profile (who they are, what they offer, where they operate, what their specialisations are). A Buyer has a project or a need (location, scope, budget, timeline). The schema for both sides shapes every other decision the product can make. Get the schema right on day one and the matchmaking writes itself.

Matchmaking that holds at scale. The algorithm is multiple server-side constraints joined cleanly: filter Suppliers whose service area covers the Buyer’s location, intersect their specialisations with the Buyer’s required scope, rank by reputation or recency or rate. On Bubble.io that is a single constrained query with the right indexes. The version that pulls every row and filters in memory works at fifty suppliers and breaks at five hundred. The schema is the algorithm.

Invite-vs-open flow choice. An invite-only marketplace (the Buyer posts, the algorithm selects, the Supplier sees only relevant invitations) keeps both sides happy as the catalogue grows. An open marketplace (every Supplier can browse every job) needs aggressive filters and a strong ranking signal or one side gets flooded with noise. The choice is a product decision with large engineering consequences for the workflow, the notification layer, and the reputation system underneath.

Reputation and ratings that resist gaming. Star ratings, written reviews, completion counts, response time, dispute history. Each signal has a manipulation pattern; the architecture decides which to trust and how to display the rest. The schema for reviews has to support flagging, moderation, time-decay weighting, and a rebuttal-from-the-rated-party surface.

Dispute and escrow. Stripe Connect for the escrow primitive (the money sits with Stripe, not the platform, between the buyer’s payment and the supplier’s payout). The dispute workflow handles partial refunds, mediator review, evidence upload, and the payout-release condition. Most disputes are resolved fast if the workflow is designed to surface them fast.

Onboarding both sides. A two-sided marketplace has a chicken-and-egg problem. The supply side has to be seeded before the demand side arrives, or the first Buyers see an empty catalogue and bounce. The Supplier onboarding flow has to be friction-free; the Buyer onboarding flow has to feel like the catalogue already has value. The product decision (seed supply manually, partner with an existing community, focus on a tight niche first) shapes the engineering shape of the onboarding.

How the build runs

The pattern is the same across verticals (talent marketplaces, gig marketplaces, service marketplaces, food/restaurant marketplaces, B2B sourcing). Four phases, run in order, with a human gate between each.

The first week is the supply schema. What does a Supplier look like (profile, specialisations, service area, rate, availability). What proof of credibility do they carry (portfolio, certifications, prior ratings). How do they manage their listing inventory. What signal does the platform need from them to feed the matchmaking algorithm. The brief that lands at the architecture phase is precise enough that the Supplier surface designs itself.

The Buyer schema mirrors the Supplier schema across the join. A project or a need has a location, a scope, a budget, a timeline. The Buyer’s search surface reads against the Supplier catalogue through the matchmaking algorithm. The decision of invite-vs-open shapes whether the Buyer browses or posts; both flows ship from the same underlying schema if it is designed for it.

The matchmaking lives in server-side constraints joined to the right indexes. Geocoded service-area fields filter by location cheaply. Specialisation relations filter by scope cheaply. Ranking by reputation, recency, or rate is a sort on the same query. The whole match runs as a single constrained read, not an in-memory scan. Boring schema work, large performance consequence.

Reputation system on Day One (not Year Two). Stripe Connect for escrow with payout release tied to a workflow condition (completion, confirmation, dispute resolution). Dispute surface that captures evidence from both sides and routes to a mediator (the platform team, initially; a third-party mediation flow if scale demands). Refund workflow that handles partial refunds, mid-dispute settlements, and refund-after-payout edge cases.

The proof: three production marketplaces

Three named-client marketplaces, shipped, with the receipts.

Marketplace · Non-Profits

ShareTalent: New product → Pixel-perfect Figma → Performance non-negotiable

A new product for an existing client on Bubble.io. Discovery feed, talent directory, jobs surface, Agentic AI resume import through n8n, three-axis taxonomy for matching. Live at sharetalent.co.

  • Pixel-perfect Figma Brief from client
  • Lead Bubble dev Role
  • Live Status
Read the case study →
ShareTalent Non-Profit marketplace on Bubble.io

Construction Tech

Construction Marketplace: MVP in three sprints

Solo Bubble.io MVP. Location-and-specialisation matchmaking between property managers and contractors. Zero bugs on the client's independent testing pass across all three sprints.

  • 3 Sprints
  • AirDev Canvas Stack
  • 0 bugs Test pass
Read the case study →
Construction Marketplace on Bubble.io

Food Tech · Marketplace

FoodIWant: Stripe fix → Marketplace rebuild → 6 verticals

Seven months. Hired to fix one thing, stayed for seven. Stripe Connect escrow, transactional email migration from SendGrid to Postmark, marketplace expanded from one food vertical to six.

  • 7 months Engagement
  • Stripe fix Initial brief
  • 1 → 6+ Verticals
Read the case study →
FoodIWant food marketplace on Bubble.io

Engagement terms

Same as the rest of my practice. Hourly only. $60 per hour. Tracked via Upwork or similar; weekly invoices; no setup fee, no padding. Minimum is a few hours of scoping discovery; no commitment beyond that until you are confident. Marketplace MVPs typically run six to twelve weeks for V1; the trust scaffolding (escrow, dispute, ratings) is part of V1, not a follow-on phase. Long-arc maintenance retainers are common (ShareTalent ran 17 months; FoodIWant ran 7).

Send your vertical, your supply-and-demand sketch, and whether you want invite-only or open when you book the call. I will tell you whether the build is one I should lead directly or one I should lead with a payment-specialist or moderation-specialist paired alongside. The decision happens once, with you in the loop.

Before the call

Common questions.

Open marketplace vs invite-only: how do you choose?
Depends on the catalogue density and the cost of irrelevant invites to each side. Open marketplaces work when supply is plentiful and buyers want to browse (consumer marketplaces, content platforms). Invite-only works when supply is scarce or expensive to engage and buyers benefit from a curated shortlist (B2B service marketplaces, high-value contractor platforms, talent marketplaces). Construction Marketplace deliberately chose invite-only to keep contractors from being spammed with irrelevant project posts and PMs from drowning in bids. FoodIWant runs an open browse for gig discovery plus invitation for direct hires. The choice shapes the entire workflow, notification layer, and reputation system underneath.
What does the matchmaking algorithm actually look like?
It's almost always a single constrained query, not a workflow. The Supplier schema has geocoded service-area fields and specialisation relations. The Buyer's project has a location and a required scope. The match is: filter Suppliers whose service area covers the project's location, intersect their specialisations with the project's required scope, rank by reputation or recency. That's a server-side constrained read, and the same pattern holds whether the stack is Bubble.io, Postgres (Preferably Supabase) with RLS, or a vibe-coded Supabase backend. The mistake is making it an 'algorithm' instead, with a workflow that pulls every row and filters in memory. That pattern locks up at fifty Suppliers. The schema is the algorithm.
How do you architect ratings and reputation?
Each completed job generates a review record: star rating, written note, how fast the job was delivered, and a flag if the review looks fake or abusive. The overall reputation score is pre-calculated on a schedule in the background, not recalculated live on every page load, so profiles stay fast as the review count grows. The profile shows the score, recent reviews, and a rebuttal field so the rated party can respond to any review on record. Fake-review detection is built in from day one: one-shot accounts (new accounts that exist only to leave a review), suspicious timing patterns, and optional reputation-staking for marketplaces that need stronger trust signals.
How does dispute and escrow handling work?
Stripe Connect for the escrow primitive: the money sits with Stripe between the Buyer's payment and the Supplier's payout. The payout release is gated by a workflow condition: completion confirmation, time-based auto-release, or dispute resolution. The dispute surface captures evidence from both sides, routes to a mediator (the platform team initially; a third-party mediation flow if scale demands it), and the resolution writes a payout-release record that triggers the Stripe payout. Refund workflow handles partial refunds, mid-dispute settlements, and refund-after-payout edge cases via Stripe refund objects. Most disputes resolve fast if the workflow is designed to surface them fast.
How do you handle two-sided onboarding without the chicken-and-egg problem?
Product decision first, engineering shape second. Most marketplaces solve chicken-and-egg by seeding one side manually (the platform team recruits the initial supply) or by partnering with an existing community to seed it for them, then letting demand-side acquisition spend justify the supply-side investment. The engineering shape that supports this: a frictionless Supplier onboarding flow, an admin tool to invite Suppliers in bulk, a Buyer-facing search that surfaces value even when the catalogue is sparse, and a notification system that prevents the empty-catalogue bounce on the Buyer side. ShareTalent solved this with non-profit affiliation; Construction Marketplace seeded contractors via direct outreach.
What are the scale ceilings on a marketplace build?
Practical ceiling depends on query shape, not row count, and the stack sets where the discipline tightens. On Bubble.io: marketplaces in the 5k-50k catalogue range are comfortable with the right schema (geocoded location fields, server-side constraints, paginated repeating groups, indexed sort columns). Past 50k rows the discipline tightens: scheduled aggregates, search index where it actually helps, caching for hot queries. Past 500k rows the honest answer is usually a hybrid: Bubble for UI plus a dedicated search service like Algolia or Typesense for the catalogue. On a vibe-coded or Postgres (Preferably Supabase) stack: the ceiling sits higher because Postgres query planning and RLS handle large row counts more cheaply, but the discipline is the same: constrained server-side reads, indexed sort columns, pre-aggregated reputation scores. The ShareTalent and FoodIWant builds run comfortably under their respective scale; I will tell you on the call where your vertical sits given your catalogue projections.