Early in 2015 Ford held a hackathon at the Campus Party event in São Paulo, Brazil. It was the first hackathon sponsored by a car manufacturer in South America ever, and it generated a lot of buzz with the local media, because the prize for the winner was a brand new car.

I always had a blast when I participated in hackathons in the past, but I hadn’t attended any over the last couple of years, mainly due to lack of time. When I heard about Ford’s one, though, I figured it would be important and interesting enough to justify taking a couple of days off my projects, so I enrolled to participate.

The hackathon started on a Thursday, at noon. The 50 competitors had 24 hours to build a mobile app that interacted with Ford’s Sync AppLink. The AppLink platform allows developers to get data directly from the vehicle, and it also allows the user to control his smartphone apps using built-in voice commands.

I developed an app called Good Driver (from Portuguese “Bom Motorista”). The goal of the app is to solve the problem of inefficient risk and price calculations done by insurance companies. Since those companies don’t have much real data about drivers, they need to rely on statistical models to calculate average risks. As a result, everyone ends up paying pretty much the same thing for an insurance policy. In other words, the good drivers need to foot the bill for the reckless ones. The app solves this problem by tracking several data while you drive (e.g., average speed, acceleration pattern, streets most used, seat belt usage) and then by creating a driver profile that can be shared, upon your request, with the insurance company.

My app ended up winning the hackathon. Winning the competition and the car was awesome, obviously. Equally valuable, though, was the overall experience and the lessons I learned along the way. Below you’ll find them:

1. Don’t give up. Really!

The main technical challenge of the hackathon was to learn how to use the Sync AppLink platform, as none of the competitors had had any contact with it prior to the hackathon. Ford provided a hardware bench that simulated a real car, so the first task was to get our mobile apps interacting with the simulator.

After a couple of hours the first teams managed to get it working. After three hours or so around ten teams had it working. Five hours into the competition and pretty much every team had this part working. Except me.

It was very frustrating, and I was considering to give up. At one point I even stood up and started packing my stuff. Then I thought to myself, “All right, let’s try one more thing. If it doesn’t work, I am out of here.” As you can guess, that one last thing worked and I stuck around. I remember thinking how odd it would be if I ended up winning the hackathon after almost giving up. And odd it was!

The next time you are considering to give up, remember to consider the what if: What if I don’t give up and end up winning? Regardless of winning, what if something awesome comes out of it? You will only know if you don’t give up!

2. Sometimes going alone is the right choice

Teams could be composed of either one or two people. The vast majority opted to compete in two. I opted to go alone, and looking back I believe this decision helped me.

There is an African saying that goes like this, “If you want to go fast, go alone. If you want to go far, go together.”

It makes sense, and I believe it suggests that you should go together in most situations. For instance, if you are building a company, you want it to go far, so getting other people aboard will be essential.

On some specific situations, however, going fast is more important than going far, and I would argue that a hackathon is one of them. Since you have a very limited time frame to develop your project, being able to take all the decisions without having to discuss with other people can be an advantage.

I am not advocating that you should always compete alone. But I do believe that your team should be as lean and agile as possible, and this rule applies to most professional endeavors.

3. Ideas and plans still matter

As soon as the hackathon announcer said the competition was on, most teams opened up their laptops and started coding relentlessly. It felt like they picked the first idea that came to mind and started working on it, as if they were afraid they wouldn’t be able to complete the project otherwise. I know this because I had no intention of starting to code for the first hour, so I had time to observe.

Why did I have no intention of starting to code as soon as possible? Because I wanted to make sure I would pick the right idea, and that I would have a plan in place before I started working on it.

In the tech and startup scene it’s common to say that ideas are worthless, and that only execution matters. Secondly, most tech people preach a Ready-Fire-Aim approach, where getting to work as soon as possible is the only way to go.

I agree that execution is the most important aspect, but ideas do carry some weight, so spending some time on the idea conception phase can be worth your while. Similarly, I agree that moving fast and actually getting things done is paramount, but that doesn’t mean that you should skip the planning phase altogether.

4. Forget about PowerPoint. Focus on the speech

After the 24-hour development period, each team would have 5 minutes to make a presentation. Every single team spent the last two or three hours of the competition creating beautiful PowerPoint presentations. The slides were very beautiful. Some even looked professionally designed. I didn’t see anyone practicing the speech itself, though. In fact during the presentation many teams got lost in the middle of the pitch. Others went far over the allowed 5 minutes, and the judges made remarks about it.

I adopted a different approach. My presentation was the only one that didn’t use slides (I only put the app logo on the screen while I talked). Instead of working on the slides, I spent the final two hours of the competition writing down and practicing what I would say.

First I wrote down the speech and made sure contained all the key points I wanted to make. Second, I edited it until I could deliver the speech in exact 5 minutes. Third, I rehearsed it over and over again. Initially to myself, but after a while I started asking random people if they would spare 5 minutes listening to my presentation.

Obviously I still got a little nervous when it was my time to present, but it flowed quite smoothly, as I knew exactly what I was going to say. I guess this made a big difference.

Summing Up

As I said before, it was an awesome experience. One that I will probably never forget about.

I was impressed with the organization of the event and with the level of professionalism that Ford brought to the table. It was by far the best hackathon I have been too. I also made a lot of friends, and got to network with great programmers.

Finally, I hope the tips above will help you in future hackathons!