Hack N’ Roll 2026

If you don’t know what Hack & Roll is, it’s a 24 hour hackathon where you can build whatever you want - no problem statements.

This year I actually saw the sign up information on time, so I decided to join. Sadly, my friend failed to join so I was alone in this enterprise (at first…)

I found some group mates through the Discord, and met up with a group that consisted of 2 NTU students and a Y1 NUS student (all CS if I recall).

I mentioned in another post that one of my learning outcomes for this semester was incorporating AI use in a manner that makes sense and actually improves productivity. With that in mind, I had one pertinent goal in this hackathon: Overuse AI. I wanted to figure if I just delegated most of my work to AI, would it be feasible? At what point do we feel productivity gains/losses? I wanted to explore this. So my workflow was mostly using copliot in a JetBrains IDE (I had yet to finish choosing a proper AI provider)

The Brainstorming

After a particularly productive brainstorming session, we had several ideas that we were unsure would work. One that I really wanted to do was to create an alternative front-end for the NUS library booking system.

I went as far as creating a rooted emulator to scrape the Backend “Chope” API with, before realizing that spoofing authentication would be a nightmare. And that if I could actually do it it’d be quite concerning overall. But I had some fun booking sessions through Bruno with scraped JWT first.

The idea

Well, we met on the day itself with nary a clue on what to build. Somehow we landed on making a splitwise clone but with baked-in gambling features. After thinking about it more and more, this was an idea that I actually liked a lot. I LOVE GAMBLING!!!!. We were going to call it PayOrPray.

i should probably add a disclaimer that you should not believe this, but if you even think it does i'm afraid you're too far gone buddy

The hacking

Met up with the group mates and we began hacking at about 1pm (we got lunch at hwang’s first, shoutout).

I don’t remember most of the timings actually, so it’s kind of a rough guess down here. I’m also using git commit times to roughly tell.

1PM

At first, we weren’t sure how to proceed, so I organized our group into 3 teams that could tackle tasks in parallel.

The first team was to work on front end:

The second team was to work on back end:

The third team was to work on deployment and architecture:

4 people among 3 teams, so one person could hop around where necessary.

It was a rough plan, but it was working. We were able to work well in parallel.

I was mostly working on Back end.

3PM

A basic API spec was created. We finished figuring out how to generate paynow QR codes on demand for settling debts.

We integrated SupaBase as a DB provider into the App.

A design was created.

All seemed to be going quite well and optimism was in the air.

5PM

We fixed up a login page on the Front end using SupaBase auth.

Back end endpoints were being implemented.

6PM

As we went along, we realized we needed one or two more endpoints.

We implemented an /invites system to the Back end. Fully integrated JWT auth with the Front end.

Front end was being fleshed out and integrated with the Back end.

9PM

I encountered the first non-trivial (ie non CRUD-related) issue at this time. We were thinking of how splitwise actually does the “simplify debts” feature, and realized it’s not simple.

I’m very glad that people have looked into this, because there was no way I was figuring out that it required utilizing Digraphs and Maxflow algorithms on that night - I was already groggy and tired.

If you’re interested, the algo is here. So I just had to adapt the code to JavaScript.

I was eventually able to do it, and we had an endpoint that was able to return the simplified debt payment data.

11PM

By 11pm, things were looking good. We had a solid application that was able to do expense tracking and debt-payment, with authentication. The app looked pretty good on mobile too.

We had a few more things to do:

  1. Polish up the front end - there were undesired UI elements that could be removed
  2. Add actual gambling elements - we just needed the frontend components to do so
  3. Integrate the invite system into the frontend
  4. Some refactoring if we had time - codebase was a mess
  5. Deploy

My team mates decided that they weren’t going to be staying overnight, but I decided to stay. There was still things I wanted to complete in the app, and it was getting too late for me to take the last bus back home. I was not going to pay for a taxi.

Midnight.

So from midnight onwards I was working in a pure hallucinogenic mind-melded hyperbolic-time-chamber coding fugue state. My brain was shutting down and I saw miracles in the in-betweens of lines of code. I saw software in its distilled purest state, and I was terrified.

I was mostly vibecoding.

3am

I only know what happened till 3am because I sent a message to my group: I:

6am

So uhh yea by 6am I really was in the trenches. I recall sleeping on a random bench somewhere for about 30minutes before the sun starting peeking at my eyes and I awoke.

9am

After my short sleep and some inadequate breakfast, I did this:

YAY!

11am

After that, my team mates came and met up with me again. I can only imagine how I looked and what they thought when they saw I, an ascended software wizard who was diligently at his craft throughout the night, remaining seated at the same seat they saw me in when they left at 11pm last night. Perfection is often ugly.

Not much changes after that, and I left soon because my body was shutting down.

The result

main page
trip page
gambling

Conclusion

Pretty happy with how that turned out! Of course, some things could be improved, but in 24 hours and one overnight session I’m satisfied.

My experience with vibecoding is mixed.

Things it was good for:

Creating API specifications in a standardized format (openapi.yml) after passing it natural-language instructions. Goated.

Brainstorming API and Architecture layout. I think straight up asking it “what should I do is bad”, but if you provide it with baseline expectations and thoughts, it can provide some value.

Things it was okay at:

Implementing back end endpoints from specifications. It’s hit or miss, but using few-shot prompting helps a little.

Things it was horrendous at:

Debugging. I attempted to ask it to debug a few problems, but it was a bad experience. The flow of prompting AI > letting it incorporate changes > test is pretty wonky. I feel like debugging by using your brain is still better.