It's all Vegas-style when 400 developers, designers, and entrepreneurs competed for $250,000 in prizes at Money20/20's ultimate Hackathon.

The size of the prize pool makes the Money20/20 Hackathon a truly special event. The only requirement is that you create an innovative and financially viable product utilizing APIs and services of the sponsor organizations. Sponsors included some of the largest players in financial services, like MasterCard, Visa, First Data, and Synchrony Financial. If you couldn’t come up with a viable product from these providers, you probably didn't try hard enough.

For this years Hackathon, I teamed up with a former co-worker and Hackathon partner, Joshua Copeland. Josh and I run the local PHP user group in Las Vegas, so we saw the Hackathon as an excellent opportunity to try some PHP magic and see just how much we could get accomplished in a small 24-hour window.

We were both interested in really “kicking the tires” on Laravel, which is taking the PHP world by storm and quickly becoming the most popular development framework in the language. We both had an introduction to Laravel prior to the conference and attended a presentation by its creator, Taylor Otwell, at ZendCon. During that presentation, Taylor spoke about how he designed Laravel to be a joy to use, so we decided to put Laravel to the test.

The product Josh and I would build was inspired by a recent trip I took to iovation's headquarters. While waiting for my delayed flight back to Las Vegas, I spent some time listening to a fantastic guitarist near the food court. His skills were quite impressive. I wanted to tip him, but realized I had no cash on me. It made me wonder how performers like him, also known as buskers, would transition into what is essentially becoming a cashless society. This seemed like great opportunity to utilize a peer-to-peer payment API to quickly transfer funds between the patron and performer with a minimum charge for the transfer. The product was molded even further by research performed with actual street performers. I discovered that many of them didn't have bank accounts and a good number of them had no permanent address. With these two factors, the product had to be specifically innovative around the homeless and un-banked.

As we spoke to the sponsors, the vision of our endeavor started to come together. We needed to address no bank account and no credit card scenarios, but still provide for person-to-person credit card transfer. We would take payments from a mobile-optimized web page and transfer funds to a white-labeled, pre-paid credit card. The pre-paid card would solve the un-banked problem.

We would also monetize based on the usage of the pre-paid card via revenue sharing with the card issuer. This would allow for zero markup on the transfer fee. This would make it more accessible, realistic and affordable for a small volume of small currency exchanges. To reduce friction at the point of sale, we would use a QR Code that the patron could scan to jump directly to a payment page. We would also need to optimize the form on the payment page for auto-fill from mobile browsers. With our requirements set, we were ready to build. Fortunately, we still had 20 hours left.

With our product taking shape, it was time to pick the platforms for our product. Based on our requirements, we felt that Laravel was still a fine choice for the application layer. However, for the database, we needed something that was easily supported by Laravel and would not require us to learn anything new. MySQL was the obvious choice for us as we both had extensive experience with it in multiple projects.

We discussed hosting for a bit. There are a myriad of options available out there for hosting projects small and large. In the end, we decided on Heroku. It was easy to provision with a simple initial setup and integration with GitHub for continuous deployment. It also had integrations with providers of MySQL databases and, even better, was free for a small application. In the end, we decided on the following:

  • PHP and Laravel for the application layer
  • MySQL for the RDBMS
  • GitHub for the version control
  • Heroku for application hosting
  • ClearDB for database hosting

Our infrastructure selections would have a tremendous payoff. With commit-based deploy on Heroku, a simple tweak to the post install scripts setting in the Composer configuration file, and Laravel’s database migrations tool, we had a continuous delivery system that would automatically release both code and database changes whenever a GitHub merge to master was successful. Every time we finished a portion of the application, it was immediately available to view on Heroku. As an added bonus, the Heroku tool belt app mixed with Laravel’s data migrations tool also allowed us to remotely reset the entire database after every demo test run to ensure the demos were consistent.

This was truly was a dream setup for a Hackathon!

Now that our infrastructure setup was complete, we could begin building our application. Bootstrapping an application with Laravel was as promised: simple and intuitive. Adding user registration and login to the site was as simple as running a script on the command line. Altering the required fields and data to capture was nearly as simple. Update the model class and the registration template and you are done. We added a service for interacting with the MasterCard P2P API, a service provider (DI factory) for the MasterCard P2P service, a controller and routes for the QR Code, and payment pages to complete the back end. Now we just needed to add refinements to the UI, which Josh did like a true pro.

Laravel comes with Bootstrap, which was more than enough to make a simple attractive website in a snap. We added some images to make the site look modern and reasonably attractive, and finished the majority of the work with four hours to spare. Now we just had to get a little rest and prepare for our presentation.

Although we both made veiled attempts to get some sleep, we were unsuccessful. We did spend some time with our eyes closed, however, which seemed to do a world of good. We walked through our presentation and got the timing down over breakfast and right up until the last few moments before our first presentation.

The initial presentation seemed to go well. It did show us a point of emphasis for the next round should we make it. The web application on the mobile device was so fast and clean that the judges thought it was a mobile app. During questions, we were able to explain that it was a seriously optimized mobile application. Based on the reactions of the judges, we felt a renewed sense of confidence. Now we just needed to wait for the announcements of the project that made it to the second round.

At Money20/20, they announce groups of projects that made it to the next round as they present to the judges. I’m not a huge fan of that methodology, but it does ratchet up the suspense. Group after group was called up to present in the next round, and our name was not called. Our optimism was fading but we still had hope. Finally, the last group was announced and we were’t selected. We were certainly disappointed but we both took some solace in knowing that we actually finished an application in under sixteen hours from start to finish, and that we optimized a web app so well that judges mistook it for a native mobile app. I’m certain we would have been more excited about winning $30,000, but pride in a job well done is a pretty nice consolation prize.

Looking back at the entire experience, there are a few things I would change, but none of them are technology based. They reflect on the makeup of the team. Had we included a business focused team member, we could have had them work on better defining our value proposition and perfecting the pitch. These are two areas which we could have done better.

I would have also included a front end designer/developer so that the user experience could have had a full 24 hours to mature instead of after the core of the business logic was completed. Josh did a great job in the limited time he had to put a pretty face on our site, but had a resource been dedicated to that task, it could have been that much more attractive. There’s always next year, right?

Speaking of 2017, I stumbled into a conversation with Bob Wells, Director of Marketing for Money20/20, who was already working on how to make the event even better. We may very well see a competition more akin to a Startup Weekend than a standard Hackathon with more emphasis placed on value proposition than technical acumen. Having participated and coached in Startup Weekends in Las Vegas, I am excited to see if business building is the direction forward, as $250,000 in prizes would go a long way to jumpstart some budding entrepreneurs.

If you would like to see what Josh and I built, the site is still available on Heroku and the code is on Github. The Heroku site may be sleeping, so please be patient if it takes a moment to start.