Growing SFU Surge’s StormHacks by 300% in a year with a hackathon management portal
Role
Founding Product Designer
Product Design Team Lead
Timeline
August 2024–May 2025
(8 months)
Team
3 UX Designers
1 UX Research Lead
4 Software Engineers
Skills
Product Strategy
User Interface Design
Design Systems
Overview
TL;DR: I founded the product design team at SFU Surge and shipped a portal that scaled StormHacks from 300 → 1,200 participants in < 1 year, making it the largest hackathon in Western Canada.
I've competed in 30+ hackathons. They're scrappy, chaotic, and one of my favorite ways to build, but they're often poorly organized. I joined SFU Surge wanting to improve the experience for participants.
In less than 4 months, I grew the Technology team from 3 → 8 (4 designers & 4 developers), ran user interviews, defined the product strategy, and shipped the MVP of the Surge portal.
RESEARCH
My team and I surveyed 14 organizers and 35 past StormHacks participants, then ran in-depth interviews with 6 organizers and 6 hackers.
The pattern that kept surfacing was how much manual work organizers were performing which were time-consuming and error-prone. These errors had a direct downstream effect on the hacker experience.
CORE FINDING
Hackathon organizers perform a lot of manual work that's time-consuming & error-prone.
FEATURE #1
Built an applicant management system that reduced application review time by 62.5%.
PREVIOUS FLOW
Previously, hackers would submit applications through Google Forms, listing out their teammates.
Organizers would have to manually group applicants into their requested teams by rearranging rows in the spreadsheet.
Why was this a problem?
Not only was the previous process prone to error, it was also unsustainable as SFU Surge scaled.
This process of manually groupling applicants into teams would take 24 hours when we received 300 applicants. In recent years, we've seen the number of applicants grow to almost 2,000. Not only was the previous process prone to error, it was also unsustainable as SFU Surge scaled.
WHAT I SHIPPED
In the portal, hackers can create or join teams through a shareable link.
Hackers individually fill out and submit their applications...
Their applications are then automatically grouped with their teammates.
Organizers can review entire teams together instead of one applicant each time.
Why was this important?
This feature helped save organizers time and directly improved hacker attendance rates.
This mattered because 93% of hackers register with teammates in mind — manual grouping had been splitting or rejecting teammates by mistake, causing full teams to drop out. The fix saved organizers time and kept teams intact from registration through acceptance, improving attendance rates.
FEATURE #2
Shipped a QR code check-in system that reduced errors & sped check-in time by 3×.
PREVIOUS FLOW
Previously, when checking in to a hackathon on the day of the event, hackers would have to state their name
Volunteers would have to search for their name in a spreadsheet, and then manually mark the hacker’s attendance
Why was this a problem?
Check-in was time-consuming and prone to error.
This process of manually checking in hackers was time-consuming (often taking from 30 seconds up to a full minute per hacker) and prone to error, with volunteers sometimes accidentally checking in the wrong hacker by selecting the wrong row in the spreadsheet by mistake.
WHAT I SHIPPED
After being accepted into the hackathon, hackers would get a unique QR code when they RSVP.
On the day of the event, organizers scan this QR code.
Why was this important?
This feature improved check-in efficiency and resulted in more accurate attendance tracking.
- Check-in time was reduced from ~30 seconds → 10 seconds
- Significant reduction in errors, resulting in more accurate attendance tracking
- Shorter lines at check-in, improving hacker experience
FEATURE #3
Integrated Stripe into the portal, processing $3,000+ to date and saving the finance team from logging 300+ manual transactions.
Context
In 2024, SFU Surge announced their first (paid) design hackathon. But how would we handle payments?
The organizing team suggested cash or e-transfer, but both would've required our finance team to manually log every transaction to comply with student society rules.
My instinct was to collect payments directly through the portal, but I wasn't sure hackers would trust a student-built platform with their credit card details.
RESEARCH
I worked with our UX Research Lead to test our assumptions directly, interviewing 5 students who signed up for the design jam.
CORE FINDING
Hackers were comfortable paying digitally as long as they saw familiar, trusted logos.
What I shipped
After being accepted into the hackathon, hackers could pay registration fees through the SFU Surge portal.
OUTCOMES
After being accepted into the hackathon, hackers could pay registration fees through the SFU Surge portal.
Integrating Stripe meant pulling engineers off other features under a tight timeline, but I made this call because it centered around my design principle of prioritizing for organizer efficiency.
To date, we processed $3,000+ in payments across 300+ RSVPs without having to manually log a single transaction.
Results
Building the portal helped scale StormHacks, making it the largest hackathon in West Canada.
- 300 hackers → 1,200 hackers in less than a year
- 62.5% faster application review
- 3× faster check-in
- $3,000+ in payments processed
- 3 designers & 4 developrs on my team leveraged this work to land internships!
LEARNINGS
Use design principles to inform product decisions
Founding the design team and shipping this from 0 → 1 meant heavy ownership of the product direction. Having a North Star (prioritizing organizer efficiency) helped me make hard tradeoffs about where to invest limited engineering resources.
Trust your intuition, but don't skip user research
This project also taught me to trust intuition where it's backed by real familiarity with the space and a real understanding of the users you're problem-solving for. However, this doesn't mean that you should skip user research. When the stakes are too high, gather insights from your users.
THANKS FOR READING!