My First Commit hackathon experience: building Beacon Night Shift

Over the past months I've been doing hackathons back to back, always looking for the next idea worth building. Some weekends went well and some didn't, but each one taught me something new. When First Commit opened up, I knew I wanted to build something that solved a problem people really feel. First Commit  was the first event of the Bharat Builds Tour by WeMakeDevs  and AWS, and more than 13,000 people registered for it.

The idea came from thinking about on-call engineers. Every company that runs software has someone whose phone goes off when something breaks, and it almost always breaks at the worst possible time. Picture it: it's 3 AM, payments are failing, and an engineer is sitting in bed half-asleep with a phone in their hand, scrolling through logs. They need four answers quickly. Is this real? What changed? What do I do? Can I go back to sleep? Getting there takes a long time, and a lot of that time goes into just figuring out where to look. The most frustrating part is that the same issue often comes back a week later, and the same person gets woken up to do the exact same fix all over again.

So I built Beacon Night Shift, an on-call assistant you can talk to. When an alert fires, Beacon looks at the logs and at what changed recently in the system, works out what went wrong and explains it in plain language. You don't have to dig through dashboards. You can just ask it "what changed?" or "can you fix it?" and it answers with the evidence behind its answer.

The part I cared about most was trust. An assistant that can change things in production has to be careful, so Beacon never acts on its own the first time. It suggests one safe fix, tests it without applying it, shows you exactly what it will touch and then waits. Only when you say "approve fix one" does it go ahead. Even then, it doesn't just assume the fix worked. It keeps checking until it's sure the problem is really gone, and if anything looks off, it hands things back to a human.

Then Beacon asks one more question: should it handle this same issue by itself next time? If you agree, you give it permission for a limited time, and only for that exact problem. I called this a Sleep Contract. The next time the same thing breaks, Beacon fixes it quietly and leaves you a short summary to read in the morning. Nobody gets woken up. That moment in the demo, where the second incident gets fixed and the counter shows zero people woken, was the whole reason I built it.

You can watch Beacon in action here: https://youtu.be/a3SxZHvIkCo 

Under the hood, Beacon runs on AWS. Amazon Bedrock handles the reasoning, AWS Step Functions runs the fix-and-verify loop, and Amazon Transcribe and Amazon Polly let you talk to it by voice. DynamoDB, Lambda and CloudWatch tie everything together. Most of my effort went into the safety side. Beacon can only take a small set of actions, and it only acts on what you actually said out loud, never on what it thinks you meant.

The four days of the hackathon went by in a blur. There were late nights, things breaking at the worst moments and more than one fix just before midnight. On the first night alone I ran into one setup problem after another, and some of the things I'd planned turned out to work very differently from what I expected. Late that night I also found a bug that could have let the assistant approve a fix you never agreed to. For a tool built around trust, that was the scariest thing I could have found, and fixing it before anyone else saw it was easily the best moment of the weekend.

One small habit saved me again and again. I wrote down every problem the moment I hit it, with the time next to it. When you're tired, you forget what you fixed and why, and those notes later became my demo script and, in a way, this article. Before submitting, I also set the whole project up from scratch the way a judge would. It broke in two places that never broke on my own machine. Catching those before the judges did made a big difference. On the last day I recorded the demo, cut it down to three minutes, took a deep breath and hit submit.

When the results came out, Beacon had won the Build It track. Soon after, I got an email saying I'd been selected for a fast-track interview with Amazon. It still feels a little unreal. A month ago I was jumping from one hackathon to the next just to keep building, and now one of those ideas has opened a door I didn't expect.

If I had to share a few lessons from this weekend, they would be simple. Pick a problem real people deal with, even if it sounds ordinary. Keep the idea small enough that you can finish it properly. Test your project the way someone else will see it, not just on your own setup. And write things down as you go, because those notes will help you more than you think.

I want to say a big thank you to the AWS team for the workshops, the mentoring and the thoughtful feedback throughout the event. Having people from Amazon so involved and so approachable made First Commit special. A huge thank you to WeMakeDevs as well, for organising everything so smoothly and building such a welcoming space for developers across India. Congratulations to all the other winners and participants too. Going through everyone's projects afterwards was really inspiring.

This was one of the best hackathon experiences I've had, and I'm already looking forward to the next Bharat Builds Tour event. If you've been thinking about joining one, just sign up. One weekend can teach you more than you expect.