Hackathons are exciting, but the real experience begins when you have to turn an idea into something that actually works.
When Hacktoberfest Hack Day started, I was nervous. I wanted to build something meaningful, but choosing the right problem statement felt like the first challenge. After listening to talks from four champions, my excitement grew. Their experiences reminded me that hackathons are about learning, experimenting, and pushing yourself beyond what you already know.
At around 6:30 PM, our team, Dot, started exploring the problem statements.
After nearly an hour of discussion, we selected Problem Statement 6: Open Source Decision Intelligence and Knowledge Recovery.
That decision became the starting point of Mentis.
The Problem We Wanted to Solve
Open-source projects accumulate years of development activity across GitHub commits, pull requests, issues, and code changes.
Among this activity are important updates and changes to the codebase, but keeping track of them can become difficult.
Imagine a developer making changes to a parser, improving its performance, fixing bugs, or modifying an existing implementation. After the changes are tested and verified, the commit becomes part of the project's development history.
However, understanding what changed and keeping track of verified commits across a repository can still be challenging.
As projects grow, developers need a reliable way to monitor commits that have already been verified and understand the changes they represent.
Without an organized way to track this information, important updates can become difficult to follow.
The problem isn't that developers lack information. It's that keeping track of valuable, verified code changes becomes difficult as repositories grow.
We wanted to make that information easier to monitor and access.
Introducing Mentis
Our team, Dot, decided to build Mentis, a project designed to help developers monitor GitHub commits that have already been verified.
The goal was to make it easier to track verified commits from GitHub instead of manually searching through repository activity.
We wanted Mentis to help answer one important question:
What verified changes have been made to this repository?
It was an interesting challenge because it combined repository analysis, information retrieval, backend development, and AI.
Building the Product
Our tech stack included:
Frontend: Next.js, TypeScript, Tailwind CSS
Backend: Python, FastAPI REST API
Database: PostgreSQL
We chose this stack to build a full-stack application with a frontend for interacting with Mentis, a REST API for backend communication, and PostgreSQL for structured data storage.
Development rarely followed a straight path. We researched the problem, analyzed the repository, explored suitable libraries, and worked on connecting the different components.
The frontend needed to communicate with the backend, the backend needed to handle application logic, and the database had to support the information we were working with.
With limited time, we focused on the essential parts of the product rather than trying to perfect every feature.
The AI Integration Challenge
One challenge came during AI integration.
We wanted the AI to work with repository information, but it wasn't fetching the backend code as expected. That meant the AI was missing important context required for analysis.
It taught us a lesson that sounds simple but matters in real applications:
An AI model cannot analyze code that the application has not successfully retrieved and provided.
Adding AI is not just about writing a prompt. The entire data flow matters—from accessing repository information to passing the right context into the model.
The experience showed us that an AI-powered product depends just as much on reliable backend communication and data retrieval as it does on the model itself.
The Midnight Journey
As the night progressed, excitement slowly turned into exhaustion.
The clock kept moving. Our screens were still open, tasks were unfinished, and the deadline was getting closer. After hours of staring at code and debugging, even simple problems started demanding more concentration.
There were moments when we felt completely drained. But whenever we looked at the progress we had made, it reminded us why we were still there.
We kept working—fixing problems, making improvements, and bringing the different pieces together.
Then came 5:30 AM.
After nearly seven hours of work, we finally merged our PR.
That moment felt different.
It wasn't just another GitHub notification. It represented hours of research, coding, debugging, and teamwork.
We had started the evening unsure which problem to choose. Now, we had a product ready to submit.
We were exhausted, but seeing our work come together made every hour feel worth it.
We submitted Mentis.
For a moment, there was relief. The product was in, and we had reached the goal we had been working toward.
But the hackathon wasn't over.
We shifted straight into presentation preparation. Now we had to explain the problem, demonstrate what we built, and communicate why Mentis mattered.
After a night of writing code, we were preparing to tell the story behind it.
What I Took Away
Hacktoberfest Hack Day taught me that building a product is about much more than implementation.
Choosing the right problem, researching the repository, connecting technologies, and working through unexpected failures are all part of development.
The AI integration challenge reminded me to understand the complete data pipeline before expecting meaningful results.
And the overnight journey showed me what persistence looks like when a deadline is approaching.
We started with uncertainty, built Mentis, merged our PR at 5:30 AM, submitted the product, and moved on to preparing our presentation.
It wasn't a perfect journey, but it was a real one.
At 6:30 PM, we had a problem statement. At 5:30 AM, we had a product. And somewhere between those hours, Team Dot learned what it takes to turn an idea into reality.
Top comments (0)