My List Of (SOME) Failed Projects

Not every project is the next Facebook or Instagram earning billions in yearly revenue. Many projects I make or design are learning experiences or fun ideas at the time. I feel like it is always nice to look back and think of all the projects and cool ideas over the years, even if they never went anywhere. Some of these grew a bit, were sold, or were non starters that hit a miss in the market or a technical limitation. A lot of these were built in the early days of the iPhone and there wasn’t millions of app to download so while some may have been simple, some really were innovative at their time if we had the ability to grow it correctly.


When Twitter API was free and you could get access to Firehose and full filters, we were onboarded in the beta program to be able to consume and search tweets as we wanted. Twitter with the growth of iPhones were starting to geotag tweets with your location. We thought, cool, we generate a box around the city of Buffalo, NY and capture all tweets from that area.

At the same time, Foursquare the early checkin app released their API which gave a considerable amount of API requests to be able to query places around you and also checkins.

There was nothing really around aggregating this data so we built BuffaloTrending. We extracted a feed of tweets and checkins and were able to show the most popular places over the last few hours, day, and week to help people discover what was going on in the city.

Since RSS feeds were popular, we extracted the local news sites and essentially had our own local homepage with what was happening. We did pitch the idea to a few local businesses to get some ads and promotion of their places and for a while, was getting organic traffic. We pitched it to a local radio personality to help grow it and they ended up starting their own version of it they swear they didn’t steal but was almost the same name. Still overall a great first experience in data aggregation, consuming tweets at a high rate, and one of the early days of JSON objects.


There was the start of web APIs that allowed the access of cameras in your laptop or webcam into web pages. The idea of a socially viable webpage that could promote through viral methods by people promoting and sharing of photos, remember this was before Facebook was super massive and Instagram and TikTok weren’t around.

We built the site that could generate a contest based on your webcam to make sure it was entered by you that day. You would create a contest, for example “Best Duck Face” and then take a webcam picture of your entry and post. The rest of the people browsing can see popular contests and choose to submit their own. As visitors interacted with the site, they upvote entries they liked and was a way to build these small contests and let people grow.

The site was functional but didn’t get any growth. Apache Cordova was a way to build mobile apps but the focus on browser and the assumption everyone would have webcams wasn’t that viable. Looking at the trends of the future of apps. it would have been great to take on a mobile first approach and possibly allowed sharing and linking to spread the viralness of contest.


This was one of the largest successes I had. YouTube was growing with a lot of videos and viral spreading trends but the use of it with live DJ sets that didn’t exist on any platform and Spotify and iTunes not being the size they were left a bunch needs to get these sets.

I decided to build the first version of a YouTube to MP3 converter that was the standard enter the URL you wanted, it downloaded the video and converted it to MP3 and allowed you to download it. YouTube didn’t really have any filters to work around and overall was a simple concept and provided a use for me to get my live DJ tracks I wanted.

The site grew fast through friends and started to get organic traffic from Google. The project initially was running some python scripts that extracted the page, downloaded the video, and ran a FFMPEG conversation on it to return the MP3. It moved the file to a folder and allowed someone to download the file. Quickly the VPS was running out of space so was deleting files after a short window and displayed ads while they were waiting for the converstion.

The site started to grow from Google and was on the front page for searching for converters and had to reengineer a lot of the site into a fully distributed website. Instead of just downloading the file on demand, I would save the files and URLs and be able to reserve the same file to prevent hitting YouTube.

While there wasn’t much blocking or DRM by YouTube in their early days, they did start to throttle by IP so initially being able to grab a video in seconds was now taking minutes. To combat this, I stared to break the website into a more distributed architecture using load balancers at the time. I was able to proxy visitors to a specific page on a single server and each server was able to download and serve the file to keep speeds up.

With the rise of jailbroken iPhones, I saw a use to want to take these files with me on the go but didn’t have the iOS jailbreak development experience so partnered with someone who was an incredible iOS dev still in university. I built a full API that could process and handle requests from his app (iDibblr) and then it would serve the files and have a built in media player. Within days of release, it had thousands of downloads.

