I start a lot of projects. I finish few of them.
In soccer a forward's job is to finish; to put the ball in the back of the net. Goals are the only thing that matter.
The theory when it comes to startups is to take a lot of shots with the hope that one of them will go in. Build a startup during a hack-a-thon. Ride a bus to Austin and by the time you arrive an LLC will have been formed. Its easy: just pursue absolutely anything and make sure you call it a startup.
I don't subscribe to those theories.
Good things take time. There are no short-cuts.
There is a huge difference between working on a project because you want to say you're doing something and being obsessed with an idea you have to build.
Also: not every good idea you have should be built.
Now for an example.
In the fall of 2008 I had a new idea: an email service for cloud based applications. At that time if you hosted an application on Amazon's servers and needed to send an email there weren't many options. Amazon's cloud was seen by the rest of the internet as a giant blacklisted entity. I presume many abused the ability to dynamically spawn servers with new IP addresses and soon entire octects were banned. If you wanted to send email you'd have to hit up SoftLayer, ServerBeach or The Planet and run your own dedicated hardware. This would not be a cheap option if all you needed it for was just to send email.
I saw an opportunity to offer an email API that would be priced on a usage basis. Companies would use it to avoid the minimum dedicated cost of $72/month and keep their own deployment simple. This service would eliminate the need to maintain an email system and be vastly cheaper than the status quo.
On December 11th, 2008 I bought the domain cloudgram.com. I figured CloudGram would be a good name: emails as telegram messages being sent through the cloud.
My first version was actually an HTTP based API until I went to use it myself as a developer and found that it sucked. Then I realized that the API for email was really SMTP. I built an SMTP server with Java and OSGI. It would accept SMTP calls, increase the meter by one for the authenticating account and deliver the message.
Everything worked and worked well. In January 2009 I had everything in place to launch this new... new.. startup?
Did I really want to go through with CloudGram? I don't even give a fuck about email. What am I going to do: deliver email for a few years and hope I cash out?
Sending email is such a pain. The further I dug the more I realized the industry was shit. You have to make deals with ISPs, get on whitelists and constantly haggle.
The more I thought about it the more I realized that Amazon would eventually fill this hole and offer it as a service. This pain couldn't continue for much longer and they would beat the shit out of me on price.
I ran the service for myself and a few other people in a long extended beta for almost a year. I never launched CloudGram.
Delivering email is creatively bankrupt. I didn't want to be in that business.
In the summer of 2009 a new startup called SendGrid came about with the same idea. They went on to raise $27.4 million dollars. They are a big company now. A former Oracle executive is now their CEO. They still fucking deliver email.
Amazon released their own email service in 2010 at cut rates just as I had predicted.
Taking a shot
I now spend more time thinking about a project than actually developing it.
I am about to release a project that I've been working on for 18 months.
It is an idea I became obsessed with and had to build. I tried to talk myself out of doing it several times. I have thought out almost every detail ten times over.
The biggest reason in favor of doing fans.fm is that it is a combination of all my passions all wrapped up into one idea. An idea that I would actually love to work on full time and see through.
I haven't taken many shots lately but this one I am going to take and want to finish.
FANS.FM will work on the desktop, iPhone, iPad and other HTML5 capable browsers when released. The logo is a series of circles and I need it to scale perfectly on a variety of resolutions. Enter HTML5! The logo below is not an image; it is a canvas that was just drawn for you!
Two years ago I embarked on a project to digitize my family's vast VHS based home movie collection. I bought the Elgato USB Video Capture adapter for my Mac and began transferring video by video from an old VHS player to the computer.
My goal was to deliver the collection as a set of DVDs that would be given as gifts for Christmas 2010. I had about 40 or so videos ready to go by December and was ready to start burning. To my dismay the traditional DVD format could only hold around two hours of content and took forever to burn.
I delievered the initial discs covering just 6 videos from 1989. My family loved them and it worked out well. I was happy with the result but there was so much more to show them! DVDs weren't going to accomplish the vision I had in mind. I wanted a library that was so dead simple to access that people would actually watch the videos.
What if I just stored all of the videos in Amazon S3?
S3 would give me both storage and backup. I would have to build a private web application for access. There would have to be a database of some sort. I would want simple title, description and year metadata on each video.
All of these thoughts were fine except they didn't accomplish the original vision. I wanted my family to experience their home movies together on the big TV in the family room. That's why I started off with DVDs in the first place.
I wanted a private video collection in the cloud that could be streamed to a TV.
Then it hit me: a vision of my mom sitting on the couch with an iPad, clicking on video thumbnails and streaming those to the TV through an Apple TV.
It was perfect. I now had to make it a reality.
The mobile Safari browser on the iPad has great support for HTML5 video. Any video that comes up in that player can be sent to an Apple TV over AirPlay. So now I had to create a private web application that would bring up HTML5 video players and work well with the touch screen of an iPad.
I hate thinking about servers. When I started out thinking about just how this private web application would be constructed I was thinking Rails. Yet another web app with a relational database that I had to worry about. What if I could get away with not running a server?
I just needed a private link that could render out the contents of an S3 bucket. S3 naturally has an HTTP api that could be called over AJAX if the site itself ran from an s3.amazonaws.com domain. I found an S3 Ajax library and got it to list out the contents of a bucket dynamically. Maybe I really could run this thing entirely out of S3!
There was just one nagging problem: metadata. I really didn't want to run a database or maintain a giant db file in S3. Then I remembered every S3 file object can store its own metadata. I was able to store the simple title, description and year data directly with the video file. I also made the metadata editable within the web app so my family could label the videos for me.
So lets recap: a private HTML5 video collection hosted entirely out of S3 streaming directly to a television through an Apple TV.
I bought my parents an iPad 2 and Apple TV for Christmas 2011. I loaded up the private S3 url (secured with Access Key and Secret Key) into the iPad and we started watching the home movies together on the big TV. It blew their minds. Over the course of the holiday they would make their way through over 50 movies they haven't seen in decades or never watched beyond filming them. The vision was complete. Now I just have to complete the transfer of the remaining dozens of VHS tapes.
My home movies now live in my pocket on my iPhone. My family can enjoy them for just a few dollars a month. Pretty fucking cool.
I might make the code open source or turn this idea into a service at some point. Everyone I show it to just wants the same for their family.
This project is a great example of why HTML5 and the open web wins. Developing an iPhone/iPad app just for this task would have been a huge waste of time. It is also a good case for controlling your own infrastructure. You pay Amazon directly to host and backup this files for you. There are no limits. You pay for what you use. Try finding that kind of deal from many private video service providers. Your files are safe and your Amazon S3 bucket can't be acquired or be deadpooled like every other startup out there. Your memories are too important.