Parade Wisuda: Graduation Platform

Parade Wisuda ITB 2023 became my first leadership role in an IT division. A friend recommended me for Head of IT, and I decided to take the opportunity even though I had never led a technical team or operated a public product before.

At the time, the role felt like almost everything at once. I assigned work, integrated features, improved quality, fixed bugs, handled deployment, and responded whenever users or other committee members encountered problems. Looking back, part of the job was engineering leadership and part of it was customer care.

At our first meeting, I asked each person which feature they wanted to learn or build. We organized the team around those interests so everyone could contribute to a part of the website they found meaningful.

Because I was worried that we would not finish, I divided the product into many small pieces across roughly 20 developers. Everyone was capable, and the work eventually came together, but I learned that a larger team does not automatically produce a larger result. In hindsight, a focused team of eight to ten people probably could have built it with less coordination overhead.

The platform needed to represent more than a thousand graduates without allowing the same people to dominate the first page. We used seeded random ordering so each visitor received a fair but stable page sequence.

Graduate rosters arrived through CSV files from many student associations and were imported into the application database. Reconciling them was difficult because leaving someone out was not merely a technical mistake. It could become a sensitive organizational and political problem during an event intended to celebrate everyone.

Wisokfess came from a team discussion about giving visitors a playful way to leave messages for graduates. It became my favorite feature and received more than 5,000 submissions.

Many graduates thanked us for building it. That response made the feature feel larger than an anonymous message wall. It gave friends, juniors, and other visitors a simple place to leave congratulations and personal memories that each graduate could collect.

We initially considered the website harmless. It handled no payments and existed for a fun university celebration, so we did not imagine that anyone would seriously attack or abuse it.

Then one individual began using Wisokfess to target other graduates and attempted to overwhelm the website. The site went down several times. We responded with message filtering, deletion tools, blocking rules, and rate limiting, learning those production defenses while the incident was already happening.

It was a wake-up call: the internet does not respect the tone a product was intended to have. Once real people can interact with a system, abuse and unexpected behavior become part of the engineering problem.

TA Fair allowed graduates to opt in through a form and share their thesis, adviser, abstract, and personal experience. It showed visitors what graduates had worked on while giving juniors a way to discover research interests, potential advisers, and networking opportunities.

Participation was intentionally optional. The goal was not to expose every thesis by default, but to give graduates who wanted to share their work a structured place to do it.

The final launch period was chaotic. I was integrating work from many contributors, fixing authentication, images, data, comments, type errors, and deployment issues while traffic was approaching. We used Vercel Pro alongside DigitalOcean to handle the production workload.

I had no mental model for production readiness yet. I did not know which failures to anticipate, how much protection a public application needed, or how strange deployment behavior could become under real traffic. If I rebuilt it today, I would rethink nearly every part of security, privacy, observability, deployment, and incident response before launch instead of learning them reactively.

By the actual parade day, our attention had shifted from the website to livestreaming the event. The platform had already done its main job of introducing graduates, collecting messages, and supporting the lead-up to the celebration.

That transition reminded me that software was only one part of a larger event. The website mattered because it supported real people and a real occasion, not because it needed to remain the center of attention forever.

It felt good when all the separate pieces finally became one product, but the experience changed how I think about team size. More people create more capacity, but they also create more interfaces, dependencies, and integration work.

My first leadership role taught me to choose a team size intentionally, give people meaningful ownership, and prepare for the human behavior a product may attract. The technical system and the team building it both need clear boundaries to work well.