Spontus

The hard part was not creating listings. It was making teams and sponsors trustworthy enough to transact.

Spontus connects college club sports teams with sponsors through structured team profiles, sponsor profiles, sponsorship listings, applications, and review workflows.

My work focused on turning the marketplace into an executable system: canonical domain language, trust states, verification gates, schema planning, security automation, and demo continuity.

40 commits by Brian at review timemerged auth + verification systemSupabase/RLS schema foundation in progressoffline demo flow restored

This project appears under Projects on my resume.

Spontus product screenshots are being sanitized; the case study currently uses source-linked workflow evidence.

Trust-to-transaction flow

  1. 01team .edu signup
  2. 02sponsor work email
  3. 03profile completion
  4. 04manual verification
  5. 05application review

Verification gates turn listings into credible opportunities.

The core product work connects business risk to technical controls: identity checks, profile completion, verification state, schema boundaries, and workflow automation.

  1. Team signs up with .edu
  2. Sponsor uses work email
  3. Profile completion
  4. Manual verification
  5. Verified marketplace access
  6. Application review
Business riskTechnical control
Fake team.edu validation + verification status
Untrusted sponsorwork-email validation + sponsor verification
Premature database exposureSupabase RLS/schema foundation
Fragile demooffline seeded fallback
Repo driftCI, security, workflow checks
canonical domain modelMVP build slicesverification status providerprofile completion testsSupabase schema directionsecurity workflow gates

The first product decision was language.

Domain model before code

Spontus needed a shared vocabulary before the UI could be trusted: Teams, Sponsors, Sponsorship Listings, Applications, Deals, Deliverables, Proof, and Contacts. That model gave product specs, database planning, and implementation slices one map.

  • The domain model defines marketplace entities and lifecycle states before final schema details.
  • MVP build slices sequence the product into team profile, sponsor listing, application, sponsor review, and admin verification loops.
  • The backend plan keeps payments, matching, and CRM depth out of the MVP so trust workflows can ship first.

A listing marketplace fails if anyone can look legitimate.

Verification as marketplace trust

PR #12 added team .edu validation, sponsor work-email validation, profile completion, verification status tracking, and application gating. The goal was not just form validation; it was making access depend on explicit trust states.

  • Teams and sponsors enter different signup paths with different email-domain expectations.
  • Profiles move through draft, submitted_for_verification, verified, needs_changes, and suspended states.
  • Application flows check verification status so unverified sides cannot bypass the marketplace trust layer.

An MVP still needs guardrails.

Operational foundations

The repo work pairs product velocity with operational discipline: community docs, PR quality gates, workflow linting, security review, Supabase schema direction, UUIDs, RLS policies, audit triggers, contacts, and advisory quality-review automations.

  • PR #10 established repo-quality and security tooling around contribution and workflow hygiene.
  • PR #24 restored offline seeded demo behavior when Supabase was unavailable.
  • PR #31 adds schema and security workflow foundations, including RLS direction and advisory workflow gates.

Marketplace trust is a system, not a screen

The artifact follows both sides through identity checks, profile completion, verification, listing access, and application review.

TeamSponsor
VerificationListingApplicationReview

Short excerpts that show the design choices.

Snippets are trimmed for readability and paired with the source file they came from.

spontus/src/components/providers/verification-provider.tsx

Verification transition guard

tsx
const SUBMITTABLE_STATUSES = ["draft", "needs_changes"];

if ((status === "needs_changes" || status === "suspended") && !note) {
  return;
}

Verification is modeled as a guarded workflow: only specific states can resubmit, and negative review states require a reason.

spontus/src/components/providers/applications-provider.tsx

Offline seeded application path

tsx
if (!isSupabaseConfigured) {
  setApplications((prev) => [
    ...prev,
    createSeededApplication(listingId, teamId, fitNote),
  ]);
}

The MVP stays demoable when Supabase is unavailable, preserving create/review flows instead of letting infrastructure state break the product story.

spontus/supabase/schema.sql

Schema starts with trust boundaries

sql
CREATE TABLE sponsorship_listings (...);
CREATE TABLE applications (...);
ALTER TABLE teams ENABLE ROW LEVEL SECURITY;
ALTER TABLE sponsors ENABLE ROW LEVEL SECURITY;

The database foundation tracks marketplace entities directly and treats access control as part of the schema direction, not a frontend-only concern.

What this project proves.

Spontus shows that marketplace engineering is trust engineering. The product only works if identity, eligibility, data access, and workflow boundaries are explicit enough for both teams and sponsors to act on.

Contact