It looks like 2015 is on to a good start. Only a couple of months after winning a car at Ford’s hackathon I decided to participate in another programming competition, and I ended up winning it as well. Organized by MasterCard, the Masters Of Code event tours around the world, and participants need to develop something using MasterCard products and APIs.
My team was composed of my brother (who is also a programmer), myself, and three other friends. We developed an online marketplace where small and medium businesses can negotiate their receivables (i.e., anticipate the credit card payments to receive the money today and not within 30 or 60 days) with dozens of banks and financial institutions at the same time. In Brazil a small or medium business can only negotiate his receivables with his own bank or credit card acquirer as of today, so our goal was to make the market more transparent, more efficient, and with lower interest rates for the small business owner.
The judges liked the project, and we ended up getting the first prize. Now we’ll be flying to Silicon Valley in November to represent Brazil in the world finals.
Pariticpating in big hackathons like this one is a blast, and at the end I always try to sum up the lessons I learned during the experience. Below you’ll find three I took home this time:
1. Pick Your Team Wisely
Initially my team was composed of three programmers. The rules allowed up to 5 people per team, so we decided to recruit two more to join us. Luckily enough we found a designer with great UX experience, and a business development guy with a background in the financial sector. I am pretty sure we wouldn’t have won if it weren’t for the complementary skill-set of the team and for the synergies that came out of it.
2. Be Flexible
My brother and I had been thinking about an innovative mobile payments solution for a couple of years already. The key innovation is to use Wi-Fi, which is already present in virtually any store, to authenticate the user. We arrived at the competition determined to develop and present that idea.
We managed to convince two other team members, but the business development member was convinced that an online marketplace for receivables was a more solid idea. The discussion lasted for hours (literally), but in the end the four of us who wanted to do the mobile payments solution were willing to change our minds. Again, if it wasn’t for this flexibility we probably wouldn’t have won.
3. Let the Pitch Man Rest
Most hackathons require teams to code and work through the night. The MasterCard one was no different, as we had 24 hours to develop our prototype.
The beauty of this model is that you push yourself hard, managing to get a lot done in a short period of time. The downside is that people tend to arrive exhausted at the end of the competition, which is exactly when the pitches are done.
Given the overall importance of the pitch, I believe it’s essential to let the team member who is going to deliver the pitch sleep for some hours at least, so that he is fresh at the time of the presentation. We used this strategy, and it worked pretty well.