The long road to version zero point nine.

Published on 2019-04-04

For awhile now, on and off, I've been interested in the sports business landscape.

Before I even had kids, I bought the domain name coachwizard.com with the idea of doing "something" in the fantasy sports or real sports space for "coaches".

My experience with supermug.com, draftwizard.com, and a few other failed services (as well as my success with statsfeed) convinced me that the better business would likely be in the real sports realm.

Early on, I looked at a few options around tools for coaching.

I thought maybe something like a CRM dedicated to coaching...or maybe a social network around coaching (this was back in the early days of Facebook and Twitter).

Nothing really jumped out as the "ah-ha" idea...and though I had solid connections into the fantasy sports market and even the larger sports content world (thanks in part to my statsfeed service and some smaller consulting gigs I had done over the years)...I didn't have any real world coaching experience or knowledge.

I was also a little gun shy about getting coaches to adopt new technology vs getting into the market as coaches were already adopting new technology (I had just learned the very expensive "timing or conversion" lesson through the supermug and draftwizard failures).

So I sat on the domain for years. Waiting. Looking for the perfect idea and the perfect time.

Eventually I had kids, and they got old enough to start playing sports. I volunteered to be a parent-coach, and finally started to get some real world experience.  The first thing I coached was football, then it was track, baseball, and even basketball (I also became a Cub Scout leader somewhere in there).

Through those experiences I had the opportunity to interact with a lot of other youth coaches...some had been at it for years and some were completely new to it as well.  I got to be a part of some great teams (and I got to be a part of pretty bad teams too)...and I got to compete against some great (and some horrible) coaches too.

Mobile devices and tablets had also become mainstays -- and more and more coaches were starting to use them on a daily basis (and in their coaching routines).

This all lead me to think I *finally* had the "ah ha" idea a few years ago.

I would build and host a searchable collection of drills, give coaches the ability to build practice plans, a simple way to stay organized & on schedule, to communicate all the details with parents, and of course offer tracking on what each kid learns as they evolve their athletic skills from year to year (so the next coach could pick up where the last one left off).

