Innovation 4 SDSU — My First Hackathon Experience and What I Learned

Deciding to Join My First Hackathon

My first hackathon experience took place at the Innovation 4 SDSU Hackathon, hosted by CTRL. I walked in with little idea of what the weekend would look like, only knowing the event ran from 9 a.m. to 7 p.m. on Saturday and from 9 a.m. to 3 p.m. on Sunday. It sounded intense but exciting.

I arrived an hour early on the first day to settle in and get comfortable. As I waited, I struck up a conversation with a fellow student I knew from AI Club. We talked casually about the event, what we hoped to get out of it, and how we were both a little nervous but also eager to begin.

A few minutes later, a friend from ACM walked in with someone from his network. After catching up, he asked if I wanted to join their team. The student I was talking to joined as well, and suddenly, we had a four-person team formed naturally before the hackathon even began. It felt like the perfect start.

Understanding the Prompt and Identifying a Real Problem

This year’s challenge was to improve the living experience for SDSU students. The prompt was broad, giving teams a lot of flexibility in what problem they wanted to tackle.

Our team quickly gravitated toward an issue affecting tens of thousands of commuter students: the growing problem of hit-and-runs in parking lots. It was something many of us had heard about, and some had even experienced firsthand.

We researched how many commuter students were on campus and discovered that roughly 24,000 students commute each semester, totaling nearly 48,000 annually. That number alone showed the scale of the problem. Then we turned to Reddit and found countless posts from frustrated students asking for help, information, or simply venting about hit-and-runs that left them with repair bills and no answers.

Seeing how common these stories were made the issue feel even more urgent. It became clear this wasn’t just an idea — it was a real student problem waiting for a solution.

Planning the Solution and Seeking Mentorship

Instead of diving straight into coding, we spent the first four hours brainstorming, analyzing use cases, and getting clarity on what we wanted to build. This planning session became one of the most important parts of our project.

We talked to two professional mentors who asked hard questions about our idea. They helped us refine our direction, think more clearly about the user experience, and decide which features mattered most for an MVP.

Since all of us had experience in web development, we chose to build a web app. It allowed us to move quickly while still creating something functional and realistic. The goal was simple: empower students to support one another by reporting incidents and providing victims with evidence they could use.

Designing a Practical MVP for Real Use Cases

We designed the web app around two primary pain points. The first was witnessing an incident. If a student saw a hit-and-run occur, they could file a report containing the victim’s license plate, images, a text description, the timestamp, and optionally their contact information.

The second use case involved the victim. A student might return to their car to find it damaged with no note or explanation. They could search their license plate in our system to see if someone had submitted a report. If a matching report existed, they could download it and use it as documentation for an insurance claim.

This workflow emphasized community support — one student helping another — without needing an official campus-run reporting system. It made the parking lots feel a little less anonymous and a little more connected.

Finding a Way to Incentivize Reporting

One major obstacle we recognized early on was motivation. How could we encourage students to actually report what they saw? Relying purely on goodwill wasn’t enough.

After talking to a mentor, we received a brilliant idea: Crash Coins. These digital tokens would reward users for creating verified reports. Students could redeem the coins for on-campus benefits or rewards.

Crash Coins added a gamified element to the platform and provided a clear incentive for students to participate. This feature became one of the most creative parts of our entire proposal.

Building the App and Overcoming Technical Hurdles

Once planning was finished, each team member took ownership of a different page of the app. I created the home page, the rewards page, and handled much of the page-to-page integration.

We faced a critical challenge when deciding how to structure our backend. Implementing a database would take too long, and we didn’t want backend complexity to slow down our progress. After speaking with another mentor, we pivoted to using a simple JSON file to store all of our demo data.

This approach let us focus on creating a working prototype without tripping over unnecessary setup. Our tech stack included React.js, Next.js, TypeScript, Tailwind CSS, and our JSON file acting as a temporary database.

AI tools ended up being lifesavers. Whenever we ran into errors or needed quick debugging, AI helped resolve issues faster than we could manually. This allowed us to keep building at a steady pace despite the time constraints.

Polishing the User Experience and Preparing the Presentation

By the end of the first day and into the early hours of the second, we had a working MVP. With the technical work mostly done, we shifted our focus to presentation quality.

We wanted to create something memorable, not just another slide deck, so we filmed two short skit videos. These acted out real scenarios where our app would help students, making the problem and our solution easy to understand.

We also recorded a screen demo of the app in use and created a clean, simple PowerPoint with clear speaking roles. We rehearsed repeatedly to make sure our three-minute presentation was smooth, engaging, and polished.

Presenting First Out of 29 Teams

We were the first of twenty-nine teams to present. Going first is always intimidating because you don’t know what standards the judges have in mind. But we went in confident and prepared.

Our videos, storytelling, and demo immediately caught people’s attention. After our presentation, many attendees and mentors approached us to say they loved our storytelling approach and that it was one of the strongest presentations they had seen.

Starting strong set the tone for the rest of the event, and it felt rewarding to hear such positive feedback right away.

Winning Most Creative and Looking Toward the Future

When the awards were announced, we learned we had won Most Creative, which felt incredibly validating. Our blend of real-world research, thoughtful design, and creative incentives like Crash Coins set our project apart.

During the final share-out, we also discussed our long-term vision for the project, including transitioning to React Native for a smoother mobile experience and building out the full Crash Coin rewards system.

Even though this was only our first hackathon, we left feeling proud and energized by what we had accomplished together.

Reflecting on Growth and What I Learned

This hackathon taught me lessons I couldn’t have learned in a classroom. I realized the importance of planning before coding, the value of seeking mentorship early, and the impact a strong presentation can have on the perception of your project.

On a personal level, I learned how exciting it is to work under pressure with a team of motivated peers. I felt myself growing more confident in my abilities while recognizing how much more I want to learn.

For anyone thinking about joining their first hackathon, I can honestly say: go for it. Be open to new ideas, be willing to take risks, and don’t underestimate the power of creativity. It’s an experience that will challenge you, inspire you, and leave you with memories you won’t forget.