🧠 My First Hackathon: Bugs, Breakthroughs, and the Best Classroom I Never Expected

Hello everyone! Welcome back to Mayur's Tech Journey. 🚀

You know, there are some experiences that a textbook simply cannot replicate. There are some lessons that only happen when you are sitting in a room, a deadline is six hours away, your app has just crashed in front of a judge, and the only option left is to fix it — right now, under pressure, with no tutorial to guide you.

This blog is about one of those experiences.

This is the story of my first ever hackathon. And I am going to tell you every part of it — the overconfidence, the confusion, the crash, the panic, the recovery, and finally, the realization that hit me afterward. Pull up a chair. This one is personal. ☕

📖 The Context: Exams Were Right Around the Corner

Before I get into the hackathon itself, let me set the stage honestly.

Our Second Semester End Semester Examinations were scheduled right after the hackathon. So when the AI Club of Sanjivani College of Engineering announced the event, my team's initial reaction was... lukewarm. We knew about it. We registered. We had a problem statement — Crop Disease Detection. But between lectures, lab submissions, and the looming exam pressure, the hackathon kept getting pushed to the back of the priority list.

"We will figure it out when the time comes."

That is the line we told ourselves. And the time came — two days before the event.

💥 Two Days Before: The Team Decided to Actually Show Up

Our team name is BugHunters. And looking back, that name was more appropriate than we realized when we chose it — because we spent a significant portion of this hackathon literally hunting bugs under deadline pressure.

Two days out, something shifted in the group. Maybe it was the realization that we had actually registered and our names were on the list. Maybe it was just the competitive instinct kicking in. But something in us said: "We are doing this. For real. Now."

So we started.

Our problem statement was Crop Disease Detection — building a system that could identify diseases in crops from images. It sounds like a well-defined problem. And in theory, it is. But what we discovered very quickly is that knowing what you want to build and actually building it are two completely different universes.

🤖 The ML Dream That Did Not Work Out

Our first instinct, naturally, was to build a Machine Learning model. We were excited about it. We had heard the words "ML model" thrown around in tech conversations enough times that they carried a certain weight — a sense that if you are doing something serious in tech, it involves machine learning.

So we dove in.

We explored Convolutional Neural Networks (CNNs) — a type of deep learning architecture specifically designed for image recognition tasks. We read about layers, filters, training datasets, and accuracy metrics. We tried to understand how a model "learns" to tell apart a healthy leaf from a diseased one. And let me tell you — the learning was real. The actual working model, however, was not.

Our model would not detect diseases. Not reliably. Not in the way we needed it to. Training a CNN from scratch requires large, well-labelled datasets, significant compute, and time — none of which we had in any meaningful quantity two days before a hackathon.

We kept trying. We adjusted parameters. We tried different approaches. But the results were inconsistent, and we were burning through our most precious resource: time.

I want to pause here and say something important about this phase though. Even though the ML model did not work — I do not consider those hours wasted. Not even slightly. Because in those few hours of exploration, I got a real, ground-level introduction to how neural networks function, what CNNs actually do with image data, and why building a production-grade model is not a weekend task. No lecture had given me that clarity. Only the frustration of watching it not work gave me that.

Sometimes, failure is the clearest teacher.

🔌 One Day Before: "What Is an API?"

With one day left, our team made a decision that changed everything.

We dropped the ML model entirely and pivoted to using the Plant.id API — an external service specifically built for plant disease detection.

Here is the honest, slightly embarrassing truth: none of us properly knew what an API was at that point.

We had heard the word. We had seen it in tutorials. But actually using one — sending a request, receiving a response, parsing the data, and building a working application around it — that was new territory for all of us.

And here is what I love about that moment in hindsight: we did not let not knowing stop us.

We looked it up. We read the Plant.id documentation. We understood — gradually, awkwardly, with a lot of browser tabs open simultaneously — that an API is essentially a bridge. You send it data (in our case, an image of a plant), it processes it on its end, and it sends you back structured information (in our case, disease detection results and confidence scores).

Once that clicked, things started moving fast.

We integrated the Plant.id API into our application. We sent test images. We got responses. The diseases were being identified. The confidence percentages were showing up on the screen.

