Turn the marketplace around. Instead of sellers posting supply and buyers hunting through it, let buyers post what they need and let vendors bid for the work. The hard part of a reverse marketplace was never the bidding — it was trust: the buyer will not pay until the job is done, the vendor will not start until the money is real. The way out is escrow: hold the buyer’s funds as credits, release them only when the booked job is delivered, and let a Telegram bot broker the matches. Demand posts first; supply bids; credits make both sides safe.

Inverting the marketplace

The idea comes from an analysis on VBWD, a self-hosted, source-available full-stack SaaS SDK. The marketplace plugin already gives you vendors, listings, and multi-party structure — you simply use it the other way around. A buyer’s request-for-work is the object that goes live; vendors respond against it. That reuse is why an exotic-sounding model is actually buildable: underneath it is the same vendor-and-listing machinery, the same shared invoice, the same event core. What distinguishes a reverse marketplace is the sequence of trust — someone has to commit first, and it should not be the vulnerable party.

Credits as escrow — the non-trivial move

This is where token_payment earns its place. You would normally think of it as a prepaid credit balance; here it does something more interesting. As the original analysis puts it:

When a buyer accepts a bid, their credits are held — committed to that job but not yet the vendor’s.

The vendor can see the funds are real and reserved, which is the assurance they need to start; the buyer’s money is protected until delivery, which is the assurance they need to pay up front. Release is gated on delivery, and delivery is a scheduled thing — which is where booking comes in. The accepted job is a booked commitment: an appointment, a slot, a delivery window. When it is completed, that completion is the event that authorizes release from held credits to the vendor:

The point of truth stays the invoice line item, and the event-based contract engine balances what is held against what is owed.

The broker lives in Telegram

A reverse marketplace is a coordination problem — new requests, new bids, acceptances, reminders, delivery confirmations — and most of that does not want to live on a web page nobody keeps open. bot_telegram is the broker: it pings vendors when a matching request appears, tells a buyer they have new bids, nudges both parties as a booked delivery approaches, and confirms when a job is marked done. Because the core is event-driven with signed webhooks, every message is downstream of a real state change rather than a cron job guessing. Add discount to seed the early market — waive fees for the first jobs or reward on-time vendors — and, like every plugin, it toggles on or off live, without a restart.

The honest boundary

Escrow mechanics are not the same as dispute resolution. VBWD holds the credits, gates release on a delivery event, and gives you the audit trail — but it cannot decide, when a buyer and vendor disagree about whether the work was delivered, who is right. That judgment is your product: the arbitration policy, the evidence you require, the refund rules, the trust and safety model for bad actors on both sides. You also carry the regulatory weight of holding value in escrow and the market-making of keeping requests flowing to bids. The platform removes the engineering of safe money-holding; it does not remove the human judgment of adjudicating a dispute.

If you have wanted to flip the marketplace and let demand lead, the escrow was always the blocker — and it is already built. Read the full analysis on VBWD, and the public code is on GitHub.

Written for Red Robot with AI assistance and human editing. Adapted from an original analysis published on VBWD.