UNISERVE

Community extension is not just an outreach activity. It is an institutional function that depends on coordination, evidence, and accountability. At NU Dasmariñas, this work involves academic departments, coordinators, approvers, directors, students, volunteers, and quality assurance roles, each contributing to a different part of the extension process.

That made me see community extension as a complete workflow, not just a list of events or uploaded documents. A proposal needs to be prepared, reviewed, approved, implemented, monitored, supported with evidence, and reported properly. Volunteer participation also needs to be tracked and validated so the institution can clearly show what was done and who contributed to the work.

This is the context where UNISERVE was designed. The goal was not to create another storage tool, but to build a system that reflects how community extension work actually moves inside the university. It needed to support the full lifecycle of extension work, from planning and approval to implementation, evidence management, volunteer engagement, monitoring, and institutional reporting.

When I started looking closely at how community extension work was being handled, I realized that the problem was not the lack of effort. The office was already managing meaningful work: proposals were being prepared, partners were being coordinated, volunteers were joining activities, and documentation was being collected. But behind those activities, the process still depended heavily on manual work and separate spreadsheets.

What stood out to me was that ComEx did not have an integrated digital platform that connected the whole process. Records, approvals, monitoring details, evidence, and volunteer participation could be handled in different places, making the work harder to trace from planning to reporting. It became clear that the issue was not just about organizing files, but about giving the office a structured system that could support how community extension actually moves.

Because of that, I told my group that we should choose the Community Extension Office as our client for our capstone project. We saw a real operational problem that a system could solve. That observation became the starting point for UNISERVE: a platform designed to help ComEx move from scattered manual processes into a more organized, traceable, and integrated digital workflow.

After identifying that ComEx did not just need another place to upload files, I approached UNISERVE as a workflow system. The goal was to design a platform that could follow the actual lifecycle of community extension work, from proposal creation and approval to implementation, monitoring, evidence collection, volunteer participation, and reporting.

UNISERVE became a unified platform where different users can work based on their roles. Faculty members and ASP can submit and manage proposals, approvers can review activities through a structured approval flow, ComEx can monitor records and reports, and student volunteers can access opportunities through the mobile app. Instead of separating internal management and volunteer engagement, the system connects both sides through one shared backend.

What makes the solution meaningful is that it turns scattered manual work into something more visible and accountable. Records are no longer treated as disconnected files, and approvals are no longer hidden across messages or spreadsheets. Every proposal, document, participant, and report can become part of a connected process that helps ComEx manage extension work with better traceability, consistency, and institutional clarity.

As the lead developer and primary implementer in our three-member capstone team, I took responsibility for the technical direction of UNISERVE. My role was to turn the operational problem we observed at ComEx into a working system structure, making sure the platform was not just a collection of screens, but a connected workflow that matched how community extension work actually happens.

I handled most of the system's core implementation, including the web and mobile applications, backend integration, database structure, interface development, role-based access, and workflow modules. This included building the parts that support proposal management, approval routing, records handling, user roles, reporting, and the connection between internal ComEx operations and student volunteer engagement.

Aside from development, I also worked heavily on the capstone manuscript and documentation. I helped shape the system's technical explanation, project context, requirements, diagrams, and overall narrative so the written output aligned with the actual system we were building. My main contribution was not only coding the platform, but making sure UNISERVE was presented clearly as one integrated solution for community extension management.

I designed UNISERVE around the actual lifecycle of community extension work, not just around basic create, read, update, and delete screens. The workflow begins when a faculty member or ASP creates a proposal and submits the required details, documents, and supporting information. From that point, the proposal becomes a traceable record that can move through the system instead of staying scattered across forms, emails, and spreadsheets.

The proposal approval route proceeds through the ComEx Representative, Program Chair, Dean, QMO, ComEx Coordinator, and ComEx Director before final approval by the Assistant Director for Academics. Reviewers can give feedback, return the package for revision, or move it forward to the next stage. The system keeps the proposal status visible, so users can see who needs to act next and where the work stands in the approval process.

After approval, the proposal becomes part of the implementation flow. Activities can be connected to student volunteers, participation can be tracked, service hours can be validated, and evidence can be attached to the proper engagement record. This makes the work easier to monitor and report because the proposal, approval history, documents, volunteer records, evidence, and reports are connected in one workflow.

UNISERVE was designed with one shared backend that supports two connected product experiences: the institutional web platform and the mobile volunteer app. The web platform handles process-heavy work such as proposal management, approval routing, records, dashboards, reports, and administrative workflows. The mobile app focuses on the student volunteer side, making it easier for users to access activities, track participation, and stay connected to community extension opportunities.

At the center of the architecture is Supabase, which connects authentication, PostgreSQL data storage, row-level security, backend services, and file storage into one managed layer. This allowed the system to keep proposals, users, roles, evidence, volunteer records, and reports in a centralized structure instead of splitting them across separate tools. Both the Next.js web platform and the Flutter mobile app communicate with the same backend, so the data remains consistent across internal users and student volunteers.

The architecture follows the way UNISERVE works as a product: users enter through different interfaces, but their actions connect to the same role-aware workflow. Faculty, ASP, Program Chairs, Deans, QMO, ComEx Coordinators, ComEx Directors, students, the Assistant Director for Academics, and administrators can only access the functions and records that match their responsibilities. This makes the system more than a front-end interface; it becomes a protected, centralized, and workflow-driven platform for managing community extension work from proposal to reporting.

UNISERVE was developed and evaluated as our final-year capstone project at NU Dasmariñas. The completed web and mobile platform connects community extension workflows, volunteer participation, and institutional reporting.

The platform is deployed for demonstration and evaluation.

The defense panel recommended AI integration as future work. It remains a planned enhancement beyond the version evaluated in the study, alongside continued refinement informed by user feedback.

The web application received an overall weighted mean of 4.88/5, interpreted as Excellent, from 190 university employees and 10 IT experts. The evaluation used selected adapted ISO/IEC 25010:2023 criteria: functional suitability, compatibility, interaction capability, reliability, and security.

The mobile application received an overall weighted mean of 3.88/4, interpreted as Highly Acceptable, from 43 active student volunteers and the same 10 IT experts. This evaluation used an adapted four-point Mobile Application Rating Scale (MARS), covering engagement, functionality, aesthetics, information quality, and subjective quality.

All documented functional checks passed across 30 web modules and 11 mobile modules, each assessed by three testers. These results describe the tested functions and respondents' assessments within the study. Further piloting is needed to measure sustained use and longer-term operational improvements.

The most challenging part of UNISERVE was not only the development work itself, but learning how to manage the project as a team under real deadlines. Building the system required more than coding features; it required coordination, task ownership, documentation, revisions, and constant alignment between what we planned, what we could finish, and what the capstone required.

As the lead developer, I had to balance technical implementation with group collaboration. There were moments where I needed to adjust timelines, help connect different parts of the work, and make sure the system, manuscript, and presentation were moving in the same direction. It taught me that a working product depends not only on individual skill, but also on communication, responsibility, and the ability to keep the team focused despite pressure.

UNISERVE helped me understand what it means to build in a real project environment. The experience pushed me to think beyond screens and features, and to take responsibility for the workflow, the documentation, and the people involved in delivering the system.