This post was originally featured on the Expo blog.

Step 1: Building A Team

  • Try to have some sort of stack preference in mind but don’t make that a deciding factor in who you choose to invite.
  • Don’t just bring along experts — try to introduce new developers to the hackathon community.
  • If you don’t come with a team, have some sort of idea of what you want to work on and be prepared to mingle.
  • Bring a laptop and a good attitude.

We  formed our team very close to the start of the hackathon. Xin and I met  at JP Morgan Code for Good in November of last year. For both of us,  that was our first time and we wanted to team up again now that we had  stronger skill sets. Both of us being CUNY students, CUNYHack was the  perfect opportunity to do that. Just a day before the competition began ,  we decided to merge with another team that Xin knew from her school  (Queens College). Together, the five of us became Team Parse. Each of us  brought something different. I was well versed in React, React Native,  and Node. Sang knew React and Firebase like the back of his hand. Xin  was a Bootstrap master. Thita and John, while being hackathon newbies,  were super fast at writing JavaScript.

Step 2: Understanding The Prompt

  • Spend as much time on this step as you can.
  • Create a list of objectives that judges might be looking for in a project.
  • Research other projects done on the topic.
  • Don’t move forward until you are 100% sure of the general expected output.

Our  prompt was to choose a New York City agency and create a technology  that would improve their workflow or output. While many teams started  hacking away at the first idea they could come up with, the five of us  sat round a table discussing the different agencies that made up the  city and which of them could use our help the most. Having had the most  experience using the slowly collapsing subway system provided by the  MTA, we determined that improving their service would be the best use of  our time. Comparing our metro with those of other cities and  countries,we agreed it was the entry system that needed some of the  biggest upgrades.

Step 3: The Idea

  • Focus on the story rather than the technology.
  • Be realistic in what you can build given the time limit and your team’s experience level.
  • Don’t be swayed by a language or framework. Choose what sounds best for the prompt.

Seeing  as we weren’t breaking ground on some Vibranium-based powersuit, all we  really had to do was explore the other implementations of entry systems  and decide on the features that could make our subway great again.  Metrocards are expensive, easily lost, and environmentally wasteful.  Countries like The Netherlands, Russia, and England, to name a few, all  employ an NFC-based system that allows for much faster entry. After  discussing the option, we decided against using NFC entry as it has not  yet been adopted by many banks and phone manufacturers here in the  states. However, we did take inspiration from such systems by deciding  on another mobile-based entry method — QR Codes. We recognized three  features that would need to be included in our system: security, simple  deposits, and super fast entry. Security was our biggest technical  concern as QR codes could possibly be captured and used by other people.  To mend this, we came up with a code that was time-encoded, meaning  that each code would be valid for only five seconds before being  replaced with a new one. When testing among ourselves, we were unable to  take a screenshot, share it, and open it on another phone within said  time limit.

Step 4: Choosing A Stack

  • Choose  the most efficient route rather than the most impressive. Judges would  rather see a working project than something complex and defective.
  • Utilize your team’s strengths.
  • Don’t be afraid to use a new API or framework.

At  this point, we needed to decide on the best technologies for us to  implement. Since the team was Javascript heavy, we focused our attention  to React Native. With Genymotion, Atom, and Expo, the setup process was a breeze and it  took all of twenty minutes to have the five of us ready to code. Despite  our mix of OSX, Windows, and Linux machines, Expo let us build for both  iOS and Android seamlessly. Our authentication and database components  would involve heavy use of Firebase. Some of us had experience using Firebase in the past and it served us  greatly not to have to build a custom backend in the limited time. The  final step in the process was to choose a payment platform. Expo  required detaching in order to use Apple Pay, so we opted to use the Stripe API instead. In order to accomplish this, we created a Firebase Function to execute  the necessary server side code. Overall the stack was incredibly simple  and allowed the five of us to split the required tasks fairly easily.

Step 5: Pacing

  • Don’t try to stay awake through the entire event. Even if you make it, no one wants to see a zombie talk through a Powerpoint.
  • Try  to balance your teammates. If anyone is having trouble, consider  modifying individual load or finding alternative solutions to a task.
  • Schedule regular checkins to make sure everyone is making progress and feeling okay.
  • Make  time to visit recruiter/sponsor tables and connect with other teams. If  you don’t finish the hackathon with an empty bottle of Soylent and at  least 5 new laptop stickers, it doesn’t count.

When we  first started coding, most of our Friday night had already gone by.  There were only about 36 hours until the pitch. Before we went to work,  the team drew a few quick mockups of what the app layout would look  like. This design left a lot to the imagination and each component would  be finalized by the person tasked to build it. In hindsight it would’ve  been better to spend more time on that phase. Nevertheless, inspired  and motivated, the team went to work. Thita and Xin began building and  integrating the login screen/accounts, John and I worked on the main qr  code/scanning screen, and Sang managed to put together the many pages  involved in funding/purchasing a ride. We would meet every few hours to  get a check on the overall progress. We also took turns taking short  naps. In the final hours, the team agreed that the presentation would be  incomplete without a scanning system. Using an Expo demo we found online, we  were able to very quickly build a simple QR code scanner and add a few  lines of verification code. (After scanning, it simply flashed green if a  code was valid and red if it wasn’t.)

Step 6: The Presentation

  • Create  a logo/cover image. This is usually overlooked but is necessary in most  hackathon submission systems like Devpost. A good logo can sway the  judges a great deal.
  • Either decide on a single person who will present or give every member of your team even time.
  • Make  sure to include a problem statement, market fit, a tech stack flow  chart, and ways you could expand your project going forward.
  • Don’t forget a ‘team page’ mentioning contact information for every member.
  • Don’t read directly off the slides.
  • Give  the judges a chance to participate. If you built for a mobile platform,  give them a phone to perform a certain action. For web apps, consider  letting them dictate some of the session flow.

With  four hours left on the clock, we paused all software development to  focus on the presentation. We had to pack everything we had done into a  three-minute pitch. We decided that every member of the team would get a  chance to speak and cover their own section. Sang started by  introducing our team and describing the issues that plagued the MTA. He  explained the inefficiencies of Metrocards and their effects on the  environment. Sang also walked through what needed to be done to fix the  system. Xin gave a brief overview of our main goals and the reasons why  we chose a QR Code-based approach. John jumped in to give a more  specific explanation of each step of the user flow including entering a  station and buying a ride. Having suffered through a cold a few days  before, I had lost my voice and did my best to describe the technologies  we had used and the flow of data throughout the platform. Demo time!  Xin took over again to describe each step as I gave the judges a close  up look at our build.

Step 7: The Finale

  • Be respectful and cheer for other teams as they go up to present their projects.
  • Make sure to thank the hosts, judges, and sponsors before heading home.
  • Get connected —add other participants on LinkedIn or other social media/professional networking channels.
  • Be proud of the amazing work you’ve been able to accomplish over a short weekend.

That’s it for our guide to winning a hackathon! Thank you to CUNY Startups and Baruch College for hosting the event. We appreciate all of the  great sponsors — Facebook, Google, Codecademy, IBM, and Protohack — for  funding the hackathon and handing out great swag. And finally, thank you  to the amazing mentors from around the industry who came to teach us  new APIs, platforms, and general skills. For any questions regarding the  project or winning a hackathon, feel free to reach out to anyone on the  team. All project source is available on Github.