Fantasy Football Draft Assistant

02.1 /

Keeping up with picks

Official draft platforms already provide their own player rankings and track which players have been picked and which are still available. What they do not offer is much control over how you can organize and apply your own rankings, research and opinions. To make up for that, I had been building increasingly detailed Excel spreadsheets to use as my personal cheat sheet.

My spreadsheet let me organize rankings for more than 300 players, track my research and distribute the information I cared about across a handful of tabs. Over the years, I kept refining the template and adding formulas to save a few seconds and reduce the mental effort required between picks.

One of my biggest improvements was making a single letter trigger a series of updates. An "X" next to another team's pick would gray out and strike through that player. Adding my first initial, "J," to one of my own picks would highlight the player, add them to a separate My Team tab and update the position and bye-week counts on the main spreadsheet. That made it much easier to understand the state of my team without updating the same information in several places.

But no matter how efficiently I organized the spreadsheet, it was still difficult to keep up once a draft began. I would move back and forth between the official draft platform and my spreadsheet, trying to review notes while also tracking each new pick. If I fell behind, too much of the time before my next selection went toward catching the spreadsheet back up instead of deciding who I wanted to draft.

I knew I could continue improving the spreadsheet, but the returns were getting smaller as I ran into the limits of using Excel for the job. That became especially clear after one of my leagues reduced its draft clock to only 30 seconds per pick, with many league mates making their selections even faster. That's when I realized the next meaningful improvement required moving beyond the spreadsheet.

I had considered trying one of the paid fantasy draft assistant tools already available, but I did not want to pay for something before knowing whether I could shape the experience around my own rankings, research and workflow. With Claude Code making it practical to build a working app quickly, this felt like a good opportunity to turn the custom draft assistant I had been thinking about into something real.

02.2 /

Defining the experience

The first thing I wanted to find out from Claude was whether the draft assistant could connect to a live draft feed and handle pick tracking automatically. Claude thought it should be possible, but I was not confident every platform would make the connection reliable enough to depend on, so I planned to include manual controls as a fallback. Either approach would let me spend more of the draft reviewing my notes and deciding who I wanted next instead of maintaining the tool.

With that question tentatively answered, I started mapping out what I wanted my custom draft assistant to do.

I already had the basic structure in mind before asking Claude Code to turn it into an interface. I combined elements I liked from existing draft platforms with ideas from the spreadsheet I had been refining, then documented the functionality, structure and general UX direction in a Word document to share with Claude as a starting point.

Because I started the project so close to my first draft, I had to prioritize structure and functionality over visual styling. I organized the experience around a main dashboard-style view that surfaced the information I expected to use most often, with deeper information and settings one click away in modals.

An Available Players list would anchor the main view, with position filters and search to help narrow the pool or locate a player quickly. Each card would surface the information I wanted most often at a glance, while selecting a player would open a profile with deeper notes and research.

The cards prominently displayed color-coded tags representing my own player research, and I included a Targeted Players section to bookmark players I was considering for upcoming picks.

Above the list, I planned two quick-reference areas. One would track the live draft's progress by showing the current round and pick, who was on the clock and how many selections remained before my next turn. The other would carry forward an idea I had found useful in my spreadsheet by showing my team's position counts, bye-week distribution and how many roster spots I still had left to fill.

Because I only needed to see my full roster occasionally, it did not earn permanent space on the main view. Instead, selecting the position and bye-week counts would open a My Team modal, making that summary a natural entry point to the players behind it.

Just as important, I wanted the UI to support my preparation before draft day without creating a separate prep experience. The same interface I would use during the draft could also let me manage rankings, notes and tags ahead of time, keeping the way I prepared the information closely connected to how I would eventually use it. It also meant I could make last-minute changes before or during the draft if necessary.

02.3 /

From plan to prototype

Because of the limited time I had to build the app and troubleshoot the live feeds, I skipped translating the plan into traditional Figma wireframes and moved directly into Claude Code. With my past wireframing experience, I was comfortable describing the structure, behavior and priorities in enough detail to move straight into something functional I could test and react to.

I started by asking Claude to review the planning document and interview me about anything that was still unclear or missing. After working through those remaining questions, I refined the requirements and asked Claude to build the initial version as a React Artifact.

