A two-sided marketplace for professional pickleball sponsorships, built from scratch in one month.

Professional pickleball is growing fast, and brands want access to its athletes. But connecting the two sides and managing the deals that follow is almost entirely manual work.

An athlete gets interest from a brand. Someone negotiates terms over email or DMs. Deliverables get discussed in a thread, submitted somewhere, and reviewed somewhere else. Payment happens through a separate invoice or payment link. Tracking which deals are active, which need follow-up, which are waiting on content, and which are waiting on payment means juggling spreadsheets, inboxes, and messaging apps.

It works at small scale. It does not scale. Every new athlete and every new brand multiplies the coordination overhead, and the person managing it all becomes the bottleneck.

The client needed a system where athletes and brands could operate directly: discover each other, post and apply to opportunities, negotiate, submit and approve content, and handle money, with administrative oversight for quality control and high-value deals.

Every sponsorship moves through a defined sequence of states, and the platform enforces the rules at each transition.

A deal can originate from a brand accepting an athlete application to a posted opportunity, or from a direct offer that both sides have negotiated and accepted. Either path produces the same deal record with the same downstream workflow.

From there, the platform generates a contract dynamically from the deal terms using database-backed templates, so each engagement gets its own contract document without manual assembly. The brand reviews and signs the displayed terms, advancing the deal into work-in-progress.

The deal then moves through content submission, brand review, revision cycles when needed, content approval, payment, payout, and completion. Deals can also be cancelled, refunded, or reversed depending on where they are in the lifecycle.

Every state transition is recorded in an immutable event timeline attached to the deal. The platform captures what happened, when, and who initiated it, creating a permanent audit trail that cannot be edited or deleted after the fact.

Payments were the most complex part of the build, and the area that required the most thorough testing.

Brand payments flow through Stripe Checkout after content is approved. Athlete payouts flow through Stripe Connect, with the platform fee subtracted before the transfer. Each payout uses a deal-specific idempotency key so a retry can never accidentally double-pay an athlete.

A checkout session can expire before the brand pays. A brand can request a cancellation after paying but before the athlete is paid out. A brand can request a refund after the athlete has already been paid, which means the transfer has to be reversed before the refund can process. A refund can fail, and the retry has to use a new idempotency key because reusing the failed one would replay the failed result from Stripe. A payout can fail if the athlete connected account has an issue.

Each scenario follows a distinct recovery path. Checkout sessions are reserved and reused to prevent duplicate payment sessions. Webhook events are processed through replay-safe database functions so redelivered events do not create duplicate state changes.

Athletes appear on a public roster that brands can browse without an account. The roster supports filtering by name, niche, and social reach, with individual profile pages showing biography, categories, pricing, availability, and a call to action for direct offers.

On the athlete side, opportunity alerts are personalized using matching tags, minimum compensation preferences, and favorite brands, so athletes get notified about opportunities that actually fit.

Matching is rules and filter based, not AI-assisted. The platform connects athletes and brands through structured search, filtering, and preference matching rather than algorithmic recommendations.

The platform enforces permissions at every layer, not just the UI.

Route-level guards direct users to the correct portal based on their role. Server-side actions independently verify authentication and authorization on every request rather than trusting page routing alone. Supabase row-level security policies ensure database queries only return data the requesting user is permitted to see.

Deal records are isolated to their athlete, brand, and assigned administrator. Offer threads are visible only to their participants plus administrators. Direct database mutation is revoked from standard authenticated clients, so sensitive deal transitions go through atomic server-side functions rather than browser-initiated writes.

Account approval is required for both athletes and brands before they can participate in real marketplace activity. Applications, offers, and deal creation are all gated on approved status at the database level.

The platform generates email notifications across the entire deal lifecycle: new signups, account approvals and rejections, new applications, matching opportunities, application decisions, flagged deals, review decisions, content submissions, revision requests, content approvals, payments, refunds, failed refunds, transfer reversals, payout issues, disputes, and payout failures.

Every notification is also persisted as a database record, so the system maintains a complete history of what was communicated and when, independent of email delivery.

The hardest part of this build was Stripe integration flexibility. A marketplace payment system is not a single checkout flow. It is a web of scenarios that branch depending on timing, user action, and asynchronous webhook events.

The platform had to handle normal payments, expired checkouts, pre-payout cancellations, post-payout refunds requiring transfer reversals, failed refunds with retry logic, payout failures, disputes, and duplicate webhook deliveries. Each scenario needed its own state-transition path, and all of them had to leave the deal record in a valid, recoverable state regardless of the order events arrived.

Getting Stripe right meant building idempotent operations, replay-safe webhook processing, deal-specific idempotency keys, separate webhook signature verification for platform and connected-account events, and a cancellation pipeline that distinguishes between unpaid expirations, paid refunds, and completed deals requiring transfer reversal before refund.

Those paths are covered by the test suite: cross-tenant isolation, webhook signature rejection, duplicate checkout prevention, retry safety, refund flows, transfer reversals, and direct state-mutation denial.

The platform is built on Next.js with React and TypeScript, styled with Tailwind CSS, backed by Supabase PostgreSQL with row-level security, and deployed on Vercel. Authentication uses Supabase email/password with server-rendered sessions. Payments run on Stripe Checkout and Stripe Connect. Email notifications are delivered through Resend. Content uploads use short-lived signed URLs so media files go directly to storage without passing through the application server.

Sensitive deal transitions are implemented as atomic database functions rather than multi-step application writes. The database uses integer cents for all monetary values with nonnegative constraints, UUID primary keys, soft deletion for operational record preservation, and indexed columns for ownership, status, and timeline queries.

Pickleball Deal Room is approximately 95% complete and launching in August 2026 at pickleballdealroom.com, with 30 athletes expected at the initial roster.