The Product Layer

The product is built on Next.js App Router with React Server Components. The route surface breaks into distinct families, each with a defined job. The diagram below shows the public, authenticated, and admin surfaces, with fan and org mode as a cross-cutting layer that applies across several of them.

Fan and org mode did not start as a cosmetic toggle. They exist because the same baseball state needs different framing for different readers. Fan mode leans toward story, readability, and cleaner narrative ordering. It makes review moments, matchup context, and challenge behavior easier to follow without forcing the user into dense operational language. Org mode pushes further toward review management, timing, modeled context, and decision-oriented detail where the product has enough evidence to support that framing.

The mode changes presentation and emphasis, not the underlying facts. There are not two separate data pipelines or two separate truth layers. Both modes read from the same challenge records and baseball state. The route resolves the view mode and shapes the output accordingly.

Fan and org mode currently affects six page route families: the home page, game pages, team index and detail, and umpire index and detail. The AI surfaces also carry audience mode into prompt construction and task-family resolution, so the conversational tone adapts alongside the page framing.

The game page is where route purpose is most visible. Pregame focuses on matchup tendencies, likely review windows, and setup context. Live focuses on challenge patterns, current review consequences, and the ongoing shape of the game. Final shifts toward postgame challenge analysis, realized swings, missed opportunities, and low-value usage review.

Many sports products flatten all three states into one page and let the user figure out which information is relevant at any given moment. A live game page should behave like a live page. A final game page should shift toward review and consequence. The state is not a filter. It is the primary context.

Once page state is explicit, the loaders, charts, and AI surfaces attached to the route can be scoped more precisely to the actual job the page is doing.

Articles are part of the product because the baseball context, review surfaces, and analytical framing the writing depends on are already here. Keeping analysis inside the same system puts it closer to the data that supports it. When an article references challenge patterns, team behavior, or umpire trends, the supporting data lives in the same product the reader is already using.

The About desk serves a different purpose. Architecture choices, modeling boundaries, product design decisions, and system documentation live here as permanent pages rather than buried in code comments or scattered dev notes. These are the articles you are reading right now.

Both desks are part of the product architecture. They are maintained and updated like the rest of the system.

The application is SQL-first and server-rendered. Server components and route handlers read from shared helpers in src/lib. Analytics pages are built from page-model helpers rather than doing route-local math in every file. Query logic and data-shaping logic live close to the server-side model of the product rather than being recreated differently in each route.

Centralizing that work also helps with consistency. When the same summary or model output appears in multiple places, there is one retrieval and shaping path rather than several that diverge over time. The browser is not treated as a trusted data or authorization layer. Product logic, data loading, and permission boundaries hold on the server side.

The current codebase serves 27 page routes and 37 API routes. Server components handle the initial data load and rendering. Client components handle interactivity, chart rendering, and AI chat surfaces. That split keeps the product responsive while keeping data integrity server-side.