Overall this project taught me a lot. Load balancing, handling traffic and compute, proxies and caching, iOS, APIs, and even dealing with traffic bursts. While I still own the domain, the site did shut down. Google got more aggressive around DRM and protecting videos. The need to keep finding ways to extract the videos was getting more and more complex so decided to turn the site down.


I started working more with affiliate marketing and finding more and more sites offering money to do more than show ads. You could make $1 or more from a visitor completing a survey or filling out an offer on a website trial.

There was a demand of VPN services outside of the US where internet was limited. Massive amount of users in India and China were looking for ways to explore the internet without being limited so I decided to combine the two. I found a few sites that offered various VPS servers (AWS and Google Cloud Platform wasn’t a thing yet) and rented small servers to host OpenVPN. I generated my own installer and server list to allow anyone to install the client and connect to my servers.

The website was powered by WordPress and had a simple sign up that created the users account. From there, they would be able to take surveys or click ads and when completed, the site got the post back they performed this and was able to respond to it similar to how mobile games now give you free coins in a game for watching an ad.

The WordPress site was the core page with guides to setup the OpenVPN software and shared the usernames and passwords to a Radius server. When a user completed the survey and earned enough points, the WordPress site would unlock the account for a time period in Radius and the user was able to connect and browse as they needed.

The site grew significantly through natural growth of users all in countries with limited internet access. I had almost 30 VPS servers running in 4 countries all managed through a central login server and minimal work on my end due to the signup and account manager I built in WordPress to Radius.

I ended up selling the website after a bit but was a great project and provided a great opportunity with little promotion.


While we sat in the office after our day jobs working on client sites for WordPress and various ideas, we were working with a small restaurant who was updating their menu. Before the DoorDash and Uber Eats apps had this stuff, we had to call places and order.

One of the ideas we had was to be able to allow a customer to update parts of their website without having to edit the whole page or be a website expert. Better yet, with most pages not really supporting mobile well, what if we had a way to generate a mobile website for people on the go who wanted to see their menu of a pizza place?

We build a PHP based application that generated mobile menu. A user can go in and pick their color scheme to match their main website and then start to edit their menu. From entrees, appetizers, drinks, specials, prices, and any descriptions, it was all web based and essentially a food CRM.

We initially tried to have a button to bounce the user from the unresponsive full website but we eventually found using a small script, if the user was on a mobile browser to redirect them to our small app. We tested it out on a few websites but the traction was never there to grow it beyond the initial test. In the end, we did create a fully functional CRM that had an intuitive way to create menus at the time and we were proud of it.


In college, craft beer was starting to grow in popularity. Drinking the newest beer or finding something you haven’t seen before gave us the idea to build a broad site to track what you were drinking and find similar ones. We started to build it and categorize all the breweries around and their lists. The concept was such a great idea, Untappd launched while we were building and grew their thriving user base much faster so we decided to stop.

The domain is still owned by me. I continually have a new idea like creating a site of beer thoughts or some microblogging beer themed site but just haven’t settled on it so will forever be renewed until I sell it or something comes up.


Similar to the beer idea, but we had graduated and expanded our drinking to wine. There were so many different ones and trying to keep track of a wine you liked that didn’t make you broke or gag was hard. I also lived in an area that was known for wineries and tours to there was a potential to somewhat link their winery info to someone looking up a bottle.

The initial idea I built was collecting peoples photos of wine bottles and starting to run image recognition on the image. You loaded the app, took a picture of the label, and initially was trying to classify it to load the info and description and where it was from. This allowed you to have a virtual “Wine Rack” in your app so people who liked your taste can see what you were drinking and follow you. You can enter manually since I was a solo operation friend sourcing my wine picture data.

The limitation on the scanning was hard. The technology we have today wasn’t there and in different light or angles, the image never recognized consistently so made it a bit hard to work with. The data for the wines and managing the latest was very time consuming but overall was a fun idea to think about.


