Case 03 · Two-sided marketplace · Complex flows + AI
A two-sided AI booking marketplace for live performers. The whole product hinges on one hard thing: making an artist's worth visible, then moving real money safely between strangers.
An independent artist can't quote a price with confidence. A business can't tell who's good or what's fair. Both problems are the same problem: worth is invisible.
For the performer (a rising DJ, say), corporate work is gatekept by a booker who takes a 30% cut, and when a direct opportunity does appear, they freeze on the number because they don't know their market rate. For the business booking entertainment, every enquiry comes back as "price depends," there's no objective signal of an act's quality, and the whole thing takes three days across WhatsApp DMs.
So I anchored the entire product on a single keystone: make an artist's market worth and credibility visible. Both sides' "aha" turns out to be the same sentence: the artist sees what they're worth; the business sees who's good and what's fair.
During onboarding the artist links Spotify and self-reports their social reach and experience. The AI returns a suggested price range with its reasoning, which they can accept or override. It's the time-to-value moment of the whole product, so the design judgment inside it matters: the model weights experience and reliability over raw follower count.
That choice is visible in the output. An experienced, low-profile working DJ gets a higher suggested range than a viral newcomer with a fraction of the gigs behind them:
| Profile | Signal | Suggested range |
|---|---|---|
| Quiet pro | Deep experience, modest following | ~7.5–11.5M IDR |
| Viral newcomer | ~150× the followers, few gigs | ~4.5–8M IDR |
Worth isn't reach. Encoding that into the first number an artist ever sees is what makes the suggestion feel fair instead of insulting, and it's why the artist trusts the platform enough to sell through it.
The information architecture is the real difficulty: two completely different mental models ("sell myself" and "fill a slot") that have to converge in one place without confusing either side. I mapped it as four zones, with everything funnelling into a single shared deal room.
Twenty-two screens in total. The artist browses matched gigs and applies with a quote; the business posts a gig in plain language, gets an AI-structured brief, and works a ranked shortlist of artists with prices and worth-signals already attached. That's the business "aha": who's good and what's fair, on one screen. Both paths then meet in the same room.
Every booking on the platform flows through one screen. It can't just be a chat. It has to hold a contract.
The deal room pairs a message thread with a structured terms panel (date and time, fee, duration, deposit %, equipment and rider, cancellation policy, payment method) and runs them through an explicit six-state machine:
Making the terms first-class objects, not sentences buried in a chat log, is what keeps "we have a deal" unambiguous for both parties. This screen is the critical path and the bottleneck: it's shared by both roles, every booking depends on it, and it's where money is about to move, so it had to be the most robust thing in the product. The design work was as much about state and clarity as about layout.
The defence isn't a wall: it's making the on-platform path the easier, safer one. The deposit, the cancellation policy and dispute protection all live in-platform, so leaving means giving up the very things that make the booking feel secure.
Security wasn't a later pass. For a product whose entire reason to exist is trust between strangers handling money, the safe-by-default posture is part of the user experience.
The core booking loop is built (post a gig, confirm the AI brief, discover and rank artists, negotiate in the deal room, confirm, and reach the deposit payment screen), and the AI price suggestion is verified working end-to-end. It's an active build toward a hackathon deadline. What's not live yet: the Stripe test keys and Firebase service account aren't wired in production, so payment and write flows are gated; a synthetic-auth dev bypass still has to be removed before any real deploy; and there are no real users yet. Discovery runs on twelve seed artist profiles built for the demo.
I include Gigly because it's the clearest example of designing genuinely complex flows (a two-sided IA, an AI valuation step, and a stateful negotiation-to-payment machine) and holding them to a real-product standard rather than a demo-day one.