VolCore Ops¶
VolCore Ops is a volunteer operations platform concept for scheduling, staffing, coordination, check-in, records, and event-day support.
It is designed around a simple reality: volunteer-driven organizations often run on spreadsheets, group chats, paper rosters, shared memory, and the heroic efforts of one or two people who somehow know where everything is. That works beautifully right up until it does not.
VolCore Ops is meant to turn that coordination work into structured, traceable, and supportable workflows.
Summary¶
VolCore Ops is a self-hosted volunteer operations system designed for a single organization. The project focuses on the operational side of volunteer management: onboarding, approvals, credentials, event staffing, shift assignments, waitlists, attendance, check-in, required forms, exports, and administrative oversight.
The goal is not to build a generic social platform or bloated enterprise portal. The goal is to support the actual work that happens before, during, and after an event.
That means answering questions like:
- Who is approved to volunteer?
- Who is available?
- Who is assigned?
- Who still needs required forms or credentials?
- Who checked in?
- Who checked out?
- Who no-showed?
- Who needs follow-up?
- What can be printed or exported when event-day chaos starts doing jazz hands?
Why I designed it¶
Volunteer coordination can get messy quickly.
A small event might survive with a spreadsheet and a group chat. A larger event usually needs more structure: role-aware access, shift planning, waitlists, check-in workflows, required forms, emergency contact access, participation history, and reliable reporting.
The problem is not just storing volunteers in a database. The harder problem is modeling the operational workflow around them.
VolCore Ops is designed to explore that problem space in a disciplined way: define roles, map workflows, identify state transitions, document business rules, and plan a system that can support real event operations without slowing people down.
Because nothing says “smooth event day” like seventeen spreadsheet tabs, three clipboard versions, and one person named Brenda who knows the truth but is currently unreachable. We can do better for Brenda.
What it does¶
The planned v1 scope includes:
- Volunteer self-registration and staff invites
- Volunteer approval workflow
- Volunteer profiles and affiliations
- Credential and training tracking
- Required acknowledgments and forms
- Media release and signature support
- Event creation and cloning
- Teams/functions within events
- Shift creation, assignments, and signup flows
- Approval-required shift requests
- Waitlists with FIFO ordering and caps
- Attendance tracking and event-day check-in mode
- Self check-in/check-out with optional staff confirmation
- Staff-entered attendance with auto-confirmation
- Late arrival, early departure, no-show, and hours served tracking
- Admin-only overrides with required audit reasons
- Group messaging and notifications
- Print-ready rosters and schedules
- CSV and Excel exports
- Archive/trash/purge operations
- Immutable audit logging
The scope is intentionally practical. It focuses on the core operational workflows a single organization needs before reaching for multi-tenant complexity, mobile apps, advanced analytics, or other feature confetti.
Roles and permissions¶
VolCore Ops is planned around both global and scoped roles.
Global roles¶
- Admin — organization-wide management, settings, overrides, approvals, exports, and sensitive reports
- Volunteer — self-service profile, signup, forms, check-in, history, and participation workflows
Scoped roles¶
- Event Lead — manages assigned events, functions, shifts, staffing, attendance, and event-level exports
- Team Lead — manages assigned teams/functions within an event, including scoped assignments, attendance, and rosters
Some capabilities, such as volunteer approval, can be delegated rather than turned into an entirely separate role.
The permission model is important because event operations rarely fit a simple “admin or not admin” pattern. People often need power inside a specific event or team, not across the whole system.
Core workflows¶
Volunteer onboarding¶
Volunteers can register, complete intake, provide profile information, submit required acknowledgments, and wait for staff approval.
The system is planned to support approval states, profile photo review, emergency contact requirements, affiliations, credentials, and volunteer-visible service history.
Event and shift management¶
Event leads can create events, define teams/functions, create shifts, set slot counts, clone events, and manage staffing plans.
The system is designed to support open signup, staff assignment, approval-required requests, and waitlist behavior.
Attendance and check-in¶
Attendance is planned as a structured workflow rather than a single checkbox.
Supported attendance concepts include:
- Scheduled
- Checked in
- Checked out
- Late arrival
- Early departure
- No show
- Hours served
- Staff confirmation status
- Admin override with reason
Event-day check-in mode should prioritize speed, clarity, and low cognitive load. The goal is to help staff search, filter, confirm, flag exceptions, and keep the line moving.
Forms and compliance¶
VolCore Ops is planned to support required forms, typed acknowledgments, drawn signatures, media releases, and participation blocking when required documents or credentials are missing.
PDF generation is planned for submitted forms and other printable records.
Reporting and exports¶
The system is planned to produce practical event outputs such as:
- Check-in rosters
- Team/function schedules
- Master schedules
- Emergency contact sheets for authorized staff
- CSV exports
- Excel exports
- Attendance and hours reports
The point is not just to collect data. The point is to make the data useful when someone actually needs it.
Technical direction¶
VolCore Ops is planned as a modern self-hosted web application with clear service boundaries.
The intended stack is:
- Frontend: React, TypeScript, Vite
- Backend: Django and Django REST Framework
- Authentication: Django session-based authentication
- Database: PostgreSQL
- Async jobs: Celery and Celery Beat
- Broker/cache: Redis
- PDF generation: WeasyPrint
- Exports: CSV and Excel via
openpyxl - Reverse proxy: Caddy
- Styling: Tailwind CSS
- Deployment: Docker and Docker Compose
The backend is planned as a modular Django monolith with a DRF API layer. That choice is intentional: the system is workflow-heavy, relational-data-heavy, permission-heavy, and audit-heavy. Splitting that into microservices for v1 would be a stunning way to add complexity and receive very little in return. Absolutely not, thank you.
Architecture principles¶
VolCore Ops is designed around a few core principles:
- Keep the v1 scope disciplined
- Use a modular monolith rather than premature microservices
- Keep business rules in explicit service/domain layers
- Treat audit logging as a domain concern, not just request logging
- Enforce global and scoped permissions deliberately
- Use transactions for critical state changes
- Archive before purge
- Keep event-day workflows fast and low-friction
- Make exports, printing, and reporting first-class operational needs
- Document decisions before they become folklore
What it demonstrates¶
VolCore Ops is useful as a portfolio project because it shows systems thinking around real operational complexity.
It demonstrates:
- Requirements analysis
- Product scoping
- Workflow modeling
- Role and permission design
- Data model planning
- State transition thinking
- Audit and retention planning
- Event-day operational design
- Reporting and export planning
- Self-hosted deployment architecture
- Documentation-first project planning
- Scope control and phased implementation
This project is less about a flashy interface and more about the harder architectural question: how do you make people-heavy operations traceable, reliable, and easier to support?
Fancy dashboards are cute. Reliable workflows are better.
Current status¶
VolCore Ops is currently a work in progress.
The project is in a docs-first planning and scaffold phase, with the foundation being defined before the full application is built out. The repository includes product documentation, requirements, architecture notes, workflow definitions, UX planning, operational notes, implementation tasks, and starter backend/frontend/infrastructure directories.
The problem space is well-defined, and the project has been broken down into implementation-oriented planning materials rather than one vague “build the app” blob.
The current focus is on moving from structured planning into implementation while keeping the scope controlled, the workflows understandable, and the architecture supportable.
Current focus¶
Current focus areas include:
- Refining v1 scope
- Building out the Django backend scaffold
- Defining core domain models
- Implementing authentication and session-based API behavior
- Modeling volunteer onboarding and approvals
- Designing event, shift, assignment, and attendance workflows
- Building audit logging and override patterns
- Creating event-day check-in workflows
- Preparing reporting and export foundations
Skills demonstrated¶
- Systems analysis
- Requirements gathering and scope definition
- Web application architecture
- Django and DRF planning
- React and TypeScript frontend planning
- PostgreSQL data modeling
- Role-based and scoped permission design
- Workflow and state modeling
- Audit logging strategy
- Reporting/export planning
- Docker Compose deployment planning
- Documentation and implementation task planning