Building a better way
to book a wedding.

Wedding planning has too many disconnected tools.

Couples coordinate vendors across websites, emails, and spreadsheets. Vendors rely on costly lead platforms and separate tools to run their businesses.

Our hypothesis was that connecting discovery, communication, booking, and business management could deliver value to both sides of the marketplace.

As co-founder and Chief Product Officer, I lead product strategy and own the majority of the product design and production implementation. I work with my co-founder Min on business and product direction, and have used AI-assisted development extensively to build, operate, and evolve the live platform.

Learning from couples
and wedding vendors.

Before launch, we conducted approximately ten moderated usability sessions with couples and wedding vendors.

In 60-minute sessions over Google Meet, participants completed key marketplace and booking tasks. We observed friction, asked questions, and refined workflows, navigation, and product priorities.

These sessions helped us refine the marketplace and booking workflows during development. We continued testing major workflows with customers before including them in the MVP.

Choosing the first
booking workflow.

The feedback reinforced our focus on a connected booking journey. With more ideas than time and resources, we prioritized discovery, communication, booking, and payment so couples and vendors could complete the core workflow in one place.

The product connected workflows that are often fragmented: finding a vendor, starting a conversation, confirming a booking, making a payment, and managing the relationship afterward.

Making it easier
for vendors to join.

After launch, signups were slow. We changed our approach to make it free for vendors to join, with an upgrade for direct booking and additional functionality.

The original product centered on direct booking. Slow signups prompted us to reconsider what vendors needed to commit to before they could get value from the marketplace. We separated participation from the fuller booking product: vendors could start with a listing, inquiries, and messaging, then choose whether to upgrade.

Slow signups gave us a reason to test a lower barrier to entry; they did not establish why people were not joining. We are now watching signup and upgrade behavior to learn whether the free-entry model helps. Improved conversion has not yet been established.

Helping vendors understand
what the product can do for them.

The vendor landing page connects a free listing with the practical work of running a wedding business.

I designed the page around a product walkthrough: a dashboard overview, storefront management, conversations with couples, and upgraded calendar and payment tools. The sequence makes the capabilities visible before asking vendors to sign up.

A demo, founder introductions, and invitations for different vendor specialties give the page a more personal introduction to the business. Free and upgraded capabilities are distinguished throughout the experience.

Designing the booking
from request to payout.

Direct booking became one of the clearest examples of design and engineering converging. A couple checks availability and authorizes payment; the vendor receives the request and confirms or declines; confirmation captures the payment and creates the messaging relationship; scheduled jobs later release the vendor payout.

Underneath that experience, Stripe handles manual-capture PaymentIntents, Connect Express accounts, subscriptions, verified webhooks, and Transfers. Booking records retain the fee breakdown and lifecycle state so the interface and financial system stay aligned.

Explore the payment lifecycle case study

Taking the product from design to production.

Building a startup meant moving across product strategy, workflow design, content, data modeling, implementation, integrations, QA, deployment, and day-to-day operations.

I used AI-assisted development to turn product intent into production software. My background in product strategy and UX guided the work, and I owned implementation decisions, review, testing, debugging, deployment, and ongoing iteration.

That changed my relationship with the product. A booking flow was no longer only a set of screens; it was UI state, permissions, database relationships, payment state, messages, email, and failure conditions that all had to agree.

Building the system
behind the experience.

Plan Zinnia runs on React and TypeScript with Vercel and Supabase. The production system supports couples, vendors, vendor team members, and admins, with payments, messaging, subscriptions, and scheduled operations.

Julie Fennell built the initial database schema. I continued evolving it as the product expanded into listings, services, inquiries, booking, payments, team accounts, and marketplace operations. Permissions, availability, and payment state had to stay consistent across those workflows.

Keeping the marketplace running

Operating the live product meant handling expired bookings, failed integrations, message notifications, and payout timing. I built scheduled operations and internal tooling to help a small team monitor the platform and respond to failures.

AI-assisted implementation also required review, validation, security checks, and monitoring. Those practices became part of the development process as I continued improving the platform.

Explore the internal Builder, QA, Health, and Upsell agents

Building the tools to
manage the marketplace.

I designed and built Plan Zinnia’s admin experience so we could review vendor listings before publishing them. We needed a way to check submissions, approve appropriate listings, and manage account and listing status.

The admin experience also brings together usage reporting, signup and upgrade funnels, vendor management, and review moderation. These tools help us understand where people encounter friction and manage the marketplace as a two-founder team.

Launching the marketplace
and learning from adoption.

• Co-led product direction and took the experience from product strategy and UX through a live full-stack implementation.
• Built and launched the MVP with AI-assisted development, with first vendors onboarded.
• Changed the entry model in response to slow signups, making listings, inquiries, and messaging available for free.
• Validated marketplace and booking workflows through customer usability sessions.
• Accepted into Chicago startup accelerator 1871.
• Built internal agents and operational tooling to extend the capacity of a very small team.

The platform is live and early vendor adoption has begun. Free listings, inquiries, and messaging now provide an entry point, while direct booking and additional functionality are available through an upgrade. The next step is to learn how the model affects signup and upgrade behavior while continuing to harden and simplify the production system.