Technical Approach

Architecture Principles

Our recommended architecture for VOLY Next Gen is guided by six principles that align directly with VolunteerNow's needs for scalability, maintainability, and future extensibility:

• Cloud-Native & Scalable: Deployed on modern cloud infrastructure (AWS or Azure) with auto-scaling, containerized services, and managed databases to handle growth without re-architecture.
• API-First Design: Every capability exposed through well-documented RESTful APIs, enabling the VOLY mobile app, agency portals, third-party integrations, and future AI services to all consume the same backend services.
• Modular Architecture: Clean separation of concerns across domains (Volunteer Management, Agency Management, Opportunity Management, Check-in/Out, Reporting, Integrations) so that features can be developed, tested, and deployed independently.
• Security by Design: Role-based access control, data encryption at rest and in transit, SOC 2-aligned practices, and PII handling appropriate for background check and volunteer data.
• Progressive Enhancement: A responsive, mobile-first front-end that provides a native-like experience on mobile devices while offering full-featured desktop experiences for administrators.
• Integration-Ready: A robust integration layer with standardized connectors for background check providers, messaging services, payment systems, and future third-party services.

Recommended Technology Stack

While we will finalize technology selections during the Discovery phase based on VolunteerNow's team capabilities and operational preferences, our recommended starting point includes:

Key Architectural Components

Volunteer Experience Layer

Agency Portal

Administrative Platform

Integration Architecture

We will design a standardized integration layer that supports current and future integrations:

• Background Check Providers: JDP and VeriFYI integrations rebuilt with modern API patterns, error handling, and status tracking
• Communication Services: Email (SendGrid/AWS SES), SMS (Twilio), and push notification services
• Payment Processing: Stripe or similar for any payment/donation processing needs
• Mapping & Geolocation: Google Maps / Mapbox for location-based opportunity discovery
• Identity & SSO: OAuth 2.0 / SAML for enterprise and corporate partner SSO
• Future Integrations: Standardized webhook and API patterns for future CRM, HRIS, and third-party connections

AI-Ready Foundation

Platform Rebuild Risks & Mitigation Strategy

Based on geniant's experience rebuilding mission-critical platforms, we have identified three key risks specific to the VOLY Next Gen engagement and have designed explicit mitigation strategies for each:

• Risk 1: Data Migration & Legacy System Complexity — VOLY's current database contains 700,000+ volunteer records and serves 4,300+ nonprofit accounts with accumulated data from over a decade. Migration without validation could corrupt volunteer records or lose historical reporting. Mitigation: Early data audit (Week 2 of Discovery) to profile current data quality, document known issues, and establish cleansing rules. Parallel run period (first 2 weeks post-launch) where both systems are live. Documented rollback plan allowing instant reversion if data issues surface. Data validation testing at each migration stage with sign-off from VolunteerNow stakeholders.
• Risk 2: Stakeholder Adoption & Change Management — Agencies and volunteers have relied on VOLY for years and may resist or struggle with interface changes. Slow adoption = platform underutilization and perceived failure. Mitigation: Co-design workshops in Discovery phase with actual agency staff and volunteer representatives (not just leadership) to validate UX decisions early. Phased rollout: pilot cohort (one school district) for 2 weeks, then expand based on lessons learned. Comprehensive training materials (video guides, quick-start walkthroughs, live Q&A sessions) provided to all agencies 4 weeks before launch. VolunteerNow designates 'Champions' at each campus who receive early training and act as peer support. Post-launch, weekly 'office hours' for agency questions.
• Risk 3: Background Check Integration Complexity — Background checks (veriFYI, TazWorks) depend on third-party APIs with their own uptime, rate limits, and occasionally breaking changes. Integration failures = volunteer onboarding stalls. Mitigation: Early integration spike in Foundation Build phase (Phase 2, Weeks 7–12) with dedicated engineering time to validate API contracts, error handling, and retry logic before building the main volunteer flow. Mock background check service during development so we can test error scenarios without relying on third-party uptime. Circuit breaker pattern: if check-in fails due to background check API timeout, we degrade gracefully (check-in succeeds, background check retried in background). Fallback to manual verification workflow if API is down for extended period.

veriFYI as Independent SaaS Platform

A critical architectural requirement is that veriFYI functions as an independent, stand-alone background check platform while also being deeply integrated with the VOLY volunteer onboarding flow. This dual nature creates a sustainable business model for veriFYI and maximum flexibility for districts. We achieve this through a microservices-based integration pattern.

geniant brings direct, hands-on experience to this architecture: we served as the full-stack technology partner for backgroundchecks.com for over five years, building and operating a consumer-facing background screening platform from the ground up. That engagement covered FCRA-compliant screening workflows, identity verification integrations, adverse action processing, PII data governance at scale, and the high-availability infrastructure requirements that time-sensitive background check requests demand. The architecture decisions below are informed by that operational experience — not derived from documentation alone.