I kept the initial creative direction intentionally light, focusing first on getting the structure and functionality working before refining the styling. Most of my guidance focused on usability, including comfortable spacing and controls large enough for touch devices. I also provided direction around placement and ordering, but gave Claude room to establish the initial styling and suggested using the Sleeper app as a loose visual reference if helpful.

Claude handled the code and took the lead on much of the initial styling, while I continued directing the structure, hierarchy, sizing, positioning, functionality and other details throughout the build. I provided color direction and visual feedback along the way, but the process let me spend less time defining every detail up front and more time refining how the app actually worked.

The interface came together quickly. I had a solid working version in roughly a day and a half, followed by another day of refining and testing the experience. Because I knew I would be adding a significant amount of prep work, including rankings and notes, without relying on a server to store it, I planned early on for a way to back up and restore that information. I also added a separate draft reset that could clear pick activity without wiping out the preparation I wanted to keep. From there, most of the remaining time went toward getting the live draft connection working.

02.4 /

Designing for speed

A fantasy draft can move fast, and I knew there would be moments when I had only a short window to compare my options, check my notes and decide who I wanted to draft.

I made sure the information hierarchy reflected that. Within each player card, I used the left edge to anchor the information I needed to scan fastest. The player's name carried the most visual weight, followed by a bold positional rank tile. Because the list itself was already sorted by overall rank, the positional rank helped me compare players across positions while still understanding where each stood within their own position group.

Team, bye week, strength of schedule and projected points stayed on the same line in a quieter style because they were more useful for breaking ties than driving the initial decision.

The color-coded icon tags I developed sat on their own row so they remained easy to scan without competing with the core player information, while also leaving enough room for the number of tags to vary from player to player.

The color and icon system became another way to reduce how much I had to read. A player I loved, liked, wanted to avoid or considered a gamble could stand out without forcing me to open the full notes. Several tags shared a limited set of colors, so the color could provide the first signal, followed by the specific icon and then the rest of the player details. Players I did not have a strong opinion about remained visually neutral, making the tagged players more meaningful instead of turning every card into another signal to interpret.

If I needed more context, I could open the player's profile to see my personal notes, tagging controls and a streamlined overview I had Claude create by combining the main points from three of my favorite fantasy football sites. That kept the main cards relatively compact while keeping the additional research one click away.

I treated the manual Draft, Target and Picked buttons similarly. They were large enough to use quickly on a touch device, but I did not want any one of them to dominate the card visually. I initially gave the Draft button a stronger primary treatment, but it pulled too much attention from the player information. Those buttons were also intended as fallback controls, since the live feed would handle most of that work automatically. Keeping the actions visually balanced made them easy to reach without making them the focus of every card.

Secondary elements followed the same approach. The Targeted Players section could collapse when it was not useful enough to justify the space, while position counts, bye-week counts and draft progress stayed visible but visually subdued.

Because I did not know which device I would use on draft day, I wanted the same structure to hold up across a laptop, iPad mini or phone. Rather than create three different experiences, the goal was to keep the same hierarchy, controls and decision flow intact as the available space changed.

02.5 /

Connecting to the live draft

By this point, I had a working prototype that was already much easier to use manually than my spreadsheet. The main feature still missing was live syncing. I needed to figure out how to connect the app to the draft platforms so it could handle pick tracking automatically.

The first working version lived as a React Artifact inside Claude, which worked well for building, testing and manually managing a draft. Its limitations became more apparent when I tried connecting it to the draft platforms. When ESPN's feed could not be reached reliably from the Artifact environment, Claude helped me explore several technical workarounds, but none were successful. The next option was to move the prototype outside Claude's sandbox, deploy it as a standalone web app and continue working on the connection there.

With the ESPN draft only a few days away, I chose to use the manual controls I had already built rather than continue troubleshooting the connection. That draft moved slowly enough for the fallback workflow to be practical, and I did not want to risk breaking something that was already working that close to draft day.

My second draft, on Sleeper, was still a week away, which gave me more time to keep working on the live connection. After the ESPN draft, my first step was to move the app outside Claude's Artifact environment. I pushed the prototype to GitHub and deployed it through Vercel. From there, with Claude providing the technical guidance, I was eventually able to connect it to the Sleeper feed using a Cloudflare Worker as a middle layer.

