What I Built
For Kyoto University's November Festival, we built PENGUIN, a web platform that lets student groups complete the procedures needed to exhibit projects online.
PENGUIN is a project developed continuously every year. Its frontend used to be written in Django, but in the year I joined the November Festival Office, the frontend changed to Next.js. I began leading development a year after joining, when I was in my second year of university.
The frontend is built with Next.js and shadcn/ui and deployed on Vercel.
The backend is built with Django REST Framework and deployed to a Kyoto University VM using Docker.
How The Team Worked
The development team had three members from my year and four juniors. The younger members needed training, so I had to teach while also building features. For each feature, we split frontend design and backend design ownership, assigned people to implement them, and I also joined implementation while checking progress, reviewing, and organizing blockers.
When I became the person in charge, the first thing I did was interview related departments. I asked which departments needed what information and what student groups needed to input, then split requirements by feature. Because we had to handle not only project content, location, equipment, food, and checks by each department, but also case-by-case special handling, the implementation plan often became complex.
On education, honestly, I cannot say it went well. It was extremely difficult to train new members in a short period while also shipping production features. Because I already had programming experience, I failed to understand how much time learning would require. There also had not been enough handover, so I could not judge properly what to teach and how far we could get in time. That is my biggest regret from this project.
Maintenance And Design Consistency
In the year I led development, only one year had passed since PENGUIN adopted Next.js. Each owner had different ideas about page structure, and there were UX issues. I created shared design tokens for the whole website and built PENGUIN UI, a unified UI component set based on shadcn/ui. I did this alone by my own decision, but it raised the team's awareness of design and I think it had a good effect.
Security Work
Because there had been an incident the previous year, I paid close attention to security during production operation. To avoid exposing direct access to the VM hosting the backend, we routed the website through Cloudflare and reduced DDoS and direct-IP risks. We moved before the IP appeared on services such as Censys, so at least exposure was reduced. I also considered moving the frontend itself from Vercel to Cloudflare Workers. However, because there was not enough time for the migration and because Vercel, as the developer of Next.js, seemed likely to provide the fastest patches and responses if a Next.js vulnerability was discovered, I decided not to move it this time. During that evaluation, CVE-2025-29927 was discovered. Fortunately, Next.js projects hosted on Vercel or Cloudflare Workers were not affected, but that will not necessarily be true for future vulnerabilities.
PENGUIN stores information about Kyoto University students and handles data about student groups. It is very important to do as much as possible before launch. I will not say it was perfect, but based on the previous year's lessons, I think we did what we could before operation.
On the implementation side, I also found code in another team member's area that could have led to XSS. We caught it before launch and prevented it.
What Was Difficult
The biggest problem was workload. Because I did not accurately understand members' abilities, the pace became too slow to meet the deadline. As a result, there were many times when I had to take over work to finish on time. More than technical difficulty, this was work where management difficulty stood out.
I also encountered situations where I was too buried in my own tasks to assign work to other team members. I felt keenly how difficult it is to keep a high-level view: which members can handle what, which features should be implemented early, and which features should be passed to juniors as practice.
As mentioned above, I led development from April of my second year. After the new-student recruiting season, the site was released in May, and then we kept building features until the festival in November. Leading under that tight schedule was not easy.
After Building It
In this development, building the product itself was much easier than finishing it on time as a team. Requirements, ownership, reviews, security, and production operation all had to happen under a short schedule. I had underestimated it as a student activity, but that was a major mistake.
Even so, being able to work as the leader of an important department supporting the success of the November Festival was valuable experience. Including the parts that did not go well, I learned what matters in team development.
Link
student.nf.la (this is the current website and is not exactly the same as what I developed.)