HackathonPic!

This blog post covers how I vibe coded an web app to fix a real life issue I was facing and ended up in the top 10 teams at the SEABW (South East Asia Blockchain Week) Bangkok hackathon. I’ll also walk through the strategies I used, my workflow, and my learnings.

The SEABW conference took place at IconSiam Mall in Bangkok from May 20-21, 2026. As part of the conference, they conducted a 24-hour vibecoding hackathon where participants had to solve a real life problem using AI.

https://www.seablockchainweek.org/hackathon

The Problem

The problem I was trying to solve was how to efficiently order food at a local street food vendor in Bangkok. I’ve passed by multiple small food stalls across the city, but many had no menu listed in English, or no menu at all. You can use translation apps to communicate with the vendor, but they’re often busy serving other customers and don’t have time to stop. I wanted to build something a vendor could set up just once, so that a tourist or expat could easily order without any friction.

Before the Hackathon: Tools and Preparation

Before the hackathon started, I researched various ideas around problems I face in my life and tried to come up with features to build. I also spent time looking into infrastructure providers that handle most of the setup, so I could focus purely on building with AI. That’s how I shortlisted Railway. I also set up a free Supabase account in advance for any database requirements.

One more decision I made early was I wanted to build this project entirely with Claude. I’d mostly used Cursor before this, in combination with ChatGPT or Claude, but I wanted to build this project entirely with Claude.

Hackathon Day: Building soifood

I named the project soifood.

In Thai, soi means street or alley, the narrow side streets of Bangkok where the best food hides. So soifood is quite literally street food, named after the place you find it.

When the hackathon started, I worked with Claude to write a PRD for the project and define the features I wanted to build in the first phase. I then asked Claude to commit everything into a CLAUDE.md file. I also updated it with the technology choices I had made upfront and the APIs I was going to use. On top of that, I added a design system for the entire project, which I came up with after brainstorming with Claude. It was based on Benjarong hand-painted Thai porcelain.

After all this groundwork, it was time to start building. I had already broken the project into phases so I could build iteratively and test as I went. This may not be how everyone works, especially with many people one-shotting apps these days, but I wanted that control. From there it was fairly straightforward. Claude asked clarifying questions as we built out each phase one by one. Everything moved smoothly, except for the deployment on cloud provider - Railway, which became a significant blocker.

Railway Outage, Switching to Render

On the day of the hackathon, Railway , the cloud provider I chose was suffering one of its biggest outages to date.

I noticed slow deployments and GitHub pushes not being picked up. That’s when I checked the Railway status page and discovered they had supposedly just recovered from an outage caused by Google Cloud suspending their GCP account. Even though all the status indicators showed green, I was still experiencing issues and had to reach out to their support on X. After multiple reports of lingering problems from other users, they updated their status page to confirm the platform was still unstable.

Full incident report: https://blog.railway.com/p/incident-report-may-19-2026-gcp-account-outage

My support tweet: https://x.com/rahul_r007/status/2057049476465102997?s=20

After that, I made the decision to switch to Render. Claude helped me make the switch within minutes.

Building the Presentation Deck with Claude Design

For the presentation deck, I started with a rough idea of how I wanted the story to flow, then brainstormed the outline with Claude. After that, I used Claude Design to build the actual presentation, which worked really well. Making edits directly in the deck with Claude Design was easy and fast.

Top 10 and the Final Presentation

On the second day, I found out I had made the top 10 teams. Shortly after, we had 10 to 15 minutes to present our deck in front of a panel of judges.

At the end I was asked a couple of questions, which I think I could have answered better because there were other important points which I missed to include due to time constraint. But overall it was a great experience, from preparing the presentation to answering questions under a very tight schedule. From receiving the shortlist notification to presenting, I had roughly an hour to prepare. The best part came after the presentation. A VC in the audience came up to me afterwards and said this was a problem he faces frequently in Bangkok. He loved the deck and asked what I used to build it. He also gave tips on how I should have responded to the judge’s question.

Learnings

  • Focus only on core working features in hackathons. Even though I had multiple ideas, one or two working end-to-end flows are worth far more than multiple partial ones.

  • Prepare properly for panel questions. I had thought through some questions the judges might ask, but I hadn’t prepared strong enough answers for all of them. That’s the part I would do differently.

  • Commit after every working phase. Claude Code would sometimes break UI while working on an unrelated change. Having every functional phase committed meant I could easily undo any regression without losing progress.

  • Platforms like Railway and Render are great for 24-hour hackathons. You don’t have to worry much about infrastructure and can stay focused on building core features. Just check the status page before competition day.

  • Don’t rely solely on status pages when things aren’t working. When Railway’s status page showed green, I assumed the issue was on my end and spent time checking my GitHub hooks and deployment setup. It was only when I checked X that I saw other people were still reporting problems. Status pages don’t always reflect reality in real time.

  • CLAUDE.md is underrated. Claude Code already knew the stack, the build order, and what not to build. That helps save a significant number of tokens and avoid a lot of unnecessary back and forth.

  • Sleep well the night before. It sounds obvious, but it goes a long way when you’re standing in front of judges trying to think clearly with a rested mind.

Presentation : https://github.com/r-r-2/soifood/blob/main/soifood-presentation.pdf

Repo Link (More technical details can be found there): https://github.com/r-r-2/soifood

Video of my Pitch: https://www.youtube.com/watch?v=M7V4j2BNFh4

SEABW Website : https://www.seablockchainweek.org/hackathon

Official Tweet with all winners and shortlisted participants listed : https://x.com/SEABWofficial/status/2057400901418319973

A big thank you to the organisers at SEABW and the hackathon sponsors. They kept everyone well fed and hydrated throughout the hackathon, and ran a well organised event at one of the best malls in Bangkok.