It worked.

I am not going to pretend that we were calm about this. We were not calm. There was a moment of genuine disbelief — the kind where you click a button, see the output, and then just stare at the screen for a second before someone says "wait... that actually worked?"

That was the night before the hackathon. We had a prototype. We were going in.

🏟️ Hackathon Day: Three Rounds, Zero Experience

Let me be upfront about something: we did not know how hackathons work.

We knew the format vaguely — build something, present it, get evaluated. But the atmosphere of an actual hackathon, the pace, the expectations of judges, what "presentation skills" mean in this context, what judges are actually looking for — none of that had been communicated to us from inside a classroom.

We walked in as complete beginners to the format. And the format does not wait for you to catch up.

Round 1: The App Crashed. Then We Fixed It. Then We Presented It.

We set up. We loaded the application. And then — in front of us, before the judge even came — the app failed to detect.

I will not sugarcoat this. There is a specific kind of panic that comes when something you built stops working at the exact moment it needs to work. It is not the calm, methodical debugging energy of a late-night coding session. It is faster, louder, and messier than that.

But here is what I noticed in that moment: the team did not scatter.

Everyone picked a thread and pulled. Someone was checking the API calls. Someone was looking at the image processing pipeline. Someone was checking environment variables. There was no blaming, no "I told you so," no one sitting back and watching. BugHunters were actually hunting bugs — together, under real pressure, in real time.

And we fixed it.

By the time the judge arrived, the app was running. We showed him the prototype. And while we were not polished presenters — not even close — we showed him something that worked.

The feedback we received was direct and constructive:

The UI needed to be better
The app should support multiple languages (we had built it only in English)
It should include a chatbot for farmers to ask questions
It should offer treatment suggestions, not just disease detection

That is a lot of feedback. And we had very little time to act on it.

But we cleared Round 1.

The Gap Between Rounds: Building at Full Speed

The hours between Round 1 and Round 2 were some of the most intense I have experienced since the late nights of 12th standard preparation.

We split the work.

I took ownership of two things: treatment suggestions and UI cleaning. The treatment suggestion feature meant that when a disease was detected, the application would not just name the disease but actually tell the farmer what to do about it — what to spray, what to avoid, how to manage the affected crop. This required researching common crop diseases and their treatments, structuring that data cleanly, and integrating it into the response flow.

The UI cleaning was equally important, and honestly it is something I have come to appreciate more and more through projects like ScholarDesk. A working app that looks broken does not inspire confidence in a judge. I went through the interface, fixed inconsistencies, improved the layout, and made it look like something you would actually hand to a farmer and say "use this."

One of our teammates took on the multilingual translation feature — using Python libraries to allow the app to present results in regional languages, so that a farmer who does not read English could still use it. This was not a trivial task to implement quickly, and watching a teammate pull it off in that time window was genuinely impressive.

And then another teammate built the chatbot.

A chatbot. From scratch. In the gap between two hackathon rounds.

I think about that sometimes when I hear people say that students cannot build real things. BugHunters built a chatbot between hackathon rounds. Under pressure. With no prior experience in that specific thing. That is what happens when a group of people decide, together, that they are going to make it work.

Round 2: The Mango Leaf That Humbled Us

Round 2 evaluation arrived and we were ready — or at least, we were as ready as we could possibly be in the time we had.

The judge was thorough. He tested the core detection flow. He asked about edge cases — a phrase that, if you have never built software for evaluation, deserves an explanation.

An edge case is a scenario that falls at the boundary of what your application was designed to handle. Not the clean, ideal input you tested with. The weird, unexpected, real-world input that breaks things.

The judge handed us an image of a mango plant. He asked us to detect diseases.

The plant was healthy. The tree was fine. But a few of the leaves were dry — the natural kind of dryness that happens because of weather, age, or mild stress. Not a disease. Just leaves being leaves.

He asked: "Why are these leaves dry?"

Our prototype failed to answer that correctly.

And here is why: we had built around the Plant.id API's disease detection capability, which works beautifully when there is a clear pathological disease present. But dry leaves on a healthy tree — that is not a disease. That is an environmental condition. Our application did not know the difference. It either misidentified, or gave a low-confidence result that did not address the actual question.