Student Volunteerism: MLP Architecture

Student volunteerism is not a full K-12 product launch, but rather a research-forward minimum lovable product (MLP) designed to validate the market while protecting student privacy and enabling longitudinal research. The architecture addresses four critical requirements:

• Hour Validation System: A dedicated subsystem for validating and certifying student volunteer hours. This is the core requirement from VolunteerNow's perspective. When a student completes a volunteer shift, campus coordinators can validate the hours in the system, creating an auditable, certifiable record. This differs from adult volunteering where self-reporting is acceptable.
• FERPA-Compliant Research Data Export: VOLY will include a research data export feature that anonymizes student volunteer data using k-anonymization and differential privacy techniques. Districts can authorize research partners (universities, nonprofits) to access this data for longitudinal studies. All exports are logged and auditable.
• Texas Schools Project Registration: Integration with TSP infrastructure to enable districts to register student volunteers as part of their civic engagement research. VOLY provides the technical backbone for TSP data collection.
• Congressional Award Integration: Student volunteers pursuing Congressional Awards can use VOLY to track service hours and document their impact — satisfying both the volunteer organization and the award program.
• Growth Path: The MLP is intentionally scoped to be small at launch. It includes student registration, opportunity discovery, check-in/check-out, hour validation, and basic reporting. Future phases can add peer mentoring, financial literacy programs, or college prep features — but only with district demand and research validation.

Multi-Tenant Architecture: District, Campus, & Volunteer Hierarchy

VOLY Next Gen must support a complex multi-tenant model where a District (e.g., Dallas ISD) has visibility across all campuses, but individual Campus Coordinators see only their own campus data, and Volunteers see only opportunities relevant to their interest and location. This is implemented via:

• Hierarchical tenant model: Each District is a top-level tenant; each Campus is a child entity within a District with its own row-level security policies
• Row-Level Security (RLS): PostgreSQL RLS policies enforce data boundaries at the database level, not application level, so even if an attacker bypasses the app they cannot see cross-campus data
• Standardized features across all tenants: volunteer registration, opportunity discovery, check-in/check-out, reporting framework
• Configurable per-tenant settings: branding (logos, colors), volunteer types, forms, background check workflows, communication templates, workflow steps
• District admin configuration UI: District admins can modify all tenant-specific settings without code changes — managed via a configuration database

Database Schema: Preventing Data Seepage Between Campuses

The database schema is designed to make data isolation explicit and enforce it at every layer:

FERPA & COPPA Governance for Student Volunteer Data

Student volunteerism is a new and sensitive capability in VOLY Next Gen. All student data will be treated as education records under FERPA, and additional protections apply for students under 13 (COPPA):

Accessibility Engineering & Spanish Language Support

The Experience Design section covers our accessibility design principles. This section covers how we engineer, test, and verify WCAG 2.2 AA compliance in the codebase — and how Spanish language support is implemented at the framework level:

• CI/CD Enforcement: Axe-core is integrated directly into the CI/CD pipeline — any new WCAG violation fails the build before code can merge to main. This prevents accessibility regressions from reaching production. Lighthouse accessibility audits run on every sprint review and are tracked as a sprint metric.
• Sprint-Level Manual Testing: Every sprint, a QA engineer runs manual accessibility testing using keyboard-only navigation and NVDA/JAWS on Windows and VoiceOver on macOS. Screen reader tests cover the core volunteer flows (registration, opportunity search, check-in/check-out, hour reporting) with documented test cases.
• Third-Party Audits: We engage a certified WCAG evaluator for independent accessibility audits at key project milestones (end of Design phase, end of Development phase, pre-launch).
• VPAT Commitment: geniant will deliver a completed VPAT 2.x (WCAG Edition) at project completion. All critical and serious accessibility defects are remediated before launch — not deferred to a post-launch backlog.
• Spanish Language Implementation: Internationalization is implemented via React-Intl with externalized string files, enabling runtime language switching without page reload. All volunteer-facing flows — onboarding, opportunity discovery, check-in/check-out, notifications — are available in English and Spanish at launch. Strings are managed separately from code so translations can be updated without a deployment.

3-Year Product Roadmap with AI Capabilities

Beyond the immediate Next Gen launch, geniant envisions a 3-year roadmap that leverages VOLY's new foundation to introduce intelligent, AI-powered capabilities while maintaining strict governance over data and bias:

