Cognition Hackathon

I participated in the Cognition Hackathon, a four-hour hackathon where participants had to build applications using tools such as Windsurf, Devin, Oracle Cloud Infrastructure, and Agora.io.

Four hours is extremely short for a hackathon. In fact, I think it was the shortest hackathon I have ever participated in. That made it one of the most challenging ones.

Before the event, I had an idea that I had wanted to build for many months. With the recent advances in AI tools, and with my own skills improving, I thought this might finally be the moment when I could build it.

I arrived at the event at Anhembi Morumbi University, checked in, and watched the opening presentation. One of the speakers introduced Windsurf and Devin, explaining how they could be used to accelerate software development. After that, the hackathon officially started.

At first, I could not find a good place to charge my laptop, so I was still trying to organize myself when someone asked whether I wanted to join a team. I said yes, because I wanted to hear the idea and explore the possibility of building together.

We talked for a while and tried to find another person to join the team. Eventually, we found a place to sit and start working. But we quickly ran into a common hackathon problem: alignment.

Everyone had a different idea of what to build. Each person wanted to pursue their own direction. We spent valuable time discussing the project instead of building it. In a normal hackathon, that would already be costly. In a four-hour hackathon, it was extremely expensive.

After some time, I decided to continue alone and build the application I had originally planned.

I started by creating the UI design and screens using Google Stitch, then used Windsurf to help me build the interface. I used Kimi K2.6, which was very powerful for coding and iteration. The development process moved fast. The application started to take shape, the UI looked good, and I was able to make meaningful progress in a short amount of time.

One of the most valuable parts of the event was talking to mentors. I discussed my idea with several people, showed what I was building, asked for feedback, and received useful suggestions. Those conversations helped me improve the project and think more clearly about what I was actually trying to build.

The biggest technical challenge came from the OCI track.

To qualify for the Oracle Cloud Infrastructure track, I needed to use OCI in the project. My plan was to deploy the database using OCI Autonomous Database. That took much more time than I expected. I lost a lot of time trying to work with Terraform and infrastructure as code instead of focusing only on the minimum implementation required for the demo.

At the end, I had to submit a video explaining the project, the demo, and the deployment. I delivered the video and included a Vercel demo link, but the application was not fully working in production. That was a problem.

The main lesson from this hackathon was clear: in very short hackathons, speed matters more than ambition.

I needed to ship faster. I needed to reduce scope earlier. I needed to choose a project that could be completed, deployed, and demonstrated within the constraints of the event.

Another important lesson was about project format. Many teams built Telegram applications. That was a smart choice. A Telegram bot does not require a full frontend. You can focus on the backend, APIs, integrations, and core functionality. In a four-hour hackathon, avoiding frontend complexity can be a major advantage.

My project required a frontend, backend, database, deployment, and cloud integration. That was probably too much for the available time.

The choice of project may have cost me the victory.

Still, the experience was extremely valuable. I learned much more than I would have learned by staying at home. I created things I had never created before. I worked with tools I had not fully used before. I finally created and used my OCI account. I talked to mentors, met interesting people, and tested myself under real pressure.

That is one of the best parts of hackathons: even when you do not win, you leave with more skill, more clarity, and more experience.

Takeaways

• In a four-hour hackathon, scope is everything.
• Team alignment has to happen very fast, or it becomes a liability.
• Solo building can be more efficient when time is extremely limited.
• Telegram bots are powerful formats for short hackathons because they avoid frontend complexity.
• Cloud deployment can consume more time than expected, so it must be planned carefully.
• A working demo matters more than a big idea.
• Mentors can improve the project dramatically if you talk to them early.

I am looking forward to the next one.