As a SpartaHack Co-Director, I work across Tech, Marketing, and Logistics. Building the platform put those responsibilities in the same place: the website had to give students a reason to attend, help them apply, and support the organizers preparing the event.

I built the public site and the participant and organizer workspaces around that full journey. The flagship hackathon was the starting point, but the organization also needed a home for events throughout the year.

Give people a reason to explore

The public site uses a pixel-art identity, hidden discoveries, and achievements. I wanted the website to feel connected to the experience of SpartaHack, with things to find before someone ever reaches an application form.

That exploration carries into the signed-in experience through achievements and a coin wallet. The participant dashboard then brings together the more practical parts: an application, RSVP, event information, announcements, and a QR credential for check-in. The playful layer and the operational layer belong to the same experience.

Follow the participant all the way through

An application is the beginning of a longer relationship with the event. Applicants need to save progress, review what they have entered, and return without losing edits. Later, participants need teams, project submissions, schedules, and a straightforward way to check in.

Working on that journey exposed assumptions that looked reasonable in code but failed for real people. A .edu-only signup rule excluded legitimate students at schools using other domains. I expanded the school-domain approach and reviewed exceptions against official school information. Similarly, normalizing profile links and explaining invalid fields made the form more forgiving without changing its requirements.

Those details mattered because a student should be concentrating on their application, not figuring out which format a field silently expects. Saved drafts, clear errors, and a complete review step became part of the core experience.

Build the organizer’s side of the same event

Behind the public site, the team needs application review, announcements, schedules, check-in, judging, and staff administration. I structured access around the departments actually doing that work, including Operations, Tech, Logistics, Marketing, and Finance. That lets people work in their area without giving everyone complete administrative control.

Communication had to connect those workspaces to the channels people use. Organizers can prepare announcements for the public, event attendees, or staff, with web, email, and Discord delivery. The audience and the difference between saving a draft and publishing need to be obvious before an organizer acts.

Event-day tools have their own rhythm. Check-in should handle a line of attendees without restarting the camera after each scan. Reward transactions should identify the attendee and make the intended action explicit. I designed these flows around the person operating them as well as the person arriving.

One organization, more than one event

Hacktoberfest made the broader platform need concrete. It needed its own campaign page and event operations while still belonging to SpartaHack. I kept accounts, achievements, and the wallet global, with applications, projects, check-in, and permissions tied to each event.

That allows the flagship to keep its identity at the main site while other events have their own entry points. A person can have an account without automatically being enrolled everywhere, and organizers can work within the event they are running.

The application uses Next.js and Convex, with Convex supporting realtime data and scheduled work. Keeping event scope in the backend means that the separation applies to operations as well as the screens people see.

Building for the team that comes next

The platform is live, and the public and organizer experience has extended beyond the flagship to Hacktoberfest. SpartaHack 12 is still ahead, so event-day rehearsal remains part of the work; a published website is one milestone in running the event.

I also maintain documentation for architecture, access, deployment, and operations. A student organization changes hands. The platform needs to be understandable to the next team, including how to recover when a provider fails or an event setting needs to change.

This project has put product development next to organizational responsibility. I can work on an application screen and then consider the same decision as someone responsible for the event. That connection is what makes the platform worth building.

Explore SpartaHack Platform

  • Next.js
  • TypeScript
  • Convex
  • Vercel
  • CI/CD