Short answer
RaftLabs rebuilt Wendor, an Irish wedding vendor marketplace, from scratch after an earlier prototype. Couples fill in wedding details once, discover vendors through a scoring-based recommendation feed, and book with a deposit. Vendors manage bookings, packages, payments, leads, and workflows in a web CRM. Payments run on Fire, a European provider. The product is in rollout and RaftLabs builds it.
Engagement
The engagement
- Client
- Wendor, a wedding vendor booking startup
- Sector
- Weddings and wedding services
- Decision-maker
- Product-minded, non-technical founder
- How they found us
- A referral from the TuneClub founders
- Timeline
- Ongoing engagement; product in rollout
- What shipped
- A couples mobile app and a vendor web CRM on one backend, with deposit payments, vendor workflows, and vendor recommendations
- Team
- Backend, frontend, and mobile engineers, a project manager, and design support
- Market
- Ireland
- Service
- Wedding marketplace development
The situation
Planning a wedding means contacting a photographer, a florist, a band, a venue, and a dozen more. Each one asks the same questions: where, when, what budget, what style. Couples answer them again and again, and many of those conversations end with "sorry, we're booked that day." Some vendors don't even reply to say whether they're free on the date.
Wendor's founder wanted couples to answer once, see vendors who fit, and book them directly. Vendors would get enquiries from couples who already match — not canned-template messages from people who never chose them — and run their business from the same platform.
Wendor had an earlier app, built by another agency, that worked more like a prototype than a product. We kept the vision and the new requirements, and rebuilt it from scratch.
starting point
The booking brief
The goal was to make booking the product, not the directory listing. A couple describes their wedding once, sees vendors who fit and are actually available, and books with a deposit. The vendor runs the whole booking from the same platform.
- The directory model: vendors listed, but no way to know who was free on the couple's date
- Couples repeating the same details to every vendor, many conversations ending in "sorry, we're booked"
- Vendors answering enquiries from couples who never chose them, or never replying at all
- No shared record connecting the enquiry, the booking, the deposit, and the vendor's calendar
- Couples set up their wedding once; every enquiry carries date, location, and preferences
- Vendors commit to responding within 48 hours; faster responses lift their ranking
- Deposits move from couple to vendor through the platform when both sides confirm
- One backend connects the couples app, the vendor CRM, bookings, payments, and availability
- Vendor workflows automate confirmations, packages, deposit chases, and follow-ups
What makes a wedding booking marketplace hard
A directory that can't tell you who's free
Large wedding directories list vendors. They don't show who's available on a couple's date. Couples waste enquiries, and vendors answer leads they can't take. From the vendor's side, the mirror image is an inbox full of messages from couples who never chose them and never reply.
Wendor treats booking as the product. A couple's wedding details travel with every enquiry, vendors commit to responding within 48 hours, and a deposit secures the booking. That only works if availability, enquiries, and payments share one backend.
A payment provider that's hard to test outside Europe
Deposits move from the couple, through the platform, to the vendor. The product runs payments on Fire, a European payment provider. Staging options were limited, and the full payment flow couldn't easily run end to end without a real European bank account.
When development started, Stripe didn't offer the payment mode the product needed in its market, so we went with Fire. The integration took longer than a typical payment setup, and it's now in place.
Vendor automations that run while bookings change
Wedding vendors repeat the same steps for every booking: confirm, send a package, chase a deposit, follow up before the day. The vendor CRM automates them. Vendors write emails once, with merge fields like the vendor's name and the package description filled in for each couple.
Those workflows run in the background, triggered by booking events. That brought the complexity we expected and some edge cases we didn't: a booking that changes while a step is waiting, or two triggers firing close together. We built the workflow engine from scratch and kept polishing it until those cases behaved.
What shipped
The operating loop
One loop: a couple describes their wedding once, books a vendor who fits, and the vendor runs the booking from the same platform.
The couple books when both sides are ready
Couples set up their wedding once: date, location, and preferences. They browse a ranked feed of vendors, chat with them, compare packages, and shortlist favourites. When they book, the vendor confirms within 48 hours. The deposit is only taken, and the booking only confirmed, when both the couple and the vendor are ready on the agreed terms.
The vendor runs the business from one CRM
Photographers, planners, venues, caterers, florists, and other vendors manage bookings, packages and pricing, calendar, payments, and leads in a web portal. Workflows send the right email at the right step without the vendor touching each booking. Faster responses also lift a vendor's ranking in the couples' feed.
The call
Vendor recommendations use a scoring system, not a trained model
The founder wanted discovery to feel like scrolling reels: vendors that match the couple's wedding, one after another. The first idea was a similarity-based recommendation algorithm.
We built a scoring system instead. Each vendor is ranked from the couple's wedding profile and how the vendor behaves on the platform, including how fast they respond. It shipped sooner, and every ranking can be explained. A vendor who wants to rank higher can see what to change. A trained model needs booking data a new marketplace doesn't have yet, so it stays out until that data exists.
Common questions
Pick a payment provider with a full test environment in your market, because testing deposits and payouts end to end is where time goes. Decide what triggers each supplier automation and what happens when a booking changes mid-flow. And decide how recommendations rank suppliers before you have data, so a trained model can replace the first version later.
Yes. Wendor's earlier app was closer to a prototype than a product. We kept the founder's vision and new requirements and rebuilt it from scratch, because extending the prototype would have carried its limits into every new feature.
This page doesn't state a price. The marketplace website cost guide explains how two-sided scope, payments, and automations change the number before a build is priced.
This story fits a founder building a two-sided booking marketplace: a consumer app and a supplier-side CRM that share one set of bookings, payments, and availability. It's the wrong reference if you only need a directory of listings, or if an off-the-shelf booking tool already covers your suppliers' workflow. A comparable wedding marketplace development engagement should start with the background work: what triggers each automation, and how payments get tested end to end in your provider's region.
Related work
Related marketplace and booking work
TuneClub creator-led music learning app
A creator-led music learning platform for Irish traditional music, built over two years across four releases. 48,100 tracked practice minutes, 100+ learners, and a subscription model built on RevenueCat rather than raw store APIs.
City Break Apartments booking and keyless app
A branded booking website with RMS Cloud integration and a Bluetooth keyless mobile app for City Break Apartments in Dublin, cutting 20+ staff hours per week and growing self check-ins from fewer than 10 to 72+ weekly.
Snelweg Deals car marketplace
A digital vehicle marketplace with a guided seller form, real-time dealer bidding, Dutch number plate lookup, and automated invoicing through Moneybird.