Campus safety shouldn't depend on who you know or how loud you can shout. At The Forge 2026 hackathon, my team Zeroday built CampusAlert — a platform that lets students flag safety issues and broken infrastructure in real time. Here's how we built it, what we learned, and why campus safety matters.
The problem is familiar to anyone who has spent time on a Nigerian university campus. A broken streetlight that never gets fixed. A security checkpoint that's always empty. A flooded walkway that students navigate every single day. The complaints are made — to hall wardens, to student government, to anyone who will listen — but nothing changes.
Not because people don't care. But because there's no system to capture, track, and escalate these issues systematically. Reports disappear into conversations. Problems persist until someone gets hurt or something breaks completely.
That's the problem we decided to solve at The Forge 2026 hackathon. We called it CampusAlert.
The Challenge — Why Campus Safety Hits Different
The Forge 2026 theme was around building solutions for campus life. When we brainstormed, campus safety kept coming up. Every single person on the team had a story — a near-miss at night, a broken facility that caused an injury, a security concern that was dismissed.
What struck us was how universal the problem was. This wasn't about one hall or one faculty. This was about the entire campus ecosystem. And the gap wasn't resources — universities have maintenance budgets, security teams, and administrative structures. The gap was visibility and accountability.
"The problem isn't that nobody cares. The problem is that nobody knows."
A broken light in Block B, Room 204 might be a minor annoyance to the student who lives there. But if you aggregate that data across the entire campus — if you could see that 40% of streetlights in a particular zone are non-functional — that's a pattern that demands action.
That's what CampusAlert does. It turns individual complaints into collective data.
What We Built
We had 48 hours. The scope had to be tight, but the impact had to be real. We focused on three core capabilities: reporting, tracking, and escalation.
-
📍
Geotagged Incident Reporting — students can report issues with precise location data, photos, and severity levels. The system automatically categorizes reports by type (safety, infrastructure, security, maintenance).
-
📊
Real-time Dashboard — administrators get a live view of all campus issues, filtered by severity, location, and category. Heat maps show problem zones. Trend analysis identifies recurring issues.
-
🔔
Automated Escalation — when a report reaches a certain severity threshold or age, the system automatically escalates to the appropriate department head with a full audit trail.
-
📱
Mobile-First Design — built for students who are on the move. Quick reporting flow. Offline mode for areas with poor connectivity. Push notifications for status updates.
-
👥
Anonymous Option — students can choose to report anonymously for sensitive safety concerns, protecting those who fear retaliation.
The Build — 48 Hours with Zeroday
This was our second hackathon as Zeroday. We had learned from Squad Hackathon 3.0 — we knew the value of starting with the core loop and building out from there. We also knew that sleep deprivation leads to bad architectural decisions.
Our stack was Django for the backend, React/Vite for the frontend, and PostgreSQL for the database. We chose this stack because we knew it — we could move fast without fighting the tools.
The first 12 hours were all about the data model. We spent serious time thinking about what an "issue" actually is in a campus context. It's not just a description and a photo. It's location, severity, category, status, reporter (optional), assigned department, resolution notes, timestamps, and audit trail.
Getting that data model right meant everything else flowed naturally. The reporting form just captured the model fields. The dashboard just visualized the aggregated data. The escalation logic just queried by status and age.
"A good data model is half the battle. The rest is just UI."
The Demo — Why Judges Responded
When we demoed CampusAlert, we didn't lead with the tech stack. We led with the story. We walked through a scenario: a student walking back to their hall at night notices a broken security light. They open CampusAlert, tap "Report," select the category, add a photo, and hit submit.
On the admin dashboard, that report appears instantly — geotagged on a map, categorized as "Security Infrastructure," marked as "High Severity." The security head gets a push notification. They assign it to the maintenance team. The student gets a status update when it's resolved.
That entire flow took 60 seconds to demonstrate. But it showed the complete story — problem, solution, impact.
What We Learned
We spent 12 hours on our data model and it paid off. Every feature after that was just manipulating that model in different ways. Rush this step and you'll spend the rest of the hackathon fighting your own architecture.
We initially debated whether to allow anonymous reports. Some team members worried about accountability. But we realized that for safety issues — harassment, assault, security threats — anonymity is what enables reporting at all. We built it in and it became one of our strongest features.
Adding location data to reports transformed them from isolated complaints into spatial patterns. We could show heat maps of problem zones. We could route reports to the nearest maintenance team. Location isn't just metadata — it's context.
Zeroday has now done two hackathons together. We know each other's strengths. We know how to communicate under pressure. We know when to push and when to compromise. That team dynamic is what makes the difference between a working prototype and a polished demo.
What's Next for CampusAlert
CampusAlert is currently live at campusalert-ten.vercel.app. We're in conversations with student government bodies at multiple universities about pilot deployments. The feedback from The Forge 2026 judges was clear — this solves a real problem and it solves it in a way that respects both student safety and administrative workflow.
We're planning to add predictive analytics — using historical data to identify emerging problem zones before they become critical. We're also exploring integration with existing campus management systems so that reports can flow directly into work order systems.
"Campus safety isn't about eliminating risk. It's about managing it intelligently with data, not ignoring it until something breaks."
If you're interested in deploying CampusAlert at your institution or contributing to the project, get in touch. Campus safety is a collective responsibility — and technology can help us share that burden more effectively.
Want to see CampusAlert in action?
Check out the live demo and see how we're making campuses safer, one report at a time.
View Live Demo View All Projects