What Is CommishHub?
Every fall, somebody in your group of friends becomes “the commish”, the poor soul stuck collecting picks via text message, maintaining a janky spreadsheet, and manually tallying scores every Sunday night while everyone else is watching the game. I’ve been that guy. CommishHub exists because that whole process deserves to be automated into oblivion.
CommishHub is a sports pick’em pool SaaS platform built to handle the full lifecycle of a pick’em league, from pool setup and weekly pick submission all the way through automated scoring and standings. The goal is simple: let the commish actually enjoy game day instead of babysitting a Google Sheet.
Why I Built It
Pick’em pools are deceptively complex when you start pulling at the thread. You’ve got weekly matchups, user pick submissions with deadlines, tiebreaker logic, dynamic standings, multiple pool configurations, and the ever-present edge case of the late-submitting guy who swears he picked the right team. Building this the right way meant treating it like a real product, not a weekend hack.
This was also a deliberate challenge for me on the full-stack side. I’m a self-taught IT guy who spent the better part of three decades deep in Exchange and Active Directory. React and TypeScript are still relatively new territory for me, and CommishHub gave me a reason to get serious with Next.js and push into PLpgSQL for the database layer, which is where the real logic lives.
The Stack
CommishHub is built on Next.js (TypeScript), which handles both the frontend and the API layer cleanly under one roof. I’m using PLpgSQL on the database side, stored procedures and functions inside PostgreSQL, which means the heavy lifting for scoring logic, standings calculations, and pick validation happens at the database level where it belongs, not scattered across application code.
The whole thing runs containerized via Docker, which keeps deployment clean and repeatable. CSS handles the styling without a lot of ceremony, I’m more interested in the data layer working correctly than pixel-perfect animations.
What’s Interesting About the Approach
Most people building something like this would dump all the business logic into API routes and call it a day. I leaned into PLpgSQL specifically because:
- Scoring and standings logic benefits from set-based operations; SQL is genuinely better at that than looping through arrays in JavaScript
- Keeping rules at the database layer means they’re enforced consistently regardless of how the data gets touched
- It forced me to actually “try to learn” PL/pgSQL, which was the point
Next.js was a natural fit here, the App Router architecture keeps the project organized in a way that scales and having server components alongside client components means I’m not over-fetching data on the frontend.
Current Status
CommishHub is actively in development. The core pick submission flow, pool management, and standings engine are the primary focus right now. This one’s being built to actually use, I’ve got people lined up who are tired of the spreadsheet life just like I was.
Landing site will be provided as soon as the product is ready to launch.
