There is a particular kind of confusion that comes from sprinting at a hackathon, then realising the main constraint is not shared.

Halfway through the Google Gemini 3 Hackathon in Singapore last week, I noticed a "hackathon repo" that clearly did not start that morning.

And I caught myself thinking: is it still a "hackathon" if your repository was initialised three months ago?

On one side, you had teams like mine: starting from scratch, frantically drawing on whiteboards, and hoping nothing weird (quotas, auth, flaky demos) would blindside us.

On the other side, you had teams that seemed to be polishing products they had already been building for days, sometimes weeks.

I later found out one of the winning teams had a company entity established back in October.

Maybe it was a new feature. Maybe it was a pivot.

But when you are sprinting to build an MVP in 6 hours, competing against a startup's roadmap can feel like turning up for day one while someone else is already on week four, or as the cliché goes, "bringing a knife to a gunfight."

Honestly, I genuinely had a great time building with the new Gemini models in a 6-hour sprint.

It is a reflection on what we built, why we pivoted, and why I think this particular hackathon is most fun when the constraint is shared. It is also what I wish organisers were clearer about: whether this is a one-day sprint, or a longer runway showcase.

I realised I miss building things just because they feel interesting, not because they are "strategic", especially after a lot of intense work at a startup the past 6 months.

The slow start: "lock in"

I did not go with colleagues or random Discord matchups. I kept it close. I partnered with my girlfriend Joey (CS background) and my cousin Cheryl (UI/UX background), and we tried to see what we could pull off in a single day. We were not optimising for the leaderboard. We were optimising for the day. Have fun, build something meaningful, ship something real, and maybe leave with a small memory that feels like "us".

Before we wrote any code, we spent about 30 to 45 minutes just throwing ideas around.

We had genuinely serious ones, like an app that lets elderly folks record their life stories, then turns it into a sketchbook-like keepsake for their family.

We also had ridiculous ones that made us laugh, like an AI council of uncles and aunties during Chinese New Year who roast you, and you have to survive the conversation.

At some point, the group chat shifted from "ideas" to "ok, we need to lock in".

That was the first mini milestone of the day.

What we built: Hands On Track

We ended up building an interactive learning game to practise American Sign Language (ASL) finger spelling, but with a very Singaporean flavour around it. We called it Hands On Track.

If you want to try it, here is the demo: handsontrack.vercel.app.

The core loop was simple:

• Pick an MRT line
• Pick a station
• Spell the station name one alphabet at a time using sign language

At first glance, it is a bit gimmicky. But I think the gimmick is what makes it work. Learning tools can feel intimidating, and a playful theme makes the first five minutes easier (and the first five minutes is usually the hardest part). Also, it just felt very "us": slightly nerdy, slightly silly, and still trying to be useful.

The part that annoyed me: latency

Our original plan was more ambitious. We tried to integrate the Gemini Live API so the app could recognise signs from a live video stream. I was excited about that direction because it felt like the "modern" version of sign recognition.

Classically, if you want to recognise hand signs, you collect labelled examples, train a model, then retrain when you want to add new classes. With a VLM backbone and a live interface, it feels like you can do something more flexible: you describe what you want, and the system adapts without the whole retraining loop.

Of course, that is the dream version. Reality has latency, edge cases, and all sorts of nuance.

And on hackathon day, latency is not a small detail. Latency is the experience.

We were seeing around 10 seconds of end-to-end latency per letter attempt (camera in, result out).

At first I thought it was the venue Wi-Fi. There were so many people there: network I/O, API calls, everything competing for bandwidth. So I switched to my own hotspot. It was slightly better, but still far off from being delightful.

That means spelling out something like "Ang Mo Kio" or "Dhoby Ghaut" turns into you standing there waiting, watching the timer, hoping the demo does not break.

It was a humbling moment.

Honestly, I was very annoyed, and also disappointed. This was the part I wanted to showcase, and I genuinely did not expect the latency to be that bad. I spent quite a bit of time trying to reduce it, but I could not get it down to something manageable within the time we had. It is one of those engineering moments where the model works and the system works, but the product feels wrong.

The pivot (and what we gave up)

With around two hours left, we made the call to pivot. We dropped the live video approach and switched to a simpler flow: image capture per letter, with a tight countdown to keep it game-like.

This version was faster. More importantly, it was predictable. I realised that in a hackathon, "wow" only counts if the demo is smooth. We gave up the real-time recognition moment I wanted to show, but we gained something better for the day: an experience that actually worked. That ended up being the right trade-off for the day.

This is also why I was so excited about the VLM and Live API direction in the first place. If it worked, it would have been a more natural path towards supporting Singapore Sign Language (SgSL) down the line, not just finger spelling. Sign languages are not one universal language either. They are cultural and local in their own ways. Even something as "Singaporean" as durian has its own sign. I found this SgSL signbank page for "Durian".