Technical Debt Management: geniant commits 20% of each sprint's engineering capacity to technical debt — code refactoring, dependency updates, infrastructure hardening, and test coverage improvement. This percentage may increase to 30% in later phases as the codebase matures. Architecture Decision Records (ADRs) document all major technical choices and are reviewed bi-weekly by the Lead Architect to identify emerging debt patterns before they compound.

Data Masking & Anonymization for Approved Research

VOLY's data is a valuable asset for education research. We will enable approved research use cases while protecting individual privacy:

• Data governance framework: approved research use cases are defined and approved by the District before any data is shared. All data exports are logged and auditable.
• Anonymization techniques: k-anonymization (records grouped so individuals cannot be re-identified), differential privacy for aggregate statistics, field-level masking for PII in research extracts
• Operational vs. research data: operational data (full fidelity, restricted access) powers day-to-day platform function. Research data (anonymized, aggregated) is exported only with explicit approval
• FERPA compliance: student data in research contexts requires either district consent or falls within FERPA's research exception. All research data exports are documented with consent proof.

LLM & AI Coding Tool Policy

geniant's SDD methodology uses AI-augmented development workflows, which raises important questions about data protection that we address explicitly:

• AI tools used in SDD: GitHub Copilot (enterprise version, no training on private code), Claude API (via geniant's enterprise account, not consumer chat.claude.ai)
• Zero ingestion of VolunteerNow logic or data into public models: VolunteerNow specifications, business logic, and proprietary workflows are never submitted to public AI model prompts. All SDD specifications are stored in a private GitHub repository accessible only to the project team.
• Controls: enterprise/API versions of AI tools do not use inputs for model training. All AI-generated code undergoes human code review before merge. SDD specifications are treated as confidential intellectual property.
• Compliance: fully compliant with VolunteerNow's data protection requirements and industry standards for AI tool usage in regulated environments.

Third-Party Dependencies & Licensing

The platform will integrate with several third-party services. Here are the key ones with ongoing implications for VolunteerNow:

Open-source licensing: All open-source libraries used will be under permissive licenses (MIT, Apache 2.0, BSD). No GPL-licensed code will be included in the delivered platform, ensuring VolunteerNow retains full control over platform licensing and distribution. All dependencies will be documented in a Software Bill of Materials (SBOM) provided at project handoff.

Data Migration Strategy

Migrating the existing VOLY data to the new platform is a critical, non-negotiable deliverable. Years of volunteer records, agency profiles, opportunity history, hour logs, and organizational relationships represent VolunteerNow's institutional memory — and zero data loss is the only acceptable outcome. Our migration approach is structured, testable, and reversible at every step.

• Data Audit (Phase 1): During Discovery, we conduct a comprehensive audit of the current VOLY database — cataloging every table, relationship, data type, and volume. We identify data quality issues (duplicates, orphaned records, malformed entries) before writing a single migration script.
• Schema Mapping (Phase 2): We produce a source-to-target data dictionary mapping every current field to its Next Gen equivalent. Where the new schema introduces structural changes (normalized relationships, renamed fields, new constraints), we document the transformation logic explicitly.
• Automated Migration Scripts (Phase 3–4): Migration scripts are written as versioned, idempotent code — not one-time manual operations. This means they can be run repeatedly in test environments until the output is verified clean, then executed once in production with confidence.
• Pilot Migration (Phase 4): We run a full dry-run migration against a production data snapshot in the staging environment. geniant and VolunteerNow staff validate record counts, spot-check data integrity, and sign off before the production cutover is scheduled.
• Production Cutover (Phase 5): Cutover is executed during a planned maintenance window. The legacy VOLY system remains in read-only mode during the window, providing a rollback option if any issue is detected. Post-migration, we run automated reconciliation checks — comparing record counts and spot-check samples between old and new systems.
• Historical Data Preservation: All historical volunteer hours, agency records, and participation history are migrated and remain queryable in the new platform. No data is archived or discarded without explicit VolunteerNow approval.

Source Code Repository Access & Cloud Environment

VolunteerNow will have complete ownership and control of all code and infrastructure:

• VolunteerNow will be the primary owner of the GitHub (or Azure DevOps) repository from day one — not just granted read access at project end. geniant has write access during development, which is revoked post-launch.
• All infrastructure will be deployed to a cloud account owned by VolunteerNow (not geniant). geniant has delegated administrative access during development, which is revoked at project completion.
• VolunteerNow retains full rights to all codebase, infrastructure configurations, design assets, and project artifacts. No licensing restrictions.
• Recommended hosting environment: AWS with us-east-1 as primary region (Virginia data center) for cost and latency optimization. Alternative: Azure US regions if VolunteerNow has enterprise agreements. Data residency: all data stored in US-based regions per RFP requirements.
• Post-launch, VolunteerNow can hire internal engineers or engage other vendors to maintain VOLY without geniant approval or licensing restrictions.