Jaylan BallouDeveloper & Data Analyst
Résumé
WorkRésuméContactUpdated Oct 15, 2026

Case study N° 08 · Data

Multi-League Fantasy Pipeline

One data warehouse across Sleeper and ESPN leagues that answers the questions neither app can.

By Jaylan Ballou·Solo: design, build, deploy·Prototype, Sep 2026·1 min read

No public link

Across 2 platforms
4teams
Two Sleeper leagues and two ESPN leagues in one warehouse.
raw → stg → core → mart
4layers
Plus an ops schema for the job queue, rate limiting and data-quality logs.
For both platforms
1core model
Sleeper and ESPN quirks stay in connector modules; nothing downstream knows the source.
SOURCESINGESTPOSTGRESAPPSleeper API2 leaguesESPN API2 leaguesEdge FunctionsDeno connectorsnormalizationpg_cron queuebackoffrate limitsopsWarehouserawstgcoremartNext.js dashboardexposurestart/sitroster holes
Fig. 1|How the data moves. Connectors are the only code that knows which platform a row came from; everything from core onward is shared.

What it is

A decision-support dashboard across 4 fantasy football teams in 2 Sleeper and 2 ESPN leagues. It shows true cross-league player exposure, conflicting start/sit calls, roster holes across teams, and schedule luck.

Highlights

  • Medallion-style layering in Postgres: raw → stg → core → mart, plus an ops schema for the job queue, rate limiting and data-quality logs.
  • Platform-agnostic core. All Sleeper and ESPN quirks live in connector modules. Nothing downstream knows which platform a row came from.
  • Tested normalization (names, players, scoring, lineup slots, transactions) in TypeScript, shared by the ingest Edge Functions and the web app.
  • A job queue driven by pg_cron with backoff and auth-failure reporting, and documented findings wherever the real API behavior differed from the spec.

Methods

Stack
Supabase Postgres, pg_cron, Supabase Edge Functions, Deno, TypeScript, SQL, Next.js.
Data
The diagram is redrawn from the shipped code. No real records are shown.
Status
Prototype, Sep 2026. 4 teams across 2 platforms.