DraftKick 2.0

It's been three years, and it's time for a DraftKick reboot.

Adding Live Sync

This all got started from my work to build a version of DraftKick that connects to the online draft room.

This past fall, I figured out how to pull out live draft data using a Chrome extension, and it's pretty amazing. My extension works in the same tab as the draft room, so you don't even have to flip back and forth between tabs.

To get it working, I copied and pasted the DraftKick engine into the extension. Then, I created a new version of the DraftKick UI that works on a narrow display, because the extension runs in a sidebar in the draft room.

That was a great way to get started, but it created a problem: I now had two codebases that were slightly different from each other, and both needed updated for new features and the latest projections. There was also no communication between the standalone DraftKick version and the Chrome extension version.

I realized I needed to put these two back together into a single, unified codebase. I needed to add the draft room sync ability into the regular DraftKick. Then, I could deploy the same codebase as either a web app or a Chrome extension.

And, while I was at it, this would give me a chance to fix some things with DraftKick 1.0.

Responsive layout

Merging these into a single codebase, I needed a UI layout that worked on a desktop monitor as well as in a single sidebar (basically a mobile-sized screen). DraftKick 1.0 was built for desktop only using Bootstrap for CSS. I decided to redo the UI with the CSS flavor-of-the-month (Tailwind), but make it work at both sizes.

It was also a chance to clean up some spacing issues—stuff that I notice but maybe no one else does.

Real user accounts

Adding the draft room sync also meant I now have two DraftKick products, or at least two pricing tiers for the same product.

Ever since I launched DraftKick, I've used the most janky possible way to verify access to paid features: I require an account to save your league settings, and I only reveal the account creation page after people pay. To keep users from paying once and using forever, I delete all of the accounts at the end of each draft season.

That has worked okay. I certainly don't regret doing things that way. By ignoring user accounts, I was able to focus on building the features that actually mattered for a valuable product (i.e. being able to track your drafts). But it has caused problems:

• Customers would like to copy their league settings from last year? Too bad, I deleted all of those accounts.
• My most frequent support issue is people who pay and then can't create an account. They didn't realize that the step after payment is their only chance to create an account. If they miss that, I need to manually get them back on track.

This is a chance to build a better system. No more making users create new logins every season.

My current user accounts are done with Google Firebase. That's worked okay, but the Firebase UI elements haven't been updated, which has forced me to use an old version of everything. I'd be happy to move that somewhere else. (Conveniently, I'll have no existing accounts to migrate, as I've been regularly deleting them all...)

Analytics

Another feature that I didn't build was any way to easily see how people were using DraftKick. Once again, that was probably the right choice. I used my own taste and direct user feedback (via email) to build the features that actually mattered to people.

But now the big, obvious features are finished. If I knew what kinds of leagues people were creating in DraftKick, it might unlock some key insights for me.

For example, I suspect that there is an unusually high percentage auction drafters in the audience for DraftKick Football. I seem to get more support questions about auctions than I would expect. I suspect that lots of DraftKick Football users are (like me) old-school fantasy baseball players first, and so their football leagues tend to draft like their baseball leagues (with auctions).

I might also suspect that DraftKick's feature set is an especially strong fit for auctions. DraftKick builds better auction values than lots of the competition (where auctions are an afterthought compared to snake drafts). Since auctions move slower than snake drafts, sync is less important to those drafters. I have a hunch that DraftKick lacking sync functionality has been a dealbreaker for lots of the core fantasy football demographic of snake drafters, and that adding that feature opens up that market to me.

But, the truth is, I'm just guessing at all that. I have never had any way to back that up, because I stored league data in an opaque and inconvenient format. I could learn a lot about what to build and what to market if I knew more about

That difficult format was (like the user accounts) also courtesy of Google Firebase. I'd really prefer to use a regular SQL database that I could view and query easily. Supabase seems to meet my criteria, and, as a bonus, it can handle my user accounts. So that's what I'm moving towards.

Progress

Here's where everything stands so far on DraftKick 2.0:

• First, I tackled the CSS refresh from Bootstrap to Tailwind. That took a couple of weeks but is now mostly complete, although there's some tricky stuff (especially with the bidding interface) that still needs fixing.
• Secondly, I switched the league data store from Firebase to Supabase. That seemed to go well and just took a day or so.
• At the moment, I'm working on the new user accounts and the purchasing flow. This is mostly new stuff, but it seems to be working. I've spent a couple days on it, and I can see the finish line.
• The next step will be inserting all of my draft room sync code into the new, unified codebase. I think this will go quickly. I should still have a couple of weeks to test it all out in baseball mock drafts, even though I'm holding off on version 2.0 until football season.
• Finally, I'd like to work on a couple of needed feature improvements. The biggest of these is a "Keeper Mode" that allows you to quickly enter keepers, and does so without forcing you to lock in a draft order.

I'm hoping that I'll have the DraftKick reboot finished by the end of baseball draft season (although version 1.0 will remain the public version).

Then, I can open up DraftKick Football as soon as possible. (Despite football's popularity, I've found that few people are thinking about their drafts until the end of July.) I want to get DraftKick running by at least May, so that I've got lots of chances in the quiet months to try to work out as many kinks with the new codebase as possible.