We did not build SgSL support for the hackathon. We stayed with finger spelling. But after the event ended, we kept tinkering anyway. Small UX changes, better design flow, shaving off latency where we could. The usual post-hackathon "we should clean this up" energy.

The part that surprised me: the team dynamic

Something I did not expect was how smoothly the dynamic would go, given that this was our first time working together in this kind of setting. We had clear roles early on: I focused on the backend and agentic workflow, Cheryl handled UI/UX, and Joey worked on the frontend with Cheryl (and also deployment).

One moment that felt genuinely heartwarming for me was seeing Joey sit beside Cheryl and walk her through how we were using AI coding tools.

Things like taking designs, moving into code, using tools like Cursor.

Just iterating quickly without needing to be a "developer" in the traditional sense.

At some point, Cheryl started asking the kind of curious questions that you only ask when you can actually imagine yourself doing it too.

"Wait, how do you all do this?"

"How do you use the tool to create that?"

It was a small moment, but it stuck with me.

I hope she uses these tools to build something of her own soon.

Having a UI/UX designer on the team changes everything. The app looked good early and had a coherent theme. It was not just "a prototype", it felt like something you could imagine showing a friend without apologising first.

In a hackathon context, that matters. Judges have limited time, and so does everyone walking past your table. If they cannot understand the idea quickly, they do not get to the part where they appreciate it.

The final sprint

The last 45 minutes felt like we were living in 5-minute blocks.

"Ok, you take 5 minutes and fix that button."

"Ok, I take 5 minutes and patch this bug."

"Ok, next 5 minutes, we record the demo."

We were pressuring each other, but not in a put-you-down way. More like trying to protect each other from slipping into panic.

It was chaotic, but also weirdly fulfilling, because we actually pulled something together.

Our submission video was stitched together in the last 5 to 10 minutes before submission.

It did not clearly tell the story, the motivation, or the demo flow.

When judges have limited time, the video is the product.

Why we did not win (and why I still felt good)

We did not win, and I was not surprised. Part of it was execution (our video was rushed), and another part was technical flashiness. A lot of the top teams integrated many Google products and models. Some projects felt like full platform showcases.

We built something simpler. We used far fewer pieces of the Gemini suite (we only used a reasoning model and a TTS model). Even so, I left the day happy. It was our first hackathon-ish experience together, and we shipped something tangible. That alone felt like a win.

But if I am being honest, I do think we left points on the table.

If we had two more hours, the first thing I would fix is the storytelling.

A question I am still thinking about

There was one thing that stayed on my mind after the event. Not about who should have won, but about what the event was really optimised for.

In general, I am not against teams building early. Some hackathons literally give you weeks. But this one felt like a 6-hour sprint, and the vibe shifts when the main constraint is not shared.

Halfway through the day, I noticed something interesting: some teams seemed to be working from repositories that were clearly not created that morning. I saw LinkedIn profiles where members of a winning team had "co-founder" roles tied to the same team name months before the event (as far back as Oct 2025), and even traces of them bringing it to earlier hackathons.

I am not saying this to attack anyone. I genuinely do not know the full context for every team.

Some people might have reused internal tooling, continued an existing project, or simply came in with a more prepared foundation.

And I get it. If prizes, recognition, or recruiting opportunities are on the line, people will optimise for winning.

But it made me pause and think. What I am really questioning is the event design.

Because when some teams are treating it like a pure one-day sprint, and others are effectively treating it like a showcase of ongoing work, it can feel like two different games being evaluated on one scoreboard.

If the event is meant to celebrate improvisation and building under pressure, then a shared time constraint is part of the fun.

If the event is meant to showcase innovation, then allowing pre-built foundations makes sense.

Both goals are valid. I just do not think they should be mixed without clarity.

Hackathons feel most fun when the constraint is shared.

So here are the questions I am still thinking about:

• Should hackathons have explicit categories (one-day build, multi-day build, startup showcase)?
• Should organisers be explicit about what "allowed" means (templates, old repos, pre-built components), instead of leaving it vague?
• What does the "hacking spirit" actually mean, and who gets to define it?
• If fairness is a spectrum, what small rules could nudge things towards a more level playing field, without turning it into an audit?

I do not have a perfect answer.

But I do know that I enjoyed the day more because we treated it like a true one-day sprint, even if it reduced our odds.

And I think that preference says something about what I want from hackathons, and maybe from building in general.

Closing thought

I went in thinking the best part would be the final demo.

The best part was the process.

Negotiating constraints, making trade-offs, laughing at bad ideas, and then watching something real appear on the screen.

And for us, I think the best part was the fulfilment of watching everything come together.

Even though we were a first-time team with pretty different strengths.

If you have done a hackathon before, I would genuinely love to hear your take.

Should hackathons require projects to be built from scratch during the event, or should anything go as long as it is interesting?