Our experience at Hacktoberfest Hack Day,31 October to 1 November 2026
There is something special about doing something for the first time. You don't know exactly what to expect, you aren't sure how things will turn out, but you are excited to experience something new.
I've always heard people talk about hackathons. Developers coming together, building something from scratch, working under pressure, facing unexpected problems, and somehow managing to turn an idea into a working product within a limited amount of time.
I'd seen people share their hackathon experiences and heard stories about overnight coding sessions, but I'd never actually participated in one myself.
Then, two of my friends asked me if I wanted to participate in the Hacktoberfest Hack Day with them.
Honestly, I didn't have any big expectations or a particular plan in mind. My response was quite simple: Why not?
It would be my first hackathon, and I wanted to experience what it actually feels like to build something with a team, especially during an overnight hackathon. I was curious about how people manage their time, how they divide responsibilities, what happens when something doesn't work, and how much a team can accomplish when everyone is working towards the same deadline.
So, the three of us decided to participate in the Hacktoberfest Hack Day at Newton School of Technology, Rishihood University, Sonipat.
We didn't know exactly what we were getting ourselves into, but we were excited to find out.
What I Built
Choosing a Problem Worth Solving
Once we got together, the first thing we did was go through the available problem statements.
There were eight problem statements, each presenting a different challenge. We started discussing them, and everyone had their own thoughts and opinions.
One person would suggest something, another would come up with a different idea, and then we would discuss whether it was actually possible to build within the given time.
Of course, we didn't agree on everything immediately.
There were a few disagreements about which problem we should choose. Some problems seemed interesting from a technical point of view, while others looked easier to implement. We had to think about what we could build, how much time it would require, and whether we would be able to deliver something meaningful.
After going through the options, we came across Problem Statement 6: Recover the Decisions Nobody Wrote Down.
Something about this problem caught our attention.
We felt it was an interesting challenge, and our initial assumption was that not many teams might choose it. We wanted to work on something a little different rather than simply going with the most obvious option.
After discussing it among ourselves, we decided to take on Problem 6.
Introducing DevTrace
Once we had selected our problem statement, we started getting the initial things ready.
First, we created our GitHub repository and completed the initial submission process. After that, we started thinking about what we should name our project.
Everyone came up with a few suggestions. We discussed different names and eventually settled on one:
DevTrace.
The name combines two ideas: development and tracing. Since our goal was to trace the history of technical decisions in software projects, we felt it represented what we were trying to build.
GitHub Repository: https://github.com/Shresth-14/DevTrace
The Problem We Wanted to Solve
Think about a large GitHub repository that has been maintained for several years. Over time, hundreds or even thousands of issues, pull requests, discussions and technical conversations get added to it.
Developers discuss different approaches, suggest improvements, point out problems, and sometimes reject an implementation because they find a better alternative.
But here's the interesting part: not all of these decisions are easy to find later.
Imagine joining an existing project and opening a file where you see a particular implementation. You might wonder why the developer chose that approach.
Was there another approach considered earlier? Was something rejected because it was too slow? Did the team discuss a particular problem before arriving at this implementation?
The answers might already be somewhere in the project's history, but finding them can take quite a bit of time.
That's exactly what we wanted to solve.
We wanted DevTrace to analyse historical GitHub conversations, identify important decisions, and preserve the reasoning behind them.
The idea wasn't simply to summarise conversations.
We wanted to understand the thinking behind the code.
Our Initial Technology Stack
After understanding the problem, we started discussing how we could turn the idea into an actual product.
We knew that the project would need several different components. We needed a frontend, a backend, a database, GitHub integration to collect historical repository information, and an AI pipeline to analyse everything.
Our initial technology choices looked like this:
| Component | Initially Planned Technology |
|---|---|
| Frontend | Next.js, React, TypeScript |
| Backend | Node.js, Express, TypeScript |
| Database | Supabase PostgreSQL |
| GitHub Integration | GitHub App, Octokit |
| AI Model | NVIDIA Nemotron 3 Ultra |
| AI Gateway | OpenRouter |
| Version Control | Git, GitHub |
| CI/CD | GitHub Actions |
These were our initial choices, and not everything remained the same during implementation.
Three People, Different Responsibilities
Since there were three of us, we decided to divide the responsibilities so everyone could focus on a different part of the project.
One of my teammates took responsibility for setting up the CI/CD pipeline. Another started researching and finalising the open-weight AI models we could use for our use case.
The third responsibility involved keeping everything organised. This included maintaining documentation, checking the project structure, keeping track of deadlines, managing the GitHub workflow and making sure we completed the submission requirements.
Everyone had a different responsibility, but all of these things were important.
I also got to understand more about how CI/CD pipelines fit into the development process. Until then, I had mostly thought about development in terms of writing code, testing it and pushing it to GitHub.
This experience helped me understand that building a project isn't just about writing features. There are many other things happening behind the scenes that help a team work properly.
Changing Our AI Approach: Ollama and Qwen
One of the interesting parts of our implementation was deciding how we would actually run the AI model.
Our initial plan included NVIDIA Nemotron 3 Ultra and OpenRouter, but our actual implementation took a different direction.
We decided to use Ollama with Qwen 2.5 Coder 7B, running locally.
We wanted to experiment with an open-weight model instead of depending on a hosted, paid AI API.
This was particularly interesting because we had to think about the actual inference environment, local hardware requirements, model responses and how to integrate the model into our application.
We started testing how well the model could understand GitHub discussions and extract the information we needed.
The results were mixed.
Sometimes the model understood the conversation quite well and gave us useful information. Other times, the responses weren't exactly what we expected. There were instances where the extracted information needed improvement, and the model didn't always interpret the context correctly.
We realised that getting an AI model to generate a response and getting it to understand a technical discussion are two very different things.
A technical conversation can contain multiple opinions, suggestions, disagreements and follow-up messages. The actual decision might not even appear in a single message.
That was one of the interesting challenges we encountered.
Using Ollama also gave us a practical introduction to local AI inference and the considerations involved in running an open-weight model on local hardware.
Connecting GitHub With Octokit
Once we started working on the backend and AI pipeline, the next important part was getting the actual data into our system.
After all, the AI needed conversations to analyse.
For this, we used Octokit, the GitHub API toolkit, to interact with GitHub and retrieve repository information.
Our focus was on collecting information from GitHub that could be passed into our AI pipeline for analysis.
This was an important part of the project because the quality of the information extracted by the AI depended on the conversations we were able to collect.
We wanted to make it easier for developers to understand the history behind decisions without manually searching through numerous issues, pull requests and discussions.
Bringing Everything Together With the Frontend
We used Next.js, React and TypeScript for the frontend, with Node.js, Express and TypeScript for the backend.
The frontend was important because we wanted to turn the work happening in the backend into something a developer could interact with.
The challenge was connecting the different pieces of the application. The backend, AI pipeline, GitHub integration and frontend were separate components, but they needed to work together to make DevTrace useful.
This was also where we began appreciating the importance of keeping the project structure organised and coordinating work between different components.
Not every part of our initial architecture was completed, but having the initial structure and technology decisions gave us a direction to work towards.
Demo
We created a public GitHub repository for DevTrace, where the project structure and hackathon documentation are available.
Project Repository: https://github.com/Shresth-14/DevTrace
The project was designed around recovering technical decisions and their reasoning from historical software development conversations.
We don't currently have a public deployed demo or demonstration video to share, so the GitHub repository is the main project reference for this submission.
Partner Technologies
The most important AI-related technology we experimented with was Ollama, together with the Qwen 2.5 Coder 7B model.
We initially planned to use NVIDIA Nemotron 3 Ultra through OpenRouter, but we changed our approach and used a locally running model instead.
This gave us an opportunity to explore local inference and understand how an open-weight model could be incorporated into a software application.
We also worked with technologies including Next.js, React, TypeScript, Node.js, Express, PostgreSQL, GitHub integrations and GitHub Actions.
We did not use Gemma or another MLH partner AI model for our implementation. Our actual AI model choice was Qwen through Ollama.
Hackathon Experience
More Than Just a Coding Event
For me, this hackathon was about much more than just building DevTrace.
It was my first time participating in an overnight hackathon, and I got to experience what it is like to work on a shared project with a deadline approaching.
The event brought together students interested in open source, AI and solving real engineering problems.
One thing that stood out to me was the emphasis on building like an actual open-source project.
The organisers expected teams to maintain public repositories, use open-source licences, work through pull requests, configure CI workflows and document the models used in their contributions.
This made us think beyond the usual approach of writing code until the project works.
We had to consider documentation, testing, evidence, collaboration and the development workflow as well.
For someone experiencing a hackathon for the first time, these expectations made the experience particularly valuable. They showed us that building software is not just about getting a feature to work. It is also about making the work understandable, testable and maintainable.
What I Learned From Building Under a Deadline
One thing I realised during this experience is that having a technology stack written down doesn't mean everything will work exactly the way you imagined.
At the beginning, we had a fairly ambitious plan. We wanted GitHub integration, an AI-powered decision extraction system, a database, a frontend and a proper development workflow.
But as development progressed, we had to make practical decisions about what we could actually complete.
Our initial AI model and gateway choices changed, and we ended up using Qwen locally through Ollama.
The AI output also wasn't perfect, which meant there was still room for improvement.
These weren't necessarily things we had expected at the beginning, but they were part of the process.
I think this is one of the biggest differences between planning a project and actually building one.
When you're planning, everything looks straightforward. Once you start implementing things, you discover the details that you hadn't considered earlier.
You have to make decisions, accept trade-offs, communicate with your teammates and keep moving forward even when the result isn't exactly what you initially imagined.
And that's where most of the learning happens.
What Made This Experience Special
We started with three friends discussing a list of problem statements, disagreeing on a few ideas, and eventually choosing one problem that we thought was worth solving.
We gave it a name, created a repository, divided the responsibilities and started building.
I got exposure to things I wanted to understand better, including CI/CD workflows, GitHub integrations, backend development and running open-weight AI models locally.
There were things that worked, things that didn't work as expected, and things that we had to leave out because of time.
But that's okay.
We weren't experienced hackathon participants who already knew exactly what to do. We were three friends experiencing this environment together for the first time.
And somewhere along the way, a simple decision to participate in a hackathon turned into an experience that taught us a lot about working together and building software under real constraints.
What I'm Taking Away From My First Hackathon
Looking back, I don't think I'll remember this experience only for the project we built.
I'll remember how it started with a simple invitation from two friends. I'll remember the discussions around choosing a problem, the excitement of planning something new, the technical decisions we had to make, and the process of bringing different components together.
I'll remember that we started with an ambitious plan but had to adapt when reality didn't match our expectations.
Most importantly, I'll remember that this was the first time I experienced what it actually means to participate in an overnight hackathon.
Before this, hackathons were something I had only heard about through other people's experiences. Now, I have my own experience to look back on.
We might not have implemented every feature we initially imagined, and there is still plenty of room to improve DevTrace. But we learned, experimented, collaborated and pushed ourselves to build something around a real problem.
And that is something I genuinely value.
Sometimes, the best experiences begin with a very small decision.
For us, it was simply saying yes when two friends asked, "Do you want to participate in this hackathon?"
And that one simple yes gave us DevTrace, our first overnight hackathon, and a memory that will stay with us long after the event is over.
Here's to the first of many more things we hope to build together.
Top comments (0)