OpenField

The Problem with Marketplace Schemas

Marketplace logic required handling many-to-many athlete ↔ brand relationships, multiple deals per athlete, deliverables per contract, state-specific NIL rules, escrow payment flows, and contract revisions + signatures. A bad schema would break compliance or payments.

Core Tables

• Athletes — profile, university, sport, follower counts, state
• Brands — category, campaign budget, targeting criteria
• Campaigns — brand-owned, with eligibility filters and deliverable specs
• Deals — join between Athlete ↔ Campaign, with status state machine
• Contracts — 1-to-1 with Deal, stores DocuSign envelope ID and template used
• Deliverables — 1-to-many with Deal, tracks submission + approval
• Payments — 1-to-many with Deal, mirrors Stripe Connect payment intents
• ComplianceRules — 1-to-many with University, enforces school-specific NIL policies
• StateLaws — 1-to-many with ContractTemplates, maps state → correct DocuSign template

Key Relationships

• Athlete ↔ Deals (1-to-many) — one athlete can run multiple active deals
• Brand ↔ Campaigns (1-to-many) — one brand runs multiple campaigns simultaneously
• Campaign ↔ Deals (1-to-many) — one campaign can match many athletes
• Deal ↔ Contract (1-to-1) — every deal has exactly one binding contract
• Deal ↔ Deliverables (1-to-many) — contract can require multiple deliverables
• Deal ↔ Payments (1-to-many) — milestone-based escrow releases
• University ↔ ComplianceRules (1-to-many) — school-specific eligibility constraints
• StateLaw ↔ ContractTemplates (1-to-many) — 19 state NIL laws mapped to DocuSign templates

Why This Mattered

• Enabled automated contract generation — state + university determines template, no manual selection
• Supported escrow payment states — payments locked to deal status transitions
• Prevented illegal NIL deals — compliance rules enforced as foreign key constraints, not app logic
• Allowed live marketplace queries without race conditions — deal state machine uses row-level locking

Matching Signals

• Sport — brand category alignment (e.g. apparel brands prioritize team sport athletes)
• Follower count — brand campaign tier requirements (micro, mid, macro)
• Location — geo-targeted campaigns, state law compliance gate
• Brand category — athlete audience demographic fit
• NIL state law compliance — hard filter, ineligible athletes excluded before ranking

Result

• 67% match-to-deal conversion rate across all brand campaigns
• 78% of athletes receive at least one offer in their first week on the platform

How It Works

• 19 state NIL law templates pre-authored and stored in DocuSign template library
• On deal acceptance, system looks up athlete's university → state → correct template
• Populates dynamic fields: athlete name, brand, deliverables, payment terms, exclusivity clauses
• Sends envelope via DocuSign API to both parties for e-signature
• Contract status synced back to Deal table via DocuSign webhook

Compliance Enforcement

• NCAA eligibility rules and university-specific policies stored in ComplianceRules table
• Checked at match time — non-compliant athletes never surface to brands
• Schema-level enforcement prevents deal creation for ineligible athletes regardless of app logic

Escrow Flow

• Brand funds deal upfront — Stripe payment intent created, held in escrow
• Funds released to athlete Stripe Connect account on deliverable approval
• 85/15 split: 85% to athlete, 15% platform fee retained automatically
• Milestone deals: multiple payment intents per deal, each tied to a Deliverable row
• Zero payment disputes across all processed deals

Stack

• Next.js frontend — athlete profiles, campaign browsing, contract status, payment tracking
• Node.js API — marketplace logic, deal state machine, DocuSign + Stripe integrations
• PostgreSQL — normalized relational schema with referential integrity
• Redis — marketplace search query caching (88% hit rate)
• Docker + AWS ECS — containerized services with auto-scaling
• S3 — signed contract PDF storage and deliverable asset uploads