I am thrilled to share that I recently won First Place in the Build4Students Hackathon (2026)! With 708 participants and a panel of judges from companies like Meta, Anthropic, and Capital One, the competition was real.
The challenge was simple but broad. Build tools to make student life better. My solution was WeRelaySyllabus, a platform to crowdsource the calendar for every course syllabus.
🔗 Try it out here | 🐙 GitHub Repo | 🚀 Devpost page | ▶️ YouTube demo
The Problem
Every semester, thousands of students receive a PDF or a printed booklet containing their exam dates and assignment deadlines. Then, we all spend hours individually and manually typing those dates into Google Calendar or Notion.
It’s a massive, collective waste of time. I wanted to create a way where one student helps, and the whole course benefits.
The Solution - WeRelaySyllabus
If you're a new student, it’s simple! Get on the website, find your course, and export the calendar in the industry-standard ICS format. That’s it. One click to import into your favorite calendar software, and you're done. No sign-up, no fluff.
If the course isn't there yet? Everyone gets together to fill it out for the benefit of the whole class. A quick "event name," "description," and "time", boom. Everyone gets the memo.
The vouch system also makes sure calendars remain trustworthy by getting a community consensus on whether the events registered are legit.
If you'd like to learn more about the project itself, you can check it out on the Devpost Page, but this blog post will be more of a devlog going over how I built this project.
Jan 20 - Switching from AWS to Firebase
So I'm 3x AWS certified, but I used Firebase to make this project? Sounds weird, but I think it was actually a good decision. I was originally planning to use Lambda, API Gateway and DynamoDB - like I previously have done many times. But I realised with the Vouch logic, I would need WebSockets. In case you aren't aware, a WebSocket is a feature in API Gateway (and APIs in general) that allows changes to be propagated in real time to users currently listening. And well, WebSockets are expensive, and I hadn't even used them before.
But I noticed that the thing I wanted sounded very similar to another thing I already knew. Users listening, realtime changes? That's right - Firebase Firestore.
I picked Firebase because it's free, it's extremely easy to set up with a web app, and it had exactly what I wanted without any hassle of having to pay or work out optimisations. It just worked.
Jan 28 - UI Styles
So I began the project on January 20 leisurely. By now I had only made decisions about what the project was going to be, and that the backend would be Firebase over AWS.
I had put in a basic system that counted vouches and showed a simple list of calendars, nothing too complex yet. I just wanted to make sure the Firebase integration was locked in before the project got complex and it would be a hassle to integrate later.
But I realised that, well, the UI was quite boring. It was just a plain "modern" style that I knew how to do well, but who doesn't? It's incredibly easy to pull off, and Next.js feels like it was practically designed for it.
So obviously, I had to think of a design style for WeRelaySyllabus. After some looking around, I found this site called Gumroad. I heard about it before - it was a freelancing site. What stuck with me is that it looked fluid, just like the "modern" style. It looked easy to use and modern, but it also looked unique. Everything had bold, completely black shadows and barely anything used rounded corners. After some more research, I found out this style was called neo-brutalism.
I had actually studied a bit about architecture at school, specifically styles such as modernism, neoclassical, art deco, and brutalism. So naturally, I took neo-brutalism to be the newer mix of modernim and the bold brutalism, but for UI.
And that's what I ended up using as WeRelaySyllabus's design language.
Feb 10 - ICS Generation
By Feb 10, I had finished what was my Unique Selling Point for WeRelaySyllabus - the fact that you can just hit download, get a univerally standard calendar file and import it into literally any calendar software you could think of.
It starts by initializing the string with BEGIN:VCALENDAR and defining the version and product ID (which is WeRelaySyllabus). Then, for every event in the events array, I concatenate a BEGIN:VEVENT block containing necessary details like SUMMARY (title), DTSTART (start time), and LOCATION. Finally, the string is closed with END:VCALENDAR and converted into a Blob with the text/calendar MIME type, allowing the browser to trigger a download.
But in testing (I actually discovered this while I was filming the demo video!) I found out that many calendars just outright reject the calendar file. And of course, it would just say "Please try again later" without actually telling me what was wrong...
I figured out that in some events, because the end date is optional, they just have a missing end date. I thought that was ok, but it turns out that Google Calendar becomes a bit cranky without it. My fix? I updated the logic to guarantee a DTEND. I now calculate endTime by checking if ev.end exists; if not, I dynamically generate one by adding one hour to the start time.
The Final Crunch - Bugfixing
If you go to my commit history of 16 commits, beginning on Jan 20 and ending (so far) on Feb 14 which was a day before the deadline, you'll notice more than half the commits are on or after Feb 10.
So here's just a quickfire runthrough of some of the commits and what they fixed...
Fix days bug - Feb 10
Because of differences in Daylight Savings, clicking on a day in the calendar after March 29 (which is Daylight Savings in the UK) would show the wrong date to edit, being offsetted by a day.
The fix was to switch from basic string concatenation to actually using a Date object to calculate the date based on the locale.
Fix calendar generation error - Feb 10
This was the calendar end date generation I discussed above.
Fix long calendar title issue - Feb 11
On smaller devices, the title wouldn't truncate so it'd just overflow to the next line and cut the calendar's space in half. I fixed this by just... allowing the title to truncate I guess
Swap course id for code - Feb 11
Pretty self-explanatory, but I found that using the auto-generated course ID instead of the actual course code wasn't very helpful especially as you could just see it in the URL if you really needed it.
Fix stylings and forms on WebKit - Feb 11
This was an interesting one. On my phone and my Mac, the forms and a lot of the icons had a weird grey tint to them.
I fixed this by forcing the icons to be white on WebKit based browsers. It's more of a bandaid fix but it was perfect for the hackathon, and it'd only be an issue if I implement dark mode, which I could also just fix by making it the opposite colour if dark mode is enabled.
Make date editable on mobile - Feb 13
In testing I noticed that on mobile you could only add events to dates already existing in the calendar.
I fixed this by just adding a small mobile-only button to change the date selected right in the events popup itself.
Add descriptive auth errors - Feb 14
If Firebase errored out on authentication, it used to just say that something went wrong.
I fixed this by just checking was the error was, comparing it against the docs and then showing a more helpful error.
Filming the Demo Video
I knew from the beginning that I wanted my demo video to have two main parts: a scripted, fluid demo video that showed all the features quickly and without mistakes. Then I also wanted a more off-the-cuff demo going through the project and showing all the features one by one in a more comprehensive way. So that's what I did. I wrote the script, grabbed some B Roll from Pexels and recorded me just going through the website, and then I stitched it all together in Davinci Resolve.
And then I just recorded the off-the-cuff demo. No preparation apart from just having a rough idea of what I needed to go through.
Next Steps
The project isn't 100% done. In fact in my Devpost README I called it an MVP - because this is what it is. I made it quickly specifically to meet the deadline for the hackathon. It has the necessary features to improve student life measurably, but I could do more to fully flesh out WeRelaySyllabus. Here's what I'd do:
A Live ICS feature. This is generally the standard when it comes to calendar syncing, but I felt that an export was better just because of the nature of how fast calendars change. Plus, server caching would mean that it'd take ages for the calendar to actually update. But still, this would remove that subtle final friction - that click on the Export button.
Maybe OCR recognition for uploading syllabi directly? While I couldn't have achieved that with Firebase, doing it is very much possible with other major cloud providers like AWS via Textract. It would definitely be a very very interesting addition!
For now though, thank you so much for reading. I hope you learned something interesting!
Written by Hamd Waseem (14)
Top comments (0)