We're building the "is this vendor even free on my date?" problem out of weddings

Quick context before the story: I'm working on WendorPro, a wedding-vendor booking marketplace + CRM. We're pre-launch (waitlist open), so this is a "here's what we found and what we're betting on" post, not a victory lap.

The problem we kept tripping over

If you've planned a wedding recently, you know the loop: you find a photographer whose work you love, you send an inquiry, you wait two or three days, and then you get back "sorry, we're already booked that weekend." Repeat across photographer, venue, florist, DJ, planner. The single most important filter — is this person actually available on my one specific date — is the thing you can't see until you've already spent the effort reaching out.

From the vendor side it's the mirror image. Their inbox fills with inquiries for dates they can't take, and the leads that are real arrive mixed in with the ones that were never going to convert. Everyone is doing unpaid sorting work.

The insight (such as it is)

The wedding industry has approximately a thousand directory sites. Almost none of them treat availability as a first-class, real-time field. They treat it as a contact form. So our core bet is narrow and kind of boring: surface real availability before the first message, and let a couple book a date-matched vendor on the spot with a secured deposit.

If you've built marketplaces you'll recognize the trap here — directories are easy to launch and hard to make useful, because the data rots. A "verified availability" claim is only worth anything if vendors actually keep a calendar synced. So the real product problem isn't the couple-facing search. It's giving vendors enough reason to keep their calendar honest.

What we're actually building to solve that

Instead of "list yourself on another directory," the pitch to vendors is a CRM they'd want anyway: packages, lead intake, contracts, email templates, deposit collection, invoice tracking. The availability calendar isn't a chore bolted on top — it's the same calendar that gates which leads even reach them. Keep it current and you stop fielding dead-end inquiries. That's the loop we're trying to close: the data quality the marketplace needs is a byproduct of the tool the vendor uses to run their business.

We're also committing vendors to a 48-hour response guarantee, which is less a feature and more a way to set the floor on the experience that usually makes wedding planning miserable.

Open questions I'd genuinely take feedback on

• Cold-start, vendor side first vs. couple side first. Weddings are seasonal and hyper-local, which makes the usual "just get liquidity" advice harder — a couple in one city doesn't care about supply in another, and they're a one-time user, not a retained one. We're leaning vendor-first (build the CRM value so the supply and the calendar data show up before couples do), but I'd love to hear from anyone who's cracked a one-shot-demand marketplace.

• Whether the CRM should be free-with-marketplace-take-rate, or paid SaaS that happens to feed a marketplace. Different incentives, different data-quality outcomes.

• How much "instant booking" couples actually want for a high-trust, high-emotion purchase vs. wanting to talk to a human first.

If you've built in marketplaces, local services, or anything with a perishable-inventory + one-time-buyer shape, I'd really value the punch-holes-in-it replies. Happy to share more about the stack or the waitlist numbers in the comments.