Why my hackathon project lost — and why I’m glad it did

Developer Soo — Wed, 28 Oct 2026 10:09:22 +0000

A few weeks ago, I participated in the IBM Bob 2.0 Hackathon. It was a 48-hour event with 15,000+ participants. My project didn’t win.

And honestly? I’m grateful for that.

Not because I think failure is fun, but because it forced me to confront a pattern I’ve seen before: when the build gets exciting, I can start optimizing the technology before I’ve fully validated the problem, the constraints, and the judging criteria.

That’s not just a hackathon problem. It’s a product problem.

The project I built was "Nerve".

The idea behind nerve is simple but important: most coding agents treat every prompt like a fresh start. They forget context, re-plan everything from scratch, and lose work when a user changes direction mid-task. I wanted to build something that treated work as a persistent graph rather than a one-off prompt.

In other words, nerve is a coordination layer for agentic software development.

Instead of “new prompt = new plan,” nerve keeps a live task graph across prompts and sessions. It understands dependencies, tracks what is running, what is pending, and what can be safely replanned without interrupting in-flight work. It’s designed to allow AI coding agents to behave more like a collaborative engineering teammate and less like a forgetful assistant.

This is the kind of problem I care deeply about because it sits at the intersection of:

AI systems
software architecture
developer experience
workflow design

The core problem A lot of people talk about AI coding tools as if the main challenge is just “make the model smarter.”

But the real challenge is often workflow and continuity.

If your agent doesn’t understand the work graph, it can’t reason about:

what is already in progress
what is blocking other tasks
what should be replanned after a new instruction
what should remain untouched while the user changes direction

That was the gap I was trying to solve with nerve. The product idea was solid: persistent state, dependency-aware execution, incremental replanning, and a better model for long-running software work.

The technical stack The project was built across multiple layers:

Backend

Python 3.13
Uvicorn + Socket.IO
LangChain + LangGraph
Model integrations including IBM watsonx.ai, OpenRouter, Groq, Anthropic, DeepSeek, and more
OCI Object Storage for file handling
Async Python for task and execution coordination

Frontend / CLI

Node.js 22
React
Ink (for terminal UI)
Vite + TypeScript for the web workspace

The stack wasn’t arbitrary. I wanted the project to reflect a real developer workflow:

model orchestration in the backend
terminal-first interaction for power users
browser-based workspace for accessibility and demos
file and execution context that felt like a real coding environment, not a toy prompt UI

What I got wrong The honest answer is this: my idea was good, but my competition strategy was weak.

I got too focused on building. I spent too much energy perfecting the system and not enough energy validating whether I was solving the problem in the way the hackathon expected.

I didn’t pay enough attention to:

the competition requirements
the judging rubric
the narrative needed to present the product clearly
the constraints of a judged environment

In other words, I built something interesting without making sure it fit the framework in which it would be evaluated.

That was the real mistake.

The lesson This was the biggest lesson for me:

At a hackathon, the rules are part of the product.

You can build a compelling technical solution, but if it doesn’t fit the criteria, the story, and the expected format of the judging process, it won’t get recognized. A good idea is not enough; it has to be framed and delivered in a way that the judges can understand and evaluate.

This taught me something about product thinking:

innovation without alignment is wasted effort
the problem isn’t just what you build, it’s how it is positioned
constraints are not obstacles; they are design inputs
being technically strong is not the same as being strategically effective

It also taught me something about myself: I’m willing to be critical when it matters. I’m not interested in pretending the result was better than it was. I want to learn from the failure and improve my process.

That is the kind of honesty I think matters in engineering.

What I’m taking forward I’m not walking away from this empty-handed.

I’m walking away with:

And most importantly, I’m more convinced that the idea behind nerve is worth exploring further.

Because the challenge is not just building an AI assistant. It’s building a system that respects continuity, dependencies, and long-running intent.

That’s the future I want to work on.

If you’re interested in the project itself, you can check it out here: The presentation

And if you’re in the middle of your own build, I’d encourage you to do this before writing the next line of code: Read the rubric. Understand the criteria. Then build.

Because sometimes the biggest technical mistake isn’t the architecture. It’s forgetting that the rules are part of the product.

If you are interesting in working or hiring me, you can contact +60109068966 via Whatsapp.

DEV Community: Developer Soo

Why my hackathon project lost — and why I’m glad it did