LY HackU 2025
Before we dive in
I initially went to Korea for travel before this Hack U hackathon, while staying Korea, we stayed at Myeong-dong for all nights. For those of you don't know Myeong-dong, it's like tourist populated area. I felt a little bit dissapointed because I wanted to try some unique experience during my stay. That's the story I brought to the initial team meeting.
Before traveling,
- Conversation with friends on where to go and what to do, but it's difficult to actually make plans and book.
- Traveling with friends, always unclear what group chat was meant for.
So in order to raise user experience on the LINE group, we should come up with an idea to see whats group chat was.
Frontend
To speed up production and try AI driven framework, we use the v0. Interestingly, our mentor was Research Scientist at Image and Video AI Dept., LY Corp. He can advise on deep learning-based product design.
Implemented with mobile UI in mind
Our idea on travel web application focused to mobile users, therefore determined our minds to mobile UI was great idea. You are welcome to try this web application out
Deployment might be down
Calling too many processes with useState causes the database to crash
Using free tier database is bad idea for hackathon, especially on 2 weeks long hack. When building our database endpoint and testing calls, there was no issues at all since I was the only one calling endpoint. But when it comes to actual demo, there could be numbers of users calling endpoints. We could limit traffic to database pool size, but rather we should use pro tier instead.
This is the part of frontend code, trying to fetch travel data from the database and setting loading when fetching is incomplete and calling endpoints until its done. In this structure, it calls endpoint more than expected and might over call database. The over-calling issue likely comes from the useEffect dependency triggers. I believe in this generation of generative AI, we should focus on performance and code review to prevent such over-calling and triggering issues.
Backend
Since everyone in the group understands Python, we chose FastAPI as our modern, fast, web framework for building APIs. As a result, we could be on the same page when we code review, however, thinking of learning new skills as hackathon and performance, we should probably chosen other API framework.
Thinking on our platform, this heavily depends on backend API. When there are chat, we need to call backend API to store data into database, when generating travel plan, we need to call backend API to generate, then store data in database. With this platform, we should chose golang.
The directory structure was not complete
When doing a project, we should always come up with data structure, repository structures, and coding rules. Questions that we can ask are:
- Where should we have our testing code (i,e, under src/**/*.py)
- What repo structure we should take? (i,e, MVC)
- Should we have schema or model?
- Should we follow SOLID principle?
We should have gone through CI properly. There were many hotfixes
I personally making 150 test cases and 8 linting checks before merging code into developing stage, but I underestimate the power of CI (Continuous Integration) actions this time. I thought CI is unnecessary since we are doing 2 weeks hackathon and we should focus on developing rather than maintaining coding rules and building checks. However, I noticed the power of CI when there are in rush. Rather than making sure all endpoints works by hands, we should've build our CI tests to see if they all works. This would strength our code clarity and eventually speeds up our development.
LINEbot
To connect our app to LINE, we created a LINEbot that listens for messages and takes action based on keywords and user interaction. For example, when a user sends "旅の計画して" ("make a travel plan"), our backend would call the itinerary generation endpoint and send a carousel message to the LINE chat with a proposed itinerary.
Although deploying the LINEbot on Render was fast and easy, we quickly ran into issues during debugging. The free Render logs truncate after a short period, making it hard to trace issues that happened during sleep/wake cycles or when webhook delivery failed. Without persistent logging or error notification, we sometimes didn’t even notice our bot had silently failed.
Next time, we should either:
- Use a more production-ready cloud environment with log retention (e.g., Fly.io or Railway).
- Integrate external logging services like Logtail or Sentry to track errors and usage metrics.
Thoughts for next time
We should have defined the design and requirements from the start
Jumping into development without a clear design or requirements led to inconsistent UI and scattered feature priorities. A shared understanding of the user flow, interface elements, and technical constraints would have aligned the team from day one and prevented rework.
We should have focused on a single, specific use case
Trying to support multiple travel scenarios—solo trips, group trips, and casual weekend outings—spread our attention thin. If we had narrowed the scope to just one clear use case, like "planning a 3-day group trip via LINE chat", we could have crafted a more refined and delightful experience.
We should have clarified the product vision early
Without a solid product vision, even small decisions like which icons to use or how to structure the itinerary became arbitrary. If we had asked ourselves early on, “What experience are we trying to create?” we would’ve had stronger sense of direction, from both the design and technical perspectives.
We should have prioritized user feelings over code
As engineers, it’s easy to get caught up in logic and optimization. But for products like travel apps—especially inside messaging platforms—the user's emotional journey matters just as much. Instead of asking “Is the code clean?” we should have asked, “How does the user feel at this moment?” Whether it’s excitement, confusion, or delight, designing for emotion is what brings a product to life.