Context
SportsMax is an AI-native sports search engine that lives inside a sports publisher's site. A reader asks a question — a player, a team, a recent game — and gets a composed editorial response with structured data, source citations, and contextual commerce, all rendered in the publisher's native voice and visual identity.
I was working on Ymax when SportsMax first got started. I'd help out when I had bandwidth, which was occasional at first, then much more as the work grew. My main ownership was the templated response system — four template types rendered across eight sports, with the SportRadar API mapping covering nine — but the work extended beyond that: profile cards, commerce, tickets, and more.
The query → response pattern
One query, one editorial page in return. That's the core of how SportsMax works.
The article at the top isn't pulled from a generic LLM — it's grounded in the publisher's own articles, with inline citations marking which sentences came from where. The right-rail player card surfaces height, weight, team, and position. Below the article, a sources carousel pulls in recent journalism from the publisher about LeBron specifically. At the bottom, a full career stats table renders with sortable Per Game / Total and Regular Season / Postseason toggles.
All of this is one response to one query.
And the experience doesn't stop after one query. SportsMax has conversational memory, so a follow-up question — "how did he do last season?" or "what about his contract?" — gets answered in the context of the original query. The reader can go deeper without rebuilding context every time.
The design challenge wasn't designing any single one of these elements in isolation. It was making them work together as a coherent reading experience — writing that sounds like the publisher's, structured data that supports the article without competing with it, and a final response that looks and feels like it belongs on the publisher's site, not like a separate AI tool living inside it.
I designed the query-to-response logic — a documented system that maps query types to their corresponding templates, defines what data feeds each one, and sets the response hierarchy. Different queries return different templates: "Ohtani" returns career stats, "Lakers last game" returns a box score, "Angels schedule" returns a schedule, and "NBA standings" returns a standings table. The system decides which template applies, what surfaces, and in what order.
Designing for nine sports across multiple data shapes
Defining when each template renders was one part of the work. Designing the templates to actually function across nine sports was another.
The templates had to do two things at once: render correctly across nine sports where the underlying data looks very different, and feel native to a publisher's site.
For example, a career stats table for an NBA player surfaces points, rebounds, and field goal percentage. The same template for an MLB player shows batting average, ERA, and home runs. The same kind of variation showed up across schedules, box scores, and standings. Each template had to absorb different shapes of data per sport.
Profile cards introduced a different kind of variability. Every sport has four player states (Active, Free Agent, Retired, Deceased), with conditional fields for things like Hall of Fame status. Each state has its own attribute set and ordering.
All of this came together through the API mapping. SportRadar was the primary data source, though some sports needed supplementary sources to fully populate profile cards. I went through the documentation sport by sport, tracked down the endpoints we needed for each template, and built a per-sport spreadsheet with column-by-column mappings against the API fields feeding them. That sheet became the source of truth for engineering. After validating the data, I designed the templates in Figma.
That data work meant pushing internally for the right fields, making sure we were pulling the stats sports fans actually expect to see. A template only feels real when the right stats are there.
Extending beyond editorial: commerce and tickets
The query-to-response pattern doesn't stop at editorial. Every query has a Shopping tab right next to it. Clicking through transforms the page into a shopping experience derived from what the user typed — "Buffalo Bills" returns Bills products, "Josh Allen" returns Allen products.
The shopping surface itself is a fairly standard e-commerce experience: filterable product grid, sponsored placements, product detail with multi-vendor pricing comparison. The design challenge wasn't reinventing how online shopping works. It was making the experience feel like a natural extension of the query, not a separate surface living inside the page.
Tickets work the same way. When a user queries a team's schedule, the schedule template includes a "Buy Tickets" CTA next to upcoming games. The default behavior surfaces a multi-vendor comparison modal — VividSeats, StubHub, SeatGeek, TickPick, and others — sorted by price with "Best price" indicators where relevant.
The system was also designed to flex for partnerships. A ticket seller can take over the schedule template entirely, routing the Buy Tickets CTA directly to their own flow with their branding. Even before launch, this partnership variant contributed to a signed deal with a ticket seller.
Editorial, commerce, and tickets all run on the same logic. Every response, whether it's an article, a product grid, or a ticket modal, is grounded in what the user typed.
What carries forward
SportsMax is in pre-launch, with four signed publisher deals. The templated response system is fully designed and integrated. Profile cards, commerce, and tickets are all designed and on the path to ship.