NFL Survivor Pool Platform Private Production Application
Cartier Suicide Pool
A production NFL survivor pool that runs itself. Once the season starts, deadlines, score finalization, grading, eliminations and reminders all happen automatically for hundreds of entries, with no admin intervention.
- Role
- Founder, pool operator and sole developer
- Product type
- Authenticated web application + Web API
- Platform
- ASP.NET Core 8 MVC and Web API, SQL Server
- Status
- In production for 15 years, fully automated through the season
Overview
Cartier Suicide Pool runs an NFL survivor pool. Each week, every entry picks one team to win outright. If the team wins, the entry survives to the next week. If it loses, the entry is eliminated. An entry can never use the same team twice, so every pick spends a resource that is gone for the rest of the season. From Week 8 on, each entry must pick two teams a week, and both have to win.
The defining feature is that the pool runs itself. Once the season starts, no one has to step in. Pick deadlines lock automatically, scores are finalized as games end, every entry is graded and eliminations are recorded, odds refresh during the week, and reminder emails go out on schedule, all without admin involvement.
The site has been running for 15 years. It began as a classic ASP website with inline SQL and evolved through ASP.NET and MVC into the ASP.NET Core 8 application it is today.
I built the application and I run the pool. Participants can hold multiple entries, follow their own survival alongside the whole pool's, and use NFL schedules, standings and betting lines without leaving the site. The product is designed so that anyone could run a pool on it.
The problem
The pool existed before the software did. Its original organizer ran it on Excel spreadsheets, tracking every entry, pick and elimination by hand. As the pool grew, the number of entries outgrew what a spreadsheet and one person could manage, and the pool was going to shut down unless someone built a website to run it. That's where I stepped in.
A survivor pool sounds simple until it reaches hundreds of entries. Every week, each entry's pick has to be validated against the teams that entry has already used and against kickoff deadlines that differ between Thursday, Sunday and Monday games. After the games, every pick has to be graded and every elimination recorded correctly.
Participants also want more than a pick form. They want to see how the rest of the pool picked, how many entries are still alive, the week's schedule and point spreads, and reminders before deadlines. Doing all of that by hand each week doesn't scale and leaves too much room for error. The goal was a pool that needs no weekly administration at all: set it up before the season, and it runs on its own until a winner is left.
My role
I designed, built and operate the entire system: the participant experience, the rules engine, the API, the database, the scheduled automation that runs the season without intervention, and the administrative tooling. I applied ChatGPT and Claude Code to implementation, debugging, automation, UX refinement and ongoing enhancement, while the design and the rules engine remain my responsibility.
- Product design and rules modeling
- Application architecture
- SQL Server database design
- ASP.NET Core MVC front end
- Web API development
- Background job design
- Third-party data integration
- Email delivery and tracking
- Testing
- AI-assisted development (ChatGPT, Claude Code)
- Pool operations and support
Key capabilities
Hands-off season automation
- No admin intervention needed once the season starts
- Pick deadlines and early-game cutoffs enforced automatically
- Scores finalized automatically as games end
- Every entry graded and eliminations recorded automatically
- Point spreads refreshed throughout the week
- Thursday pick processing and weekly reminder emails on fixed schedules
Participant experience
- Authenticated accounts and personal dashboards
- Multiple entries per user
- Weekly pick cards showing kickoff times and point spreads
- Pick changes allowed until the deadline
- Live countdowns to early-game and Sunday deadlines
- Separate desktop and mobile interfaces
Survivor rules engine
- Prevents an entry from reusing any team it has already picked
- Two picks required per week starting in Week 8, and both must win to survive
- Separate early-game cutoffs for Thursday and other early kickoffs
- Deadline enforcement on every pick change
- Weekly grading and elimination logic
- Survivor statistics per entry and across the pool
NFL data and analytics
- Weekly NFL schedule with networks and venues
- Full-season schedule and record for each team
- NFL standings
- Weekly pick-distribution summaries, revealed after the deadline
- Pool-wide entries, survivors and eliminations
Administration and communications
- Participant, entry and pool configuration management
- Automated weekly game processing with built-in exception handling
- Broadcast email to participants
- Per-recipient delivery status and bounce handling
- Login history and system configuration
Technical architecture
-
Web application
An ASP.NET Core 8 MVC application renders the participant and admin experience with server-rendered Razor views, plus separate handling for desktop and mobile layouts.
-
Web API
A separate ASP.NET Core 8 Web API project provides the pool's data and operations behind JWT-secured endpoints, documented with Swagger/OpenAPI.
-
Service layer
Business rules such as pick validation, the one-use-per-team rule, deadlines, grading and elimination live in services, separate from controllers and views, so they can be tested directly.
-
Data
A SQL Server database tracks users, entries, picks, weeks, teams, schedules, standings, login history, system configuration, broadcast messages and per-recipient delivery status.
-
Background processing
Hangfire recurring jobs run the season with no manual steps, on Eastern-time schedules. Score finalization checks every minute but only calls the scores API for games that kicked off at least three hours ago and haven't been processed yet, with grading following automatically. Odds sync every three hours from Tuesday to Friday, and Thursday pick processing and weekly reminder emails run on fixed schedules.
-
Integrations
NFL schedule and results data come from ESPN data feeds, and point spreads come from The Odds API. Email is sent over SMTP with MailKit.
-
Testing
Unit and integration test projects cover the API and MVC application using MSTest and xUnit, with EF Core in-memory and SQLite providers for data-layer tests.
Interesting engineering challenges
A season that runs itself
The most important requirement was that the pool should never wait on a person. Deadlines are enforced by the application itself the moment they pass. Every other recurring task in an NFL week is a scheduled job timed to the NFL calendar in Eastern time: score finalization, grading and elimination, odds updates, Thursday pick processing and reminder emails. Once the season is configured, it runs from Week 1 to the final survivor without admin intervention.
Survivor eligibility: each team only once
Each entry's eligible teams shrink every week. The pick screen marks the teams an entry has already used, labeled with the week they were picked, and they can't be selected again. Each entry is tracked separately, so one participant's four entries can follow four different paths through the season.
Two picks a week from Week 8
Starting in Week 8, every surviving entry must pick two teams, and both have to win for the entry to survive. That doubles the rate at which each entry uses up its teams just as the remaining choices get thin, and it touches almost every part of the system. The required number of picks is stored per week, not hard-coded. The pick screens on desktop and mobile collect and validate two selections, both checked against the one-use-per-team rule and the game deadlines. Grading eliminates an entry if either pick loses. Dashboards show both teams. Pool statistics count entries rather than individual picks, so the numbers stay accurate, and reminder emails tell participants how many picks are required that week.
Deadlines that depend on the game
NFL weeks don't have a single kickoff. Thursday night and other early games lock earlier than the Sunday slate, so the application models early-game cutoffs separately from the main deadline. It enforces both whenever a pick is made or changed, and shows live countdowns to each so participants always know how long they have left.
Fifteen years of continuous evolution
The first version was a classic ASP site with SQL written inline in the pages. It worked, and it saved the pool, but every rule lived wherever it happened to be written. The application then moved to ASP.NET, and that transition is where the separate API project began, pulling data access and pool logic out of the pages. Next came MVC, and then ASP.NET Core 8. The API kept evolving at each step, all while the pool kept running every season. The current version pairs an ASP.NET Core 8 MVC front end with that Web API, keeps the survivor rules in a testable service layer, and runs the weekly work as Hangfire jobs instead of manual steps or standalone scheduled tasks.
Moving scheduled work into the application
Thursday pick processing and the weekly reminder emails began as standalone .NET Framework scheduled tasks. They now run as Hangfire recurring jobs inside the ASP.NET Core 8 API, alongside score finalization and odds synchronization. All of the pool's scheduled operations now share one codebase, one configuration and one dashboard, and the schedules are defined in Eastern time to match the NFL's.
Grading reliably, every week
Scores have to be final before anyone is eliminated. A lightweight score-finalization job runs every minute, but it only reaches out to the external scores API when a game kicked off three or more hours ago and hasn't yet been marked as processed. Most runs make no external calls at all. Once a game's final score is recorded, the game is marked processed and never fetched again, and participant grading works from those finalized scores automatically. Exception handling is built into the weekly processing, so grading doesn't depend on anyone checking results.
Communicating with a large seasonal audience
Broadcast email goes to every participant in the pool. Each message records per-recipient delivery status and handles bounces, so the operator knows who actually received a deadline reminder, not just that one was sent.
Screenshots
Select any screenshot to view it full size. Participant information has been removed.
-
Participant dashboard: entry cards, personal and pool-wide survival, and countdowns to each pick deadline. -
Weekly pick: teams this entry has already used are locked and labeled with the week they were picked. -
NFL schedule grouped by kickoff window, with networks, venues and point spreads. -
Team view: full season schedule, final scores and records. -
NFL standings by conference and division. -
Pool summary: entries still alive and eliminations by week. -
Weekly summary: pick distribution across the pool, revealed after the deadline. -
How Many Picked: picks per team per week, results, and how many entries can still use each team. -
My Picks: every entry's pick history, week by week. -
Still Alive: surviving entries and whether this week's pick is in. Entry names blurred. -
Admin: broadcast email with recipient filters, such as entries with no pick this week. Recipients blurred. -
Admin: broadcast history with per-message delivered, bounced and rejected counts, including the automated weekly reminders.
-
Mobile dashboard: pick deadline and swipeable entry cards. -
Making a pick on a phone, with spreads and kickoff times. -
Weekly NFL schedule grouped by kickoff window. -
Team schedule with record and point spreads. -
NFL standings with conference tabs. -
Pool summary on a phone. -
Weekly summary: pick distribution and results. -
My Picks on a phone. -
How Many Picked on a phone. -
Admin broadcast email works on a phone too.
Technologies
- Application
- Data
- Processing
- Integrations
- Testing
- AI-assisted development
Outcome and current status
Private Production Application In production for 15 years, fully automated through the season
- Admin steps needed once the season starts
- 0
- After kickoff before a game's final score is fetched, once
- 3 hrs
- Entries graded automatically each week
- Hundreds
In production for 15 years and still running every NFL season, supporting hundreds of participant entries. The pool that was about to close because it outgrew its spreadsheets is still going. Once the season starts it runs without intervention: deadlines, scoring, grading, eliminations, odds and reminders all happen on their own, every week.
Access is by invitation, so the product is shown here through sanitized screenshots and an architectural walkthrough rather than a public login.