The idea was to use data available in sports providers to pick winners in NFL games each week. The trends of teams and how they were performing was accessible through some data providers and gave the idea to generate predictions. This wasn’t fully embedded in machine learning but did perform basic models on the stats and matchups. Using decision trees it was able to pull some good results at par with Vegas predictions and slightly better.

Was a fun attempt at some data projects before the accessible tools like AutoML and the more user friendly tools to build models.

Provably Fair Casino

During the early Bitcoin days, the biggest use of your bitcoin was JustDice. You send in your coins, you bet your value and pick over under a number. Mathematically, you get paid based on the odds and the number out of 100. If you picked over 20 on a sale of 0-100, your payout was smaller than if you said over 80. Was addicting and sadly, spend a lot of Bitcoin when it was only a few bucks to buy them.

The idea kept going to build more fun games using a similar logic of hashes. Instead of just dice rolling, we wrote a few games using some prebuilt engines like Blackjack and High Low with a deck of cards. The problem was how do we generate a way to prove we are running a legit casino game without sharing too much about the game.

What if we told them the cards before they played to prove we didn’t swap cards? Yes. We wrote a hashing method on the deck so when you joined our game, the deck was shuffled and the hash was shown to you.

When you played, you would see the deck hash for every hand which was the order of the cards. At midnight, the fair page would post the server key used for that 24 hour window and all the hands that were played using it. The user then could use a simple script using any hashing library and combine the game ID, the deck hash, and the server hash and confirm the deck that was shown was the deck they played with and no swapping of cards happened. To be able to fake the hash, we would need some serious compute power and wouldn’t be possible to find another hash to generate the same deck of cards, similar to how most methods to crack a password take years or a lifetime.

The idea was awesome and become implemented by many other larger casinos online. We ended up selling a bit of the concept to a few smaller ones who wanted to add it to their games and came up with a few variations like rock paper scissor against the computer where we told you what they picked before you decided and a few other games like high/low that proved they were fair.


Bitcoin was popular and so was betting so using the provably logic from prior projects, had the idea to implement it into sports betting.

After the Super Bowl, there was the thought of being able to run Super Bowl style squares for other sports. You know, the one that everyone writes their names in a box, pays some money, and if your score matches the half of final, you win a portion of the pot. Really simple and really fun when you win.

For sports like NBA and MLB that played regularly made the thought of having squares to join online using crypto was interesting and easy to get more people to fill the games.

The site came up with a few new methods to handle the squares. If it was a sport like baseball, we had 5×5 games where each player got two numbers 0-4 and then 5-9. NBA we had the normal 0-9 on both sides. If the game didn’t sell, the site would buy up the squares when the game closed 30 minutes before the game started.

The problem we faced was how do we replicate a fair method of picking numbers like using a deck of cards to make sure no one thought they got a bad number like 2 and 3 if the site was also buying up numbers to fill the games? A user could pick the spot they wanted but the site could give them unfavorable numbers if it was a bad actor.

We decided to use the Bitcoin blockchain for our source of truth and similar method to the provably fair casino games. We generated a server key each night for that days games. When the game filled, the recent bitcoin block hash was the second hash we used. We generated a hash of this using the combined server key, bitcoin hash, and the suffix of 1, 2, 3, 4…. This hash we then extracted the numbers to fill.


Using this hash, we would start from the left and extract each number we need without repeating. As we moved, we get 3, 1, 2, 5, 6, 7, 4, 8, 0, 9. This fills the first side of the board and need to continue to fill the next set of 10 numbers. We get 1, 6, 3, 4, 7, 0, 9, 5, 8, 2.

Board filled! If we do not get all 20 numbers we need, we will rehash with the server key, bitcoin hash, and the run number 2, 3, 4… until we fill it.

At the end of the day, the server key was published with all the game IDs and ability to show the hashes used to build the numbers for each game.