What you'd be working on
Blowout Draft is an NFL pick'em scored on margin of victory — one team a week, each team only once a season, and your worst loss is forgiven. It has been running since 2014, and the site you're reading is the second version of it: a complete rewrite of the original 2014-era app, with every one of those twelve seasons migrated into it. Real leagues, real history, real people who notice when a scoreboard is wrong.
That's the appeal and the constraint at once. It's a small enough codebase to hold in your head, and it has enough history that decisions have consequences. If you've been looking for something more interesting than another to-do list app, this is a genuine one.
The stack
Current, and deliberately unexotic:
- .NET 10 and C#, with Blazor Server for the front end
- ASP.NET Identity for accounts, including passkeys and two-factor
- Entity Framework Core over SQL Server
- Bootstrap compiled from SCSS, Font Awesome, and hand-written CSS — no component library
- xUnit and Shouldly, with bUnit for components — roughly 840 tests, and they stay green
- GitHub Actions into Azure App Service deployment slots
The layering matters more than any individual choice: pages are thin, services own the business logic, and providers own everything external. A page reaching into the database directly is a bug, not a shortcut.
Where the work is
There's a real backlog, and it spans the full range from an afternoon to a genuine design project:
- Features from the queue. Concrete, specified work that just needs building — navigation improvements, admin surfaces, a historical snapshot viewer.
- Bugs and polish. The best way in. Small, self-contained, and you'll learn the codebase properly by fixing something in it.
- The parked areas. A playoffs track exists in the domain model but has no interface and several genuinely open questions about how it should work. A stats section is planned and unstarted. If you'd rather shape a feature than implement one, these are where to look — expect a conversation about the design, not a ticket.
Tell us which of those sounds like you and we'll point you at something real rather than leaving you to guess.
How we work
Worth knowing before you decide, because these aren't negotiable and they're not to everyone's taste:
- Commit messages carry the reasoning. A subject line saying what changed, then a body explaining why — which rule is being protected, why the obvious approach was rejected. The history is documentation here and it's expected to read like it.
- Comments explain reasoning, not mechanics. Nothing that restates the code. Plenty about why a legacy scoring rule is preserved exactly as it is.
- Everything arrives by pull request, on a branch named for the work, with the build and the full test suite gating the merge.
- Scoring rules are era-dependent and load-bearing. The drop rule changed in 2017, and seasons before that still score the old way. Historical scoreboards must not move.
Getting the source
The repository is private, and access is granted per person on request — it holds the migrated history of real leagues, so it isn't something we hand out automatically. Ask using the form below and tell us a little about yourself: what you've worked on, what you'd like to pick up, and your GitHub username so we have somewhere to send the invitation.