There's a moment after a race when you turn the engine off and everything goes quiet. That's where I am with competitions this year.
Races --- 5
Wins --- 2
Two Wins and a Dangerous Habit
I won 2 big dev challenges this year, and it got me so hyped that I couldn't stop entering more and more of them. Winning does that to you. You start refreshing the challenges page like crazy.
Then I found out I hadn't won my latest challenge. Did that slow me down? Not even a little. It made me want the next one even more.
The Idea That Never Showed Up
So I set my sights on the next one: the Presage SmartSpectra SDK Challenge.
I was fired up to get started, even though I had no idea what to build.
That's how it usually works. You never know which challenge is coming next, so you come up with an idea on the run. Metal Birds Watch literally started as a word association: Copilot, Pilot, Airplanes. Give me 2 or 3 days and something always clicks.
Back in May, during the Gemma 4 challenge, though, I had the opposite problem. I had so many ideas for the challenge that I couldn't pick one, and I ended up building an app for exactly that problem.
But This Time It's Different
It's been 4 or 5 days and I still have nothing. I've hit the ceiling.
I don't want to build something just for the sake of the challenge, because even if I won, it wouldn't feel special when I look back at my GitHub repositories. I want to build something I'm proud of, not something AI suggested. That's not how we roll here. If even I don't care about my creation, how do I expect that someone else will?
Effort Doesn't Guarantee a Win
There's another thing. After my recent losses, I realized that no matter how much energy and passion you put into a project, it doesn't guarantee a win.
For my last entry, I wrote every dataset by hand, and I finished the project with one eye patched up after a small surgery on my eyelid. It didn't matter.
You can drain yourself to the point where you can't think clearly the next day, and it still won't matter. Someone might come up with a better idea, build it better, or make a better video about it.
The judges only care about the end result, and rightfully so.
All In or Not at All
DEV challenges take a huge chunk of my free time, energy, and mental resources. If I commit to one, I have to go all in. There's no other option.
That was great in the first half of the year, when I was relatively fresh. Now it's a little different. It might be burnout, which I don't really pay attention to because I'm used to it. But I have so many other things going on right now that it's just harder to make time for challenges. I have a lot of personal projects to maintain and new articles and videos to create. I don't want to take any more time from them.
I've also noticed that people appreciate the things I create on my own even more, with no challenge attached, and I love that. I have so many cool ideas, and I need to ship them before someone else does.
Confessions of a Competition Junkie
I'm a competition junkie, though. I love the anticipation of the results and the huge spike of adrenaline and dopamine when I hear I just won. Oh god, I still remember winning those 2.
Let's recap the year real quick.
The Wins
Metal Birds Watch
Metal Birds Watch (GitHub Copilot CLI Challenge). A real-time aircraft tracker that watches the sky (using a public API) for you and notifies you when a plane flies over. It groups users into grid cells for caching, which was something that I came up with, and I'm still extremely proud of.
Check out the video:
NoteRunway
NoteRunway (Notion MCP Challenge). A cleanup crew for your Notion workspace. Seven tools hunt down duplicates, dead links, stale pages, and the API keys you swore you'd move later, and nothing destructive runs without your approval.
Check out the video:
The Losses
Sunday DEV Drive
Sunday DEV Drive (Weekend Challenge) a synthwave driving game where your DEV articles become neon billboards along an endless road. Enter a username and cruise past your own titles and quotes. I built it in a weekend with Three.js and no build tools, and the car is made from 46 boxes.
Check out the video:
NeuralHats
NeuralHats (Gemma 4 Challenge). Six AI personas, all running locally on Gemma 4, debate any topic using Edward de Bono's Six Thinking Hats. The Blue Hat decides when the debate is over, and a seventh model writes the final report.
Check out the video:
Georgian Language Benchmark
Georgian Language Benchmark (Kaggle Benchmarking Challenge). Eight OpenAI and Anthropic models against five Georgian language tasks I wrote by hand. They understand Georgian almost perfectly. Producing it correctly is a whole different story.
Sorry, I don't have a video for this one (yet).
So 2 wins out of 5. That isn't too bad. I also entered a couple of writing challenges, but I'm not counting those, because you don't really build something new for those.
I REALLY wanted to make it 3 wins this year, but as they say, you can't win them all. Sometimes you need to lose to adjust your approach and style.
Not Done Yet, Haven't Even Started
Am I done with challenges for good? Oh, no! I'm not going anywhere. I'm just getting started.
The moment I hear about a hackathon where I can build something really good, I'm in, guaranteed. And I'm going for that win with all I've got, down to the last ounce of energy. There's no other way for me to do things.
But for 2026, the engines are off, but only for hackathons.
Other than that, I'm going to be even more productive. I still have a few projects and articles to create.
And for those of you who follow me closely, you're in for a treat. I'm cooking up a few good things. Stay tuned.
Let's stay connected!
Top comments (12)
Hi winner bro! We are win on a same challenge: copilot cli.
Enjoy the rest of the year and relax, power up is mission critical!
My result a bit worst: 1/9 or 1/7/(2x?) I don't know Hacktoberfest week 3 and 4 result, so maybe I am in the race with hexaw and Singularity Game also.
But right now I found a hidden gem of hackhaton which is seems nice to me:
Meta VR competition So I try to make something with my 3D engine.
Winning that challenge was incredibly challenging, over 400 people signed up, so well done! I remember your project, it was awesome!
You applied for 9 challenges? That's a lot!
2 wins out of 5 is honestly an amazing run! 😸🎉
But I also really like the decision to stop when you no longer have an idea you genuinely care about.
Sometimes knowing when to turn the engine off is a win too. 🏁
I’m looking forward to seeing what you build next when there’s no challenge telling you what to make! 🙌
When there's no challenge telling me the rules, I get 10x more creative. So expect some good stuff.😊
I'm not surprised at all! That's exactly why I don't participate in these challenges. I have the same all-or-nothing mentality, and they're so time-consuming!
But I have a very similar problem with conferences. One day I wake up and realize I've somehow ended up speaking at a conference every two weeks, all across Europe, of course, with absolutely no time left for anything else! 😂
So I totally get it. Sometimes you just have to let go a little. And that doesn't necessarily mean doing less, just choosing to focus your time and energy on different things.
Actually, one of the reasons why I decided this way is to focus on doing other stuff as well, including conferences. I gotta start somewhere, but if I'm not able to say no each time they announce a new challenge. I ain't gonna have any time for it.
The NoteRunway part caught my attention, especially the decision to keep destructive operations behind user approval.
One thing I'd be curious about is how you handle the gap between approval and execution. For example, if an agent proposes deleting a set of duplicate pages, gets approval, but the underlying workspace changes before the operation runs, the original approval might no longer represent the action being executed.
I'd bind the approval to the exact operation, including the target resource IDs and parameters, then validate that scope again at execution time. Adding idempotency keys would also help prevent duplicate operations if an MCP call times out and gets retried.
It's a small architectural detail, but it makes a big difference once an agent moves beyond suggesting changes and starts modifying real user data.
Also, two wins out of five is a solid run. Knowing when to stop building for a scoreboard and put that energy into projects you actually want to ship is an interesting decision in itself.
It definitely was an interesting project. As for your question, by design, if the state changes (for example the page gets deleted by another process), it'll simply not do any further action. But I need to think about if it's necessary to warn the author if something changes in that page before deletion. Good point.
That makes sense. I was thinking about a slightly different edge case: what if the page still exists, but its content or relationships have changed since approval?
For example, a page gets flagged as a duplicate, but while the approval is pending, someone edits it or adds new backlinks pointing to it. The existence check would still pass, even though deleting that page might no longer be the right action.
I'd probably handle that with version-based validation. Capture the page's revision or ETag when the approval is requested, then execute the deletion only if that version still matches. It's similar to how HTTP
If-Matchworks with conditional requests. If the version has changed, abort the operation and ask for approval again, ideally showing what changed.I'm not sure whether Notion's API exposes a revision token that can be used for an atomic conditional delete, but I think that's an important distinction between checking whether a resource still exists and checking whether it's still the resource the user actually approved.
Two wins out of five is a strong year by any measure, and the part that stuck with me was your rule for stopping: not building something just because a challenge is there. That takes more discipline than entering, especially after a win. Resting the engine now so the next idea is one you actually care about sounds like the right call — looking forward to what you build on your own terms next.
Thank you!
Stopping mid-task is hard because work in progress has no natural receipt. A lightweight shutdown note—current state, next smallest action, and an explicit not-doing list—can preserve continuity without making rest conditional on closing every open loop.