---
title: "CampusCare: Turning Hostel Maintenance Reports into Verifiable Repairs"
published: false
tags: mlhacks, devchallenge, hackathon, ai
This is a submission for the MLH x DEV Writing Challenge
What I Built
Imagine reporting a leaking tap in your hostel. You submit the complaint, but then what? Who will fix it? Has anyone been assigned? And how do you know the problem has actually been resolved?
That is the problem we wanted to address with CampusCare, a campus and hostel maintenance management web application.
The idea is simple: reporting an issue should be the beginning of a transparent process, not the end of the conversation.
Instead of treating every complaint as a disconnected form submission, CampusCare connects reporting, assignment, repair, and verification in one workflow.
How CampusCare works
1. Report a problem
Students can report maintenance issues, provide a description, add location details, and attach a photo. The student-facing reporting flow does not require a login.
2. Analyze and route the issue
The application includes an AI-assisted analysis workflow designed to structure the report, suggest a category and priority, and recommend the appropriate maintenance department. Issues involving potential safety risks can be flagged for human review.
3. Assign and repair
Maintenance staff can access work orders for their department, update progress, add repair notes, and upload after-repair photos. Administrators or wardens can oversee campus-wide issues and manage assignments.
4. Verify the result
CampusCare supports comparing before-and-after repair evidence. The verification workflow checks the assessment and applies application-level rules before allowing a student to confirm the repair. Unclear evidence or safety-critical cases can require human review.
The ticket lifecycle is designed around a clear progression:
Reported → Assigned → Fixed → Confirmed
Students can confirm a completed repair or reopen an issue when the problem remains unresolved.
What makes the project interesting?
I wanted CampusCare to be more than a complaint form with an AI feature attached to it.
A useful maintenance system needs to answer three questions:
- What is wrong?
- Who is responsible for fixing it?
- What evidence shows that the problem was addressed?
CampusCare brings those steps together. It also includes separate student, maintenance-staff, and administrator experiences, role-based access controls, an audit trail, and Progressive Web App support.
The PWA features include an installable app experience and an offline app shell. The current demo stores application state in memory, so it is a prototype rather than a production-ready system with persistent database storage.
Demo
Try the live application:
Live Demo: https://campuscare-62kn.onrender.com/
GitHub Repository: https://github.com/notNavgengineer/CampusCare-
CampusCare is deployed on Render, so you can explore the application without setting up the development environment locally.
Partner Technologies
AI-assisted maintenance analysis
A key part of CampusCare is the AI-assisted workflow for turning maintenance descriptions and photos into structured issue assessments.
The goal is not to let a model make every decision independently. Instead, the application validates structured outputs, uses defined workflow rules, and can route safety-critical or uncertain cases for human review.
The repair-verification workflow follows the same principle: an AI assessment can contribute observations, but application-level safety rules determine whether the ticket can move forward to student confirmation.
Model transparency matters: the current public repository configures Google's GenAI SDK with gemini-3.8-flash and includes a deterministic fallback when the model is unavailable. The repository's project description mentions Gemma 4, so the exact model used in the final deployed version should be verified before making a specific Gemma 4 implementation claim.
Render
We deployed CampusCare on Render to make the project accessible through a public URL.
Deployment made it easier to demonstrate the complete user experience instead of asking everyone to run the project locally. The repository also includes a Render Blueprint configuration to support deployment.
Hackathon Experience
Hackathons encourage us to move quickly from an idea to something people can actually try. But building a working application also means thinking about the less obvious parts: what happens after a report is submitted, how different users access the system, how repairs are verified, and what should happen when an AI result is uncertain.
CampusCare gave us a practical way to explore those questions.
One lesson I am taking away is that adding AI is not enough by itself. The surrounding workflow matters just as much. A useful system needs clear responsibilities, predictable state transitions, validation, and a way to handle uncertainty instead of pretending every result is correct.
I also learned to think beyond the local development environment. Making a project accessible online changes how we can demonstrate it, gather feedback, and identify what still needs improvement.
CampusCare is a starting point, not a finished production system. There is still room to improve persistent storage, reliability, and the AI integration. But building it helped turn an everyday campus problem into a concrete engineering project.
I hope this project encourages more developers to look at ordinary problems around them and explore how thoughtful software and AI-assisted workflows can help solve them.
Thanks to the MLH and DEV communities for giving builders a place to share what they create and learn from one another.
Top comments (0)