A volunteer management system on a zero budget

The situation

FutureGeneration, a youth-development nonprofit in Ioannina, coordinates 310 volunteers. Coordination at that scale run on memory and spreadsheets fails quietly: nobody can say who is active, what tasks are open, or what has been dropped, until something visible breaks. The people running the organisation are organisers, not engineers — and they needed operations to be visible, not heroic.

The constraints

• Zero budget. No licences, no paid services with meaningful bills. Infrastructure choices were made by what costs nothing or nearly nothing to run.
• Non-technical operators. Every workflow had to be usable by organisers without training sessions or an engineer on call. If a screen needed explaining, the screen was wrong.
• Real operations from day one. The organisation didn't pause while the system was built. It had to slot into live volunteer onboarding and task management, not replace it in one cutover.
• Personal data of young people. The volunteer base skews young. Access was scoped conservatively from the start — the system shows people only what their role needs.
• Spare-time build. Nights-and-weekends attention, with an operating nonprofit depending on the result.

What I built

A Laravel + Vue web application, in production, covering the operational core:

• a volunteer roster — role, status, commitment, skills, and current workload per person
• task management with explicit states, so open, in-progress, done, and overdue are facts on a screen rather than impressions in someone's head
• team-level summaries for planning: who is available, where the load sits, what is slipping

Boring technology, chosen on purpose: a conventional Laravel + Vue stack is cheap to host, easy to keep healthy in spare hours, and — the part that matters for a nonprofit — possible for a future volunteer engineer to pick up without me.

The system has since grown a second interface: a read-only MCP server, so AI agents can answer questions about roster and task state the same governed way I build agent access to internal systems elsewhere.

Time to first value

First useful output within the first sprint. It went into production long before it was complete, running one slice of the operation while the rest stayed wherever it already lived, and earned its place workflow by workflow.

What changed

Volunteer operations run through the system: onboarding, task assignment, follow-up. Organisers see the state of the organisation instead of reconstructing it — overdue work is visible instead of remembered, and "who can take this?" is a lookup instead of a group chat thread.

Nothing here was formally instrumented, and I won't dress that up. The behavioural evidence is that a zero-budget system, operated by non-technical staff, has stayed the way the organisation actually runs — with 310 volunteers flowing through it.

What I'd do differently

I built the admin screens the way an engineer thinks — entities and relations — and watched organisers translate in their heads to how they think: people and weeks. The redesigns that followed real usage were the most valuable UI work on the project, and I'd start there now: sit an operator in front of every screen before it ships, not after.

And I'd design for handover earlier. For too long I was the only person who could administer the system safely — an acceptable risk for a side project, a real one for an organisation that depends on it. Making myself unnecessary took deliberate work that should have started at the first release, not after it.