We did not clear Round 2.

🪞 The Honest Reflection: What This Actually Was

I want to sit here for a moment and be honest with you, the way I was honest in "The Boy Behind the Percentile" when I talked about financial constraints and deferred dreams.

Losing in Round 2 stung. Of course it did. We had built for hours, fixed a crash under pressure, added features in real time, and walked into that round feeling genuinely proud of how far we had come from the morning.

But here is the thing I have been thinking about ever since:

We were not supposed to win. We were supposed to learn.

I say that not as a consolation. I say it because I genuinely believe the learning we got from this hackathon has a longer shelf life than any trophy could.

Think about what happened over those two days:

We tried to build a CNN model from scratch and understood, through failure, what neural networks actually demand.
We discovered what an API is — not from a definition in a textbook but from the real experience of sending a request and watching data come back.
We debugged a crash under deadline pressure and learned that staying focused and not panicking is itself a skill that must be developed.
We built new features between evaluation rounds — translation, a chatbot, treatment suggestions — in a timeframe that would have seemed impossible to us a week earlier.
We learned what edge cases are, not because a professor explained them, but because a judge exposed one in our project in real time.

Not one of those lessons came from sitting in a classroom. Every single one came from doing the thing.

🙌 BugHunters: The Team Behind the Build

I want to take a moment to acknowledge my team, because this experience was not mine alone.

A hackathon is fundamentally a team sport. And what I saw from BugHunters across those two days — the willingness to take on unfamiliar tasks, the calm under pressure, the speed of execution, the support for each other when things were not working — that is not something every team has.

The person who built the chatbot between rounds: genuinely impressive.
The person who implemented multilingual translation in hours: genuinely impressive.
Every person who stayed in and kept building when the app crashed and the easy choice would have been to shrug and give up: genuinely impressive.

I am proud to have been part of this team. And I am proud of what we built — not despite it being imperfect, but including its imperfections. Because those imperfections are exactly where the education lives.

💡 What the Hackathon Taught Me That No Semester Can

Let me close with a few direct lessons, because I think these are valuable for every student reading this who has not yet attended a hackathon:

First — Start early. We burned two days of potential build time by treating the hackathon as a secondary priority. In a hackathon, every hour is expensive. Start from the day you register.
Second — Presentation matters as much as the product. A mediocre product presented with confidence and clarity will often outperform a great product presented poorly. We are engineers. We need to work on this. I need to work on this.
Third — Edge cases are not optional. If you build something and only test the happy path — the clean, perfect input — you have not really tested it. The real world sends mango plants with dry leaves and asks you why they are dry. Build for that world.
Fourth — APIs are not cheating. I think there is sometimes an unspoken feeling among students that using an external API is somehow "less real" than building everything yourself. That is wrong. Every professional developer in the world builds on APIs, libraries, and frameworks created by other people. The skill is in knowing which tools to use and how to integrate them intelligently. That is what we did.
Fifth — Fast-paced practical learning is irreplaceable. The compressed, high-stakes environment of a hackathon forces a kind of learning that no scheduled lecture can replicate. You are not learning to pass a test. You are learning because the application literally will not run until you figure it out.

🔭 Looking Ahead

The Second Semester exams are starting from June 5th, and right now that is the priority. But after the exams, BugHunters will be back. We have unfinished business with that crop disease detection app — and now I know exactly what needs to be fixed.

Edge cases. Treatment accuracy. A more robust detection pipeline. Maybe, eventually, a properly trained model.

The hackathon did not end our journey with this problem. It showed us where our journey with this problem actually needs to go.

And to every student at Sanjivani College of Engineering — or anywhere else — who is sitting on the fence about whether to participate in the next hackathon: just register. You will figure the rest out.

That is exactly what BugHunters did. And I would not trade a single hour of it.

CropSuraksha : Our hackathon project

🔗 Also Read:

"Winning is one kind of education. Losing, with your eyes open, is another. Both are necessary."

Signing off,

Mayur B. Gund

FY B.Tech CSE | Sanjivani College of Engineering

Mayur's Tech Journey