I started building out that software, collecting (and paying to generate) some intial content, and trying to put together a team of people to help me execute on the vision...I even started to have some early talks with potential angel investors (though I didn't have a complete business plan together; and hence had no success in those talks).

The trouble was - even though I thought the idea was great...I couldn't get any other coaches excited about it. And the reality was, even I didn't use it that much.  The product wasn't right...even as an early prototype.

The reality was that most coaches stuck to their routines. This included what drills they used, how they organized and scheduled practices, how they communicated with parents...basically everything I was trying to "streamline".

Sure a few people might use a system like I was putting together to get started coaching...it was easier/better than sifting through youtube for hours...but once they had a couple of practices together, there wasn't much need for the service.  You could just mix and match those and get through a season.

And other apps/services were already doing some of the parts better.  Teamsnap made communication easier.  CoachUp made finding coaches easy.  LeagueAthletics was already a pretty good management app.  Hudl was already building a monopoly in the tape sharing and review world.

The list goes on and on.

Everywhere I looked there was already better funded, nicer looking, well-functioning solutions.

I still wanted to build a business in this space, but I was back to square one. Looking for a new, ground breaking, idea I could bring to market in this space.

For the most part that's where I still am.

Meanwhile, I think I've mentioned before that even though we didn't use coachwizard.com much ourselves, the one little part that we did seem to use (at least more than any other part) was the ability to view and share game tape.

I had built it mostly because the youth programs I was involved in were completely broke...and though all the coaches would love to be able to use Hudl, they just couldn't afford it.

So instead of Hudl we were emailing clips back and forth -- or putting larger files on dropbox or google drive...and then spending multiple emails, texts, and conversations working out access rights and making sure everyone could actually get the files they wanted.

It was really painful, so I tried to make it a little less painful with coachwizard.  Then as it became clear coachwizard wasn't going to work...I decided maybe I could/should just focus on the tape part of the system and so I broke everything out to sharegametape.com

I wasn't sure if sharegametape.com could become it's own business or not (Hudl really owns this space already; and my tools were still pretty clunky and not fully baked) - but I thought it was at least worth putting the core system together, trying it out with a few of my coaching friends, and seeing how it goes.

So over a year ago now, I put the initial sharegametape.com system together...and it mostly worked (though no one but me knew about it or used it).  Again, still just a clunky v1 and hosted on a very cheap AWS server that isn't at all ready to handle any type of scale...but it was enough of a system that at least I could use it to review tape, and I could use it to share tape with other coaches who could then download or view the clips.

It felt like it was something that *could* be a small subscription business...with just a few changes here or there to simplify the service...some tweaks for scaling...and of course a little marketing.

But I have been busy with other, more important, things...and so it has sat mostly idle for the past year (rolling around in the back of my head).

One of the bigger challenges that has been rolling around in the back of my head was just how to better scale the system.

The initial version took every file that was uploaded, wrote it to the server disk, then moved a copy of that up to s3, and then removed it from the server disk (and finally let the user know the file was uploaded).

This of course wasn't going to scale (even up to two or three users really).  So the first tweak was to remove that "write to server" i/o stuff...that wasn't too hard thanks to the latest version of the boto3 library.

But still the process for uploading files was sequential...if you uploaded a lot of clips at once (which is pretty common as an average football game is like 60 or more plays)...you would be tying up a process until the whole thing finished.

From a single user standpoint, it's not that big of a deal for an upload to take while (after all you are uploading a lot of big files)...but from a server and business stand point you can't have a lot of long blocking calls or you're going to have some serious scaling issues.

The easiest solution is to just add more servers (more processes)...but this gets expensive super fast (and so it just wasn't going to work for me).  I needed a better way to support uploading lots of files without tying up my servers that much.

As it turns out, AWS and the boto3 library, have a solution for just that need -- you can generate a pre-signed upload URL and let a client browser upload the file directly to your s3 bucket. This means you only tie up the server to generate the upload URL (which only takes microseconds per file).

So this was the solution I had been looking for (waiting for?)...I spent a few days figuring it all out and got it mostly working over the summer.

But it was never quite right...when I ran it local, it worked like a charm.  When I ran it on the server, it didn't always upload all the files in larger collections (if I did, say ten files at a time it seem to work but much more than that and it would start to randomly miss files).

It was frustrating -- but it wasn't a show stopper because no one else was using the system (and I could always just run the local version -- or walk through adding the missing files one by one)...so I had it on a to do list to debug, but again, the project went back into the "eventually" queue.

Fast forward to about a month ago - we're heading into what is likely my final season coaching (my kids are now getting to the level that they no longer want parent coaches)...and the spring league is yet another case of "working on a budget"...so I wanted to be able to use my sharegametape.com system to share our clips amongst my fellow coaches.

It was finally time to sit down and figure this thing out. As the saying goes, it was now or never.

So the challenge was to determine where and why files were being dropped.

Was it the dropzone javascript (a javascript library built for drag-n-drop uploading of files)?  Was it something to do with the pre-signed URL process (either within boto3 or maybe something on the client side that was causing a problem with the size or volume of files)?  Was it something else completely?

As it turns out - it *was* something else completely.  It was the fact that, even after twenty plus years as a developer, I sometimes still make really stupid beginner mistakes.

Because of the way the system had evolved over the years (from Coachwizard all the way through to today)...I had written the system as if the files would be uploaded and processed sequentially by the system.  This helped with everything from keeping track of what we upload to the default sorting based on file names.

...but it also meant that, when I moved to the generate pre-signed URLs process and a multi-process system...sometimes multiple files would be uploaded at essentially the same time to the same collection.

I was essentially getting collisions -- one process would sometimes over write the other (making it appear as if the loser in the race never actually existed).

Instead of saving the collection on each upload, I needed to just append to the collection ($addToSet in my mongo collection)...and then just apply the sorting and clean up details in a final call after all the files have been uploaded.

Rookie mistake -- that took me almost a full year to get annoyed enough by to actually dig into and fix.

But hey - it's finally fixed (along with a few other key bugs that were lingering around for awhile now).

And that means the system is *finally* ready for a bit more scale (without breaking the bank)...and now I can turn my attention to fixing some of the more 'clunky' parts that remain...and then maybe...just maybe I can even start to market it a bit.

...and who knows where it can go from there...maybe even all the way to a complete version one some day.