Once the connection was working, I wanted a way to monitor it during an actual draft rather than simply trust that the Available Players list was syncing correctly. I added a Draft Activity modal that showed the pick history, then expanded it to include connection status and error messaging so I could better understand what the feed was doing. Testing also revealed the need for a few controls outside the modal, including a dedicated feed refresh button in the main view and a Settings toggle to turn automatic polling on or off.

My final concern was speed. The Sleeper feed still lagged slightly behind the mock drafts I was using for testing, so I wanted to make sure the delay was not coming from the app itself. Claude initially suggested reducing the polling interval, but I had already tested the feed with automatic polling turned off and found the same delay when triggering refreshes manually. That helped isolate the lag to the source feed rather than something I could meaningfully improve in the app. At that point, I accepted the limitation knowing the manual controls were still there if the feed proved too slow during the actual draft.

02.6 /

Putting it to the test

The ESPN draft gave me my first chance to use the app for real. Without a live feed, I relied on the manual controls I had built as a fallback. The slower pace gave me enough time to keep the draft state updated, and the new interface made that maintenance much faster and easier than when I had been using my spreadsheet.

The Sleeper draft was the more complete test. By then, the live feed was working and I could see whether the experience I had designed would hold up in a much faster draft. Even after testing the app through mock drafts, I still wasn't sure how useful it would feel once I was relying on it during the actual draft.

I had initially planned to use an iPad, but ended up borrowing a laptop instead. Because I had saved my rankings, notes and other setup in a JSON backup, I was able to restore all of my prep work on the laptop in only a few seconds after copying the backup to my clipboard.

During the draft, I spent most of my time in the Available Players section, usually looking at the full list and occasionally switching to the individual position tabs when I wanted to see each position's top remaining options. The color-coded card outlines and tags made my research findings recognizable at a glance, reducing how often I had to open a player's profile for deeper context. Position and bye-week counts remained useful secondary references, while the profile itself became the place for details that did not need to live on the main screen.

I still had to move between the app and Sleeper to make my selections, but the connected feed allowed me to spend much more of my decision-making time inside the app itself. The live-feed delay was manageable because the real draft moved more slowly than the mock drafts I had used for testing, though I still occasionally returned to Sleeper to confirm the official state of the draft and make sure the selections immediately before mine had synced.

I used the Targeted Players section less often than expected, but it became especially useful for working around the slight feed delay. A few picks before my turn, I could add the three to five players I was most interested in, then compare that shorter list against Sleeper when it was time for me to make a pick. If the feed was behind, I only needed to confirm which of those players were still available rather than rescan the full player pool.

One of the most useful improvements over my spreadsheet ended up being much simpler. In Excel, I had relied on the Find feature as a makeshift search. In the app, the dedicated type-ahead search was always visible and let me quickly narrow the Available Players list as I typed, making it considerably faster to locate a specific player.

Compared with the spreadsheet, the biggest difference was that I no longer had to spend most of the draft maintaining the app itself. The feed handled the repetitive work of removing players from the board, while the interface made the rankings, notes and signals I had already prepared easy to reference as I made decisions. That shifted my attention back to the decisions I was actually trying to make.

02.7 /

Closing thoughts

In the end, the app worked better than I expected and provided a meaningful improvement over my previous spreadsheet, especially given the limited timeframe I had to build it.

However, I still think of this version as a working prototype rather than a finished product. There are things I would like to improve for next year, including the visual styling and typography, clearer labeling, improvements to the structure and interactions within the Settings menu and a less manual way to manage and sync data across devices.

But the goal of this project was not to get every detail polished and perfect. It was to turn several years of spreadsheet-based thinking into something meaningfully easier to use, quickly enough that I could rely on it during that year's drafts.

Claude Code also changed what felt practical for me to build. I could describe the structure and behavior I wanted, react to working software instead of specifying every detail before interacting with it and spend more of my time testing and deciding what the product should do. The process felt less like designing every screen from scratch and more like continuously directing and evaluating a working prototype, moving back and forth between defining the experience and auditing what was already there. Claude could propose technical approaches and handle much of the coding implementation, but I still had to judge what it produced, identify when something was not working and decide which problems were worth solving.

That was probably the biggest takeaway. AI made the distance between an idea and a working prototype much shorter, but it did not remove the need for product judgment. If anything, being able to test ideas that quickly made those decisions more immediate.