Inside a hackathon: 36 hours to build a financial app
A weekend’s work and $15 buys some lessons in fintech
- Written by Amrita Vir
- Comments: DISQUS_COMMENTS
A couple of weeks ago, I attended my first “fintech hackathon.” With my focus on public policy and business, this was a rare opportunity for me to better understand how fintechs operate and my potential roles in them. I share my experiences here to uncover some of the challenges and opportunities associated with fintech. I learned some lessons that all bankers and fintech players can benefit from.
First, what is a hackathon? Headlines of foreign agents “hacking” into our cyberspace have caused many people to think that the concept is scary, “Our website has been hacked!” However, this is only one specific definition of “hacking,” the broader of which is much less sinister.
“To hack” is to write computer program prototypes to address various objectives. Thus, a “hackathon” is an event wherein many people collaborate in this computer prototyping for several days. In my case, the hackathon was focused on fintech objectives, lasted the entire weekend, and was set up as a competition with participants vying to win cash prizes.
I learned about the MIT FinTech Hackathon via Facebook. I had heard that hackathons were really fun, but I thought they were exclusively targeted at people who have a mobile application (app) idea and/or know how to develop computer programs.
To my surprise, the organizers of the hackathon advertised that it was not necessary to have coding experience or even to arrive with a team to participate. The total cost for a ticket to the event was $15. I had no idea what I was getting into, but I went ahead and bought one.
The Friday of the hackathon arrived, and I strolled down to the Cambridge Innovation Center in Cambridge’s Kendall Square. Here, MIT’s spark of innovation has ignited the whole neighborhood and turned it into one of the country’s tech hubs.
Friday: Joining the hackathon
I arrived at 5:30 P.M., and the hackathon started 30 minutes later. I was given a wristband and t-shirt and told that I could hang around the table of free snacks until the program began.
I didn’t know anyone there, so I began chatting with other participants. It seemed as if everyone was either interested in fin or tech with only a minority of people focused specifically on fintech.
The program finally started with an introduction by the MIT FinTech Club and an overview of what we would actually be doing over the course of the next 36 hours.
The event sponsors—TD Bank, Citi Ventures, Prudential, and Even Financial—were four different financial institutions that were each looking to incorporate fintech into their business models.
Four “hacks” were revealed:
1. Create a home loan renewal process to increase loan renewal rates.
2. Build a tool to help employees better serve customers at bank branches.
3. Use physical fitness and financial health data to better engage consumers.
4. Use one bank’s big data and application programming interface (API) capability to create something cool.
Teams would pick one hack to pursue and then pitch their ideas to the sponsors on Sunday morning, complete with a presentation, demo, and Q&A.
The top three teams in each category would go on to the final round, where they would pitch to the entire hackathon audience. Several winners would be determined and receive prizes ranging from $3,000 to a remote-control drone.
And then we were turned loose to begin hacking.
“Hi! Can you code?”
Having arrived without colleagues, I immediately started networking to cobble one together. There were no limits to the team size, but I knew I couldn’t be successful alone.
I ran into a school friend, so we decided to team up. While he was taking a technology design class and could understand some programming language, neither of us felt confident that we could deliver a successful hack without someone who could develop computer programs.
Our top priority became recruiting a third team member with this skillset on site. This was more challenging than I expected.
I had no idea how to define my value proposition to a potential developer/teammate. Yes, I have done work and research in the areas of finance, consumer policy, and fintech, but I have never actually built anything.
“What do my work experience and studies mean if they don’t give me a tangible skill with which to actually make something?” I thought.
Additionally, I had to figure out how to translate whatever marketable skills I did have into language more easily defined by existing roles in the tech ecosystem. Even if I did have fintech experience, how was I going to put that experience into terms that will be understood by my teammates?
Meanwhile, the clock was ticking. No more time for introspection. We didn’t have weeks or months to accomplish our mission.
We had 36 hours.
Finding my role
I decided to pitch myself as a “designer” and “program manager.”
Wearing the hat of designer, I could shape what the product would look like, its functionality, and how the consumer would engage with it.
The program manager hat, on the other hand, allowed me to think strategically about the addressable market, how our app would fit into the company’s larger portfolio, and whether we would have a viable business.
We succeeded in convincing a developer to join our team, a role defined by focusing on using computer code to build the product.
My job was to focus on making the user interface and user experience (“UI/UX” in the tech world) conducive to consumer engagement, as well as to develop the business case for why we were pursuing the hack that we chose.
My friend operated in the middle, as a designer and a translator of my ideas into more tangible and aesthetic models, which were used as the skeleton on which the final product was built.
Digging into the hacks
The three of us spent the rest of the evening in a conference room debating which hack we wanted to pursue and coming up with ideas about how to actually build the product.
All three of us seemed to gravitate towards the consumer-facing hacks, the home loan renewal product and product offering customer engagement through physical wellness.
In debating the pros and cons of each, we concluded that the home loan renewal product was more straightforward, while the wellness product required a little more creativity. Since we had all signed up for the hackathon for the learning rather than the possibility of prizes, we decided to take a risk. We chose the physical wellness product as a greater challenge.
We wrapped up around 11 P.M., giving ourselves the rest of the night to think about how best to link financial health and physical health outcomes. We agreed to meet at 9 A.M. on Saturday morning to resume our work.
Saturday: The work begins in earnest
By noon on Saturday, we had come up with the idea for our product.
Operating on the premise that the same behaviors necessary to achieve financial health are also required for physical health, we decided to create an app that pulled in data from various health and fitness apps, as well as financial health data to come up with a composite score of one’s overall “health.”
The app would encourage positive financial health behaviors using physical health nudges … and vice versa.
By 4 P.M. we had several “wireframes,” or templates of the product design completed and were beginning to build the actual app. We made a work plan and aimed at getting out of the Innovation Center by 9 P.M.
Best-made plans go awry
Turns out, building an app takes longer than expected.
We worked at the Innovation Center until it closed at 11 pm. With plenty of work yet to do, we shifted to the bar next door and resumed our work, beers in hand.
It was not until around 2 A.M. that we agreed that the product was ready.
Sunday: Preparing our pitch
The next morning, we met up at 7 A.M. to practice our “pitch”—the presentation and demo of our product to our sponsor.
As a former consultant with a lot of experience with PowerPoint, I took the responsibility of creating the pitch deck.
But, alas, it was not so easy …
As I Googled examples of pitch decks, I realized that pitch decks were very different from the consulting decks to which I had been accustomed. Pitch decks use pictures and design rather than words and provide only the most important information. The “pitcher’s” voice-over is used to provide most of the content.
Around 9:45 A.M., we were ushered into our sponsor’s conference room.
We had five minutes to sell our idea with our pitch and demonstration.
Clad in “tech casual,” we talked about the behavioral premise of our product; the data sources and algorithms for our scoring system; and the behavioral nudges we included to improve customer engagement.
There was a quick Q&A, and then we were finished. We awaited word if we’d made it to the final round.
Each sponsor selected three finalists for their hack to present their ideas to the broader group.
While our team was not selected, I stuck around to see the products that others had created. Each of them was innovative and engaging, with a primary focus on product-design and user experience.
Learning from a hackathon
I am very glad to have participated in this hackathon and am excited about the prospect of participating in more in the future. As I reflect on my first experience, I take away a few important lessons that can be applied broadly to the banking sector.
First, there is a need to bring diverse groups together to solve financial problems.
My team members at the hackathon had very different backgrounds, skills, and career goals, and each perspective shaped the end-product.
For example, the developer suggested leveraging existing data from physical health apps, when I thought we would have to build hardware, like a Fitbit or an Apple Watch, to collect the data from scratch.
For my part, when we needed to develop a framework for measuring financial health, I was able to draw on metrics I have seen in the financial regulatory arena.
In the banking industry, we need bankers, regulators, consumer advocates, and technology developers to work together, rather than in silos, to come up with solutions.
Second, communication lies behind successful development.
I found that it is critical that these diverse perspectives are communicated effectively. I was surprised that even though I am familiar with the fintech landscape, I had trouble getting my ideas across to the developer.
While I was talking about human-centered design, the developer was talking about programming in Python. While I wanted to be able to track breaches of data security, the designer wanted to figure out how a consumer would get the notification that such a breach had occurred.
Similarly, regulators often fail to grasp the tactical constraints governing fintechs, while fintechs often fail to see the massive risks to security posed by big data.
By immersing ourselves in these different environments and trying to learn the basic concepts and trends in the industry, we can more effectively communicate our own perspectives.
Finally, we tend to think of fintech as a shift in the banking industry that will call for huge overhauls of regulation and banking operating models. That may not be the case.
At the hackathon, teams worked on incorporating fintech into one very specific aspect of the consumer banking process.
The financial institution sponsors did not have to change anything about their existing structures to better understand fintech, and participants did not have to worry about defending their products to consumer advocates or regulators who may view them as predatory.
The environment encouraged innovation and risk-taking without much downside. It is possible for fintech to iterate quickly in a safe space that leads to greater understanding by all involved.
If you want to learn more about “hacking,” see John Ginovsky’s recent “Making Sense Of It All” blog, “6 more tech terms you need to know”
Editor’s note: Have you ever taken part in a hackathon? Tell us about your experience in the comment section below.
Tagged under Technology, Blogs, Fintech, Next Voices,