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 of 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 application, 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.

Once submitted, the proposal follows the proper review and approval path. Each approver can review the package, give feedback, return it for revision, or move it forward to the next stage. The system keeps the proposal status visible, so users can see what has been submitted, who needs to act next, and where the work currently 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, 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 has already been presented and defended for Capstone 1, marking the completion of its initial research, design, and development phase. At this stage, the project has moved beyond concept and prototype planning, with the core system already shaped around the actual workflow of the Community Extension Office.

The next focus is testing and validation. This phase is where the system will be checked more closely in terms of usability, workflow fit, reliability, and how well it supports the users involved in community extension work. The goal is to see whether the platform feels clear, practical, and aligned with the real process it was designed to improve.

From here, the project will continue to be refined based on feedback and evaluation results. The system is not only being tested as a technical output, but as a product that needs to work for faculty, ASP, ComEx personnel, approvers, students, and volunteers in an actual institutional setting.

UNISERVE is currently in the validation phase, so there are no final quantitative or qualitative results yet. At this stage, the current outcome is project readiness: the system has already been designed and developed around the ComEx workflow, and it is prepared for evaluation using ISO/IEC 25010:2023 for the web-based system and MARS for the mobile volunteer application. The next step is to gather user assessment data on software quality, usability, workflow fit, mobile app experience, and overall readiness for continued refinement.

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.