Short answer
RaftLabs rebuilt Wendor, an Irish wedding vendor marketplace, from scratch after an earlier prototype. Couples fill in their wedding details once, discover vendors through a scoring-based recommendation feed, and book with a deposit. Vendors manage bookings, packages, payments, leads, and automated workflows in a web CRM. Payments run on Fire, a European provider. The product is in rollout and RaftLabs still 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."
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, 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.
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.
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.
We evaluated Stripe and recommended it. When development started, Stripe didn't offer the features the product needed in its market, so Wendor stayed on 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.
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.
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 answers once. The deposit waits until 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.
Where this applies
Use this when your marketplace has to book, not just list
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.
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.
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.