A volunteer’s contribution is more than a registration form. I’m working with a five-person team to rebuild VMIS for the Bhutan Youth Development Fund, connecting the Y-VIA volunteer journey from joining an event to having that participation verified, recorded, and recognised.
- Client & programme
- Bhutan Youth Development Fund · Y-VIA
- My role
- Team lead, full-stack development & AI
- Collaboration
- Five-person capstone team
- Project status
- In development
The problem
Registration was only the beginning.
Young Volunteers in Action (Y-VIA) connects young people with community service, leadership, and development opportunities across Bhutan. Supporting that work involves more than knowing who has registered: coordinators also need to know who took part, what they contributed, and how that experience builds over time.
The rebuild extends the volunteer experience beyond registration towards connected activity records, attendance, service hours, achievements, and reporting. Coordinators and programme staff need a consistent view of participation to support that journey.
A connected participation record can help volunteers follow their development and give coordinators useful programme information. Registration, events, attendance, and recognition therefore form parts of the same product direction.
My contribution
Keeping the team and the product connected.
My role combines team leadership with hands-on full-stack development and an AI-assistance direction. As Scrum Master and project coordinator, I support sprint planning, progress reviews, task coordination, and communication with the client and supervisor.
I help track dependencies, resolve blockers, and keep development aligned with the agreed scope. My technical work spans frontend and backend features, APIs, data management, role-based functionality, and the application workflows that connect them.
This is collaborative work. Our five-person team shares requirements analysis, implementation, review, testing, and documentation, with dedicated leads for business analysis, interface design, backend development, and quality assurance. My responsibility is to help those contributions come together as a coherent product.
Product direction
One platform, different responsibilities.
The proposed experience follows Y-VIA’s operating structure. A volunteer needs a clear route into activities and a trustworthy record of their contribution. A coordinator needs practical tools for managing participation. YDF needs oversight across the programme. Those needs call for different views of the same connected information.
- Volunteers
- Discover and join activities, record attendance, and follow their service history, skills, achievements, and recognition through a personal portfolio.
- School and cluster coordinators
- Manage local volunteers and events, verify participation and submitted evidence, and prepare event reports within their assigned scope.
- Dzongkhag coordinators
- Coordinate activities across their district, submit district-level event proposals, and review programme information and local reports.
- YDF administrators
- Oversee programme records, roles, event approvals, recognition rules, resources, and national reporting.
The core workflow
From an event to a verified contribution.
The event lifecycle is the thread connecting the platform. Signing up for an event should not, by itself, become proof of service. The proposed workflow keeps registration, attendance, verification, and credited participation as distinct stages.
School-level and district-level events also follow different governance paths. District-level proposals go to YDF for approval and can return to the coordinator for revision before publication. After publication, both paths connect to the same participation and verification process.
Plan and publish
A coordinator defines the event, capacity, deadlines, and allocated hours. District-level proposals pass through YDF’s review before they can be published.
Register and manage places
Registration checks cover existing sign-ups, availability, and deadlines. Permitted withdrawals free a place for another volunteer.
Capture attendance
Event-specific QR attendance, with authorised manual recording where required, provides evidence of who actually participated.
Verify participation
The responsible coordinator reviews attendance before the event is completed and participation is treated as verified.
Build the volunteer record
Verified participation connects to service hours and portfolio history, supporting programme-defined milestones and recognition.
Report and review
Event reports give coordinators and YDF a shared basis for reviewing activities and monitoring the programme.
Design decisions
Make the records useful by making them trustworthy.
The portfolio is intended to tell a volunteer’s Y-VIA story through service history, skills, achievements, leadership, certificates, and recognition. That makes the quality of the underlying records a product concern, not just a database concern.
For submitted skills and achievements, the proposed process includes supporting evidence, coordinator review, and feedback when a submission needs revision. The goal is a record that is meaningful when a volunteer shares their experience for future opportunities.
Access also needs to follow responsibility. The design limits programme and personal information to the people authorised to use it, with audit trails for important administrative changes. This matters particularly because the platform holds information about young volunteers.
The experience is being designed for phones as well as larger screens. It is a responsive web application, with an active connection required for online attendance and programme workflows. The current scope does not assume an offline attendance queue or a separate native mobile app.
Technical approach
Separate the experience, the rules, and the records.
We are structuring VMIS around three tiers: a responsive presentation layer, an application layer for programme rules and workflows, and a data layer for connected records. This keeps interface changes separate from decisions about permissions, verification, event participation, and service hours.
The application uses Next.js and TypeScript for the interface, with FastAPI and PostgreSQL supporting programme workflows and connected records. Development focuses on a clear experience, maintainable business rules, and consistent information across the volunteer journey.
Keeping relationships consistent across volunteers, events, attendance, hours, and portfolios is central to this approach. Recognition and reporting should draw on those verified records, rather than create separate versions of the same contribution.
Progress & next steps
A defined direction, with implementation continuing.
The current project work establishes the problem, stakeholder needs, functional requirements, user stories, role-specific interface designs, workflow diagrams, and proposed architecture. Implementation is continuing through iterative sprints, with stakeholder feedback helping refine priorities.
The next milestones are to connect and validate the core journeys end to end: registration, event participation, attendance verification, credited service hours, portfolios, and reporting. Permission checks, responsive access, integration testing, and user acceptance are part of that validation work.
Delivery planning continues with client feedback. AI assistance is a development direction, while the core work remains focused on the documented volunteer-management workflows.
The intended outcome is a platform that helps coordinators manage participation and gives volunteers a credible record of their development. The focus for this phase is getting those core records and workflows validated with stakeholders.