We built and run a marketplace where an attorney who cannot make a hearing finds another attorney to cover it. One side posts an appearance, the other side takes it, appears in court, files a report, and gets paid.
Described that way it sounds like a listings page with a checkout button. It is not. Most of the engineering in a marketplace goes into things a visitor never sees, and most of the ways a marketplace fails are not technical. Here is what we would tell anyone about to build one.
You are building three products
A marketplace is a product for the buyer, a product for the seller, and a product for yourself as the operator. They share a database and almost nothing else.
The posting attorney wants speed: describe the hearing in under a minute and trust that someone competent will show up. The covering attorney wants clarity: where, when, what is expected, and how much it pays. The operator needs to see everything, step in when something goes wrong, and prove afterward what happened.
Founders usually design the buyer side in detail, sketch the seller side, and forget the operator side until the first dispute. Build the admin tools early. You will be living in them.
Payments are the easy part
Moving money between strangers used to be the hard problem. A provider built for platforms now handles most of it: onboarding the people who get paid, verifying their identity, collecting the buyer's payment, taking your fee, and paying out the rest. We use Stripe Connect and would not consider writing that ourselves.
What the provider does not do is decide your rules. Those are yours:
- When is the buyer charged? At posting, at acceptance, or after the work is done?
- When is the seller paid? Immediately, or after a window in which the buyer can raise a problem?
- What happens on a cancellation? An hour before a hearing is very different from a week before.
- Who absorbs a failed payment or a chargeback?
Every one of those is a business decision that becomes code. Write the answers down before you write the code. Changing a payout rule after real money has moved through the old one is painful.
Trust is the actual product
A marketplace sells one thing: the confidence that a stranger will do what they said. For attorneys covering court appearances the stakes are a client's case, so vetting is not optional. Both sides are verified before they can transact.
The general lesson applies to any marketplace. Work out what the worst realistic outcome is for each side, then build the check that prevents it. Reviews and ratings help later. Verification is what lets the first transaction happen at all.
It also means some features are deliberately slow. Instant signup feels better and converts better. In a market where one bad actor can cost a customer their livelihood, slower and verified wins.
Time is a feature
Marketplace work is time sensitive in a way most software is not. A hearing posted at four in the afternoon for nine the next morning needs to reach the right people within minutes.
That requires more plumbing than expected:
- Several channels. Email is too slow on its own. We send text messages and browser push notifications as well, and let people choose.
- Realtime updates. When someone takes a job, everyone else looking at it needs to see that immediately, or two people believe they have it.
- Only one winner. Two acceptances arriving in the same second must resolve to one, enforced in the database, not in the interface.
That last point is the kind of bug that never appears in testing and always appears in production. Enforce it where the data lives.
The cold start is not a software problem
A marketplace with no sellers is useless to buyers, and the reverse. No amount of engineering fixes that. What helps is starting narrow: one city, one kind of job, a small group of people you can call personally.
Software can still support it. We built pages for individual states and courthouses so that people searching for coverage in a specific place find something that speaks to exactly that. Supply and demand for a marketplace are usually local, even when the product is not.
What we would do again
- Enforce a merge gate. Nothing ships unless type checks, lint, tests, and the build all pass. When money moves through your code, a broken deploy is not an inconvenience.
- Log every state change. Who did what, when, to which job. Disputes are settled by the record.
- Keep the rules in one place. Fees, cancellation windows, and payout timing live in configuration that a non-engineer can read.
And one thing we would do sooner: build the operator's view on day one.
If you are planning a marketplace, the most useful hour you can spend is writing down your rules for money and trust before any design work begins. We are glad to go through them with you. Tell us what you are building.