Hi everyone, we're from OSDC, and this year we continued our flagship event, OSDHACK'26, with a five-day hackathon focused on On-Device AI and Local ML.
We chose the theme because AI projects at hackathons have become painfully repetitive. Another chatbot, another wrapper, another "AI-powered" something. So we thought forcing models to run locally would make people think harder about privacy, hardware limits, latency, smaller models and actual edge use cases.
We were expecting some really interesting projects.
We did not exactly get that.
A special thanks to FOSS United for sponsoring us and helping make the event possible. Alongside the main hackathon, we also hosted our usual CTF, speed typing competition, and this year added a new mini-game called Battleships.
This time, we hosted OSDHACK on Unstop, mainly because of the reach the platform offers. And reach we definitely got. We received close to 3,000 registrations in a month, compared to around 600 participants at most in our previous events. Naturally, we were pretty excited.
Then came the mid evaluations.
We had around 350 project submissions, and this is where we learned our first major lesson: always have mid evaluations.
A surprising number of submissions were old repositories, dead projects, or repos with barely any activity during the hackathon. Some people were very clearly there just for the participation certificate. We ended up eliminating around 60 submissions at this stage itself, which saved us a lot of pain during the final evaluations.
The bigger problem, though, was what happened after that.
Once we started going through the remaining projects, everything started looking strangely familiar. Notes analysers, PDF analysers, study assistants, document summarizers, local chatbots and different versions of the same "upload something and ask questions about it" project.
We had tried to eliminate AI wrappers by choosing On-Device AI. Instead, we got AI wrappers where the API provider was now Ollama.
At some point, we gave ChatGPT our hackathon theme and guidelines and simply asked it for project ideas. A lot of the suggestions it gave us were almost exactly what we had been evaluating for hours.
That was both funny and slightly depressing.
We had created a hackathon theme partly to escape generic AI-generated ideas, and participants had apparently responded by asking AI what they should build for it.
There were definitely exceptions. A few teams built genuinely interesting projects and actually explored what local AI could enable. But considering the number of registrations and submissions we had, those projects were far rarer than we expected.
If we're being honest, we don't have a great story about someone using LLMs cleverly. One of our special mentions, LANShare, was a peer-to-peer file-sharing tool for local networks with semantic search built in, and it made the cut mainly because the code was hand-written and it clearly wasn't another chatbot wearing a different theme. If there's a lesson in that, it's probably this: use an LLM if you want, but don't let it decide what you're building, and don't let it write all of it either. Whatever it helps you with should still have your fingerprints on it, tests, documentation, an explanation you can give when someone asks how it works. And if you are going to lean on AI, at least use it for something more interesting and novel than the AI ideas being used by 10 others. Find your own problem statement and maybe use AI for the work plan rather than a "make this, make no mistakes." prompt.
This also taught us something about platforms. Unstop is great if you want reach and numbers. We had never seen anywhere close to 3,000 registrations before. But registrations do not automatically translate into good participation.
From our experience, communities around platforms like Devfolio and Devpost seem to attract more participants who actually come looking to build something. With Unstop, the huge reach also brought in a much larger number of people who seemed interested mainly in certificates or submitting whatever they already had.
That is not necessarily a problem with the platform itself, but it is something student clubs should think about. Do you want the largest possible registration number, or do you want a smaller crowd that is more invested in actually building?
The other thing we would strongly recommend is mid evaluations. Check repository activity, ask participants what they built during the event, ask them to run the project, and make them explain a few technical decisions. You do not need some massive anti-cheating setup. You just need enough checks that submitting a random old repo is not the easiest way to complete the hackathon.
OSDHACK'26 also made us realise that organising hackathons in the AI era probably needs a slightly different approach. Banning AI tools is not realistic, and honestly, it would be stupid. The problem is not people using AI to code. The problem is when AI starts deciding what everyone builds as well.
Maybe hackathons now need stronger problem statements, more specific constraints and evaluation criteria that reward originality and understanding instead of just whether a project works.
If we ran this again, we're not sure more guardrails are the answer, it's a little idealistic to think people would follow them anyway. What we'd actually love to see is a local AI hackathon that leaned harder into being local, more things built by hand, more people actually testing what these small models can do. A lot of the projects we saw felt unsure of what the model underneath them was even capable of. If we had to pick one real guardrail, it's this: design the theme so it's genuinely hard to be generic.
Despite all of this, OSDHACK'26 taught us a lot. We reached more people than ever before, built the event website at hack.osdc.dev, ran our mini-games and CTF, found some genuinely good projects, and learned a lot about what we want to change next time.
Here is roughly what we ran on. We judged on seven things: how much real local AI work went into it, whether it was actually on-device or just claiming to be, whether the team knew their own numbers for latency, memory and model size, whether their evaluation was honest enough to name its own failure cases, whether privacy was a design decision rather than a closing paragraph, whether we could clone it and run it, and whether everything they built on was attributed.
The weighting was simple: someone who trained or fine-tuned their own model counted for far more than someone who pointed at Ollama. Asking for those numbers did a lot of quiet filtering for us, because it is hard to write an honest technical report about a project you did not really build.
The run of show was a mid evaluation, then finals, with the gap in between filled by alumni talks and our mini-events, Monketype, CodeBattleships and the CTF. Prize money came to ₹15,000 in cash across the hackathon and the mini-events, with sponsor-provided memberships and domains on top.
If there is one thing we would tell other student-led clubs, it is this: big numbers look great, but they do not necessarily mean a better hackathon.
So would we tell other clubs to run one? We'd say think hard before you do. You get the reach and the buzz, but you also spend most of the event fighting the exact thing your theme was designed to avoid. We'd still call it a deal with the devil, just one worth making if you go in with eyes open. If you're up for that fight, mid evaluations and a genuinely hard-to-be-generic theme aren't optional.
And if you are designing a theme specifically to avoid generic AI projects, maybe give the theme to ChatGPT first.
You might get a preview of half your submissions.
Thank you for sparing a little attention to this blog, if you liked us, maybe take a look at our website and some links of OSDC.
Thanks,
OSDC
