Reflections on the “Gemini AI Hackathon @ Google Japan in Tokyo”

A developer reflects on lessons from the Gemini AI Hackathon @ Google Japan in Tokyo, where over 300 participants gathered to build AI projects with Google Cloud and Gemini. The developer notes that many attendees worked individually, aided by AI coding tools, and shares plans to improve time management and start with minimal viable versions in future hackathons.

Starting this month, I’ll be participating in the 5th Agentic AI Hackathon with Google Cloud. The program kicks off with “Build with Gemini Tokyo” on September 3 and 4, where participants will build AI projects using Google Cloud and Gemini. Since I’m taking part, I want to approach the development process more effectively this time than I did at my previous hackathon. Before it begins, I thought it would be useful to reflect on the Gemini AI Hackathon @ Google Japan Hackathon Tokyo, which I attended in June 2026. The previous event was a one-day hackathon organized by AI Builders and Google Japan. With only about five hours of actual development time, participants had to build an AI project, deploy it to the cloud, and present a working demo at the end. I attempted to build an app using health data from my Apple Watch, but I wasn’t able to complete it before the event ended. The immediate cause was that six months of health data exceeded 1 GB, making it difficult to import into the app successfully. Looking back, however, the real problem wasn’t simply that I had “1 GB of data.” Despite having only around four hours to build the project, I started with the full production dataset instead of first creating the smallest possible version that could work from end to end. I also failed to plan my time properly. I focused mainly on implementation without setting aside enough time for deployment, the demo, and the final presentation. To avoid making the same mistakes this time, I want to reflect on what stood out to me at the previous hackathon and organize the lessons I plan to apply to my next one. When I arrived at the Google office that day, the first thing that surprised me was the long line outside the entrance. I had heard that there would be a lot of participants, but once I joined the queue, I realized the event was much larger than the small study-group-style gathering I had imagined. I do not know the exact number of attendees, but my impression was that there were more than 300 people at the venue. What also stood out was how international the crowd felt. Based purely on what I observed, there seemed to be many participants from a wide range of backgrounds, with people from overseas appearing to make up a significant portion of the audience. I had expected the event to be mostly local, so the diversity of the participants was one of the first things that caught my attention. This is only my personal impression from being at the venue and is not based on confirmed information about participants’ nationalities or backgrounds. Before attending, I had always imagined a hackathon as an event where several people formed a team, divided up the work, and built a single product together. But once the development session began and I looked around the venue, I noticed that many participants were actually working on their own. I did not count everyone, so this is only a rough estimate, but it seemed that around 70–80% of participants were coding individually. Even among those working in teams, most appeared to be in small groups of two or so. During the opening briefing, the organizers introduced Google Cloud and several related products, as well as tools that allowed participants to write code from the CLI with AI assistance. With AI coding tools, it is becoming much easier for a single person to turn an idea into something that actually works. You no longer need a large team just to get a prototype off the ground. Looking around the venue, I felt that the rapid improvement of these tools may be encouraging more people to think, “I’ll try building it myself first.” As I remember it, the event began with about one or two hours of introductions and explanations, followed by roughly five hours to build a product. That development window had to cover much more than just coding. Participants also needed to deploy their projects to the cloud, record a demo video, and prepare presentation slides. If the goal had simply been to build an app, five hours might have felt manageable. But getting something working, deploying it, preparing a demo, recording a video, and putting together slides for the final presentation made the schedule feel extremely tight. Once I started working, the time seemed to disappear almost immediately. Participants were also given Google Cloud credits as part of the event. As I recall, the amount was somewhere between ¥10,000 and ¥20,000, although I was unable to confirm the exact value or the conditions for using them. At the time, I was already subscribed to Google AI Pro, so I decided not to use the credits immediately and thought I would save them for later. In the end, however, I never used them. At the time, I was interested in health and fitness, so I decided to build an app using health data collected from my Apple Watch. The idea was to visualize the data and generate personalized suggestions based on each user’s health information. However, during development, I realized that my own health data had already exceeded 1 GB, even though I had only been using an Apple Watch for about six months. This was not just a case of the dataset being “larger than expected.” For a hackathon with only a few hours of development time, it was simply too large to work with efficiently from the start. In practice, I was unable to upload the data successfully to the app I had deployed on Google Cloud, and I ended up spending a significant amount of time troubleshooting the issue. I could not determine during the event exactly which service or limitation was causing the problem, so I cannot say that any particular technical constraint was responsible. In the end, I ran out of time before I could complete the product. Looking back, I should have started with a small sample dataset and first confirmed that the entire workflow—from uploading the data to processing and displaying it—worked end to end. I also should have had a fallback plan, such as splitting the dataset or switching to a smaller version for the demo if the full dataset proved too large. The biggest problem was not that AI coding tools failed to generate the code I needed. It was that I introduced a large, production-like dataset before confirming that the basic workflow worked. With only a few hours available, checking the size and format of the data should have been part of my preparation before the hackathon even began. At the end of the event, I had the chance to watch demos from some of the prize-winning participants. Their UIs were polished enough that it was hard to believe they had been built in just five hours, and the projects had already been deployed to the cloud. Some were even multimodal apps with features such as voice input, rather than simple prototypes that only displayed information on a screen. While I had spent much of my time struggling with a 1 GB dataset, other participants had managed to take their projects this far within the same limited timeframe. Seeing that was both impressive and motivating. Watching the winning demos, I got the sense that there was very little hesitation between coming up with an idea and turning it into something that worked. Of course, I did not see their actual development process, but I suspect they had decided early on what they wanted to build—and, just as importantly, how far they needed to take it. At the same time, some presentations seemed less polished than the products themselves. The apps worked, but a few presenters appeared unsure about what to explain first or how to structure the demo. It made me realize that if you spend every available minute on implementation, you leave yourself almost no time to rehearse the presentation. There were, of course, also some excellent presenters. Within a few moments, it was clear what they had built, why it mattered, and what they wanted the audience to pay attention to. I learned a lot simply from watching how they structured their demos. I also noticed that many of the presentation slides had a similar visual style. I wondered whether participants were using a common Google Cloud template or generating their slides with AI, although I did not confirm this, so that is purely speculation. What stayed with me most was this: as implementation becomes faster, the differences in everything surrounding the implementation become more visible. How narrowly did you define the scope? How well did you prepare your data? When did you decide to stop coding and start preparing the demo and presentation? I think this stood out to me because I saw all three things in the same room: highly polished winning projects, presentations that appeared to have run out of preparation time, and my own project that never made it to the finish line. The experience made me realize that in a short hackathon, coding speed alone is not enough. Scoping, preparation, time management, and presentation are all part of building the final product. At this hackathon, I was not able to finish and submit a completed product. Looking back, the main problem was not a lack of AI coding skills. It was that I failed to narrow the scope, decide how far I needed to take the project within the limited time, and validate the workflow before introducing a large, production-like dataset. At the same time, I saw many participants working alone and still managing to complete their cloud deployment, demo video, and presentation within just a few hours. With AI-assisted development, individuals can now turn ideas into working products much faster than before. Experiencing that firsthand was one of the biggest takeaways for me. But I also realized that as implementation becomes faster, the skills surrounding implementation become even more important: deciding what to build, preparing the data, managing time, knowing when to stop coding, and communicating the result clearly at the end. Next time, I want to approach the process differently. I will first test the entire workflow end to end with a small sample dataset. I will decide in advance when to stop implementation, and I will treat the demo and presentation as part of the product itself rather than something to prepare at the very end. Because I failed to finish this time, I now have a much clearer idea of what I need to change. At the next hackathon, I want to apply these lessons directly and make sure I take the project all the way from idea to working demo.