cuHacking, 2024 to 2026: the portal, the monorepo and the docs

I was a full stack developer for cuHacking, the Ottawa hackathon, from September 2024 to April 2026. Three pieces of work stand out: the event portal, the monorepo, and the docs.

The event portal

The portal is what attendees use during the event. It covers 400+ people, and it is built with React, TypeScript and Payload CMS. The brief was simple to state and hard to do: stay stable while hundreds of people use it at the same time, during a live event, with no room for a second try.

The thing I took from that is that a live event has a hard deadline that nothing else on a student team has. A bug in a class project costs you marks. A bug at an event costs you a room full of people waiting. I kept the portal modular, with small React components that could be tested on their own, so a problem in one part did not take the rest down with it.

The monorepo and Storybook

cuHacking had several things that looked like separate projects: the website, the portal, the docs, and the Figma design scope. They shared components and conventions, but they lived apart, which meant the same button got rebuilt and retested more than once.

I set up an Nx monorepo that brings the docs, website, portal and Figma scopes into one place. It made ownership and build order explicit: what depends on what, and what has to build first.

I also led the adoption of Storybook for the shared UI components. The point was to build and review a component once, in isolation, and use it everywhere. That removed the duplicate testing and the per-platform variants that had crept in across the site.

A monorepo is not automatically better. It pays off when the pieces really share code, and it costs you in tooling and build configuration. For a project with several surfaces and changing contributors, I think the clarity was worth it.

Event day, from the organizer side.

The contributor docs

The docs site is the piece I'm most glad exists. I wrote and maintained the contributor docs, and they helped onboard five or more open-source contributors.

Volunteer teams change over time. The knowledge leaves with people unless it is written down. Good docs mean a new contributor can clone the repo, run the project and open a pull request without asking someone for a walkthrough. I treated the docs as part of the product, not a chore after it.

What I would tell the next developer

• Write the contributor guide first. It forces you to find out how hard the setup really is.
• Share components early. Divergence is cheap to prevent and expensive to remove.
• Test the portal under the worst realistic case, not the average one.

Separately, my robot project BOOPBOT, funded by a development grant from BlackBerry QNX, is being built for cuHacking 7. You can read more on the BOOPBOT project page.