Community Connect

Overview

I built Community Connect as a volunteer operations desk, not a social network. Admins, organisations, and volunteers share one PHP/MySQL app: identity, projects, membership, approvals, and reporting. Guests can suggest work; nothing goes live until an admin reviews it.

The stack was a constraint on purpose — HTML, CSS, JavaScript, PHP, and MySQL with no JS or PHP frameworks — so a campus club or NGO can host it on cheap shared PHP. Source: github.com/induwarauthsara/community-connect.

Problem

Volunteer programmes stall when sign-ups live in a form, assignments live in a chat, and approvals live in someone’s inbox. Organisations cannot see who is free. Volunteers cannot see what they are allowed to join. Admins cannot report on either. I wanted those loops in one MVC-style PHP application with explicit roles instead of a single users table and a boolean.

What I built

I implemented four surfaces: admin (users, projects, reports, guest-project approval), organisation dashboards (create and run initiatives), volunteer dashboards (profile, browse, self-assign with filters), and a public browse/suggest path for guests.

Business rules are coded, not documented as hopes: volunteers must be signed in to join; each volunteer belongs to at most one organisation; one signup per person per project; guests cannot publish without admin approval; volunteers edit only their own profile. Writes go through confirmation prompts and validation (email, dates, required fields). Persistence uses Users, Organizations, Projects, and Volunteer_Project_Assignments.

Impact

The result is a complete volunteer-ops product that can run on shared PHP hosting. Role separation is structural, not cosmetic. The same pattern fits campus clubs, NGOs, and community chapters that will never adopt a SaaS volunteer tool.

Key features

• Role-based access for admin, organisation, and volunteer
• Guest project suggestions with an admin review queue
• Project create / browse / join with capacity and status
• One-organisation membership rule and per-project signup uniqueness
• Volunteer profiles and assignment filters
• Admin reporting over people, orgs, and projects
• Confirmation dialogs and server-side validation on mutations

Technologies

PHP and MySQL (MySQLi, procedural) on the server. HTML, CSS, and JavaScript on the client. No React, no Laravel — by design.

My role

Solo full-stack build: data model, role matrix, approval flow, UI, and the public repository.