Aasha Foundation — NGO Impact & AMC Platform

Table of Contents

• The Challenge
• Architecture & Solution
• Tech Stack
• Key Engineering Decisions
• Deep-Dive: Maintenance Playbook
• Deployment

The Challenge

Aasha Foundation is a non-profit organization dedicated to community upliftment through education and sustainable development in North-East India. The organization needed a highly professional web presence to showcase their substantial social impact, facilitate donations, and engage volunteers.

However, the previous implementation suffered from critical operational issues:

• No Staging Environment: Content updates were made directly on the production site, risking breaking changes during high-traffic campaign drives.
• Security Vulnerabilities: The site suffered from regular spam injection, brute-force attempts, and lacked structured access controls.
• PDPP Act 2023 Non-Compliance: Forms collected donor and volunteer PII (Personally Identifiable Information) without active consent, putting the foundation at legal risk under India's Digital Personal Data Protection Act.
• Non-Technical Usability Bottlenecks: Staff members had to edit raw HTML to update simple content, leading to delayed releases and accidental design breaks.

The requirement: Establish a secure, high-performance web platform under a structured Annual Maintenance Contract (AMC). The system must guarantee high uptime (99.95%), introduce a staging-to-production deployment workflow, implement field-level data privacy compliance, and remain entirely manageable by non-technical editors.

Architecture & Solution

To resolve the operational failures, we instituted a strict Staging-First Architecture with Cloudflare edge caching, Wordfence malware shields, and compliant out-of-band backups.

Non-Technical Administration Boundary

The architecture isolates non-technical operations from core files. System parameters, database configurations, and plugin core layers are strictly read-only for standard editors. Administrative controls are locked under multi-factor authentication (MFA).

Tech Stack

Key Engineering Decisions

1. Custom Elementor & ACF Scoping (Non-Technical Usability)

• Why over standard Gutenberg or custom templates: Standard Gutenberg blocks exposed too many visual layout decisions to editors, resulting in brand drift. Fully custom raw PHP templates required a developer for every change.
• Implementation:

  // Scoped ACF field group registration for aasha-events
  if( function_exists('acf_add_local_field_group') ):
    acf_add_local_field_group(array(
      'key' => 'group_aasha_events',
      'title' => 'Event Scoped Meta',
      'fields' => array (
        array (
          'key' => 'field_event_date',
          'label' => 'Event Execution Date',
          'name' => 'event_execution_date',
          'type' => 'date_picker',
          'required' => 1,
        )
      ),
      'location' => array (
        array (
          array (
            'param' => 'post_type',
            'operator' => '==',
            'value' => 'event',
          ),
        ),
      ),
    ));
  endif;

• Result: Non-technical staff can update dates, impact metrics, and photo galleries via simple form fields. Visual layout parameters are locked, maintaining 100% brand consistency.

2. Complianz Integration & Privacy Shields (PDPP Act 2023 Compliance)

• Why over standard cookie banners: Standard banners only notify users but do not actively block scripts, failing India's strict PDPP Act 2023 "consent before processing" requirements.
• Implementation: Integrated Complianz PDPP module with strict script blocker. Before a user actively checks the consent box, all third-party analytics and form trackers are entirely disabled in the DOM.
• Result: Zero data is gathered without explicit user consent. Data retention schedules purge local form database records every 30 days to enforce data minimization.

3. Wordfence Premium + Cloudflare WAF (Vulnerability Shielding)

• Why over stock security plugins: High-profile NGO portals are prime targets for automated botnets and brute-force scanners. Standard security tools run on-server only, taxing CPU resources during an attack.
• Implementation: Enabled Cloudflare Edge Rules to block common XML-RPC scan payloads before reaching the server, with Wordfence Premium handling in-memory rate limiting and core integrity scans.
• Result: CPU overhead during automated crawl surges dropped by 75%. Zero successful security breaches were recorded.

4. UpdraftPlus + Google Cloud Storage (Offsite Backups)

• Why over standard hosting-level backups: Hosting backups are stored on the same infrastructure. If the VPS host experiences a hardware fault, both the live site and backups are lost.
• Implementation: Configured UpdraftPlus to run differential database backups, encrypting the SQL output and pushing it out-of-band to a cold-line storage bucket in Google Cloud.
• Result: Complete system recovery path validated in under 30 minutes from staging restoral tests.

Deep-Dive: Maintenance Playbook

To ensure long-term operational reliability, the AMC is executed via a rigorous, documented timeline:

Daily (Automated)

• Security Check: Wordfence schedules a silent malware and core integrity scan at 02:00 IST.
• Uptime Tracking: Automated ping monitors verify portal availability every 5 minutes. Real-time alerts are routed to developer channels on downtime.
• Offsite Backup: Encrypted daily database backup uploaded to Google Cloud GCS bucket.

Weekly

• Broken Links Audit: Automated check of all external outbound links, redirecting or updating broken items.
• Staging Sync: Staging database refreshed with production content structures for seamless preview environments.
• Form Verification: Standard sandbox submissions generated on critical donation/volunteer forms to ensure functional gateway paths.

Monthly

• Staging Test: All pending WordPress core, theme, and plugin updates are executed on the staging environment.
• Compatibility Review: System logs, PHP error logs, and console scripts are checked on staging for deprecation warnings.
• Production Rollout: Upon staging sign-off, updates are deployed to production during low-traffic windows (01:00-03:00 IST) with rollbacks ready.
• Lighthouse Performance Audit: Detailed Speed and Core Web Vitals audit generated and delivered as a *Monthly Maintenance Report*.

Quarterly

• Deep Security Audit: Manual audit of admin users, active credentials, file permissions, and failed login logs.
• PDPP Act Compliance Review: Verify form data minimization practices, validate active consent cookie blockers, and execute a data retention purge checklist.
• Backup Restore Validation: Actively restore a GCS backup onto a sandbox staging server to confirm absolute backup recovery reliability.

Support Model & SLA (Quick Inquiry Response)

Deployment

Quick Start

To run a local staging environment mapping the live configuration:

# Clone the repository structure
git clone https://github.com/bhargab-pratim-sarma/aasha-amc.git && cd aasha-amc

# Spin up local stateful dependencies via docker-compose
docker-compose up -d

# Verify local DB connectivity
docker-compose exec db mysqladmin -u root -p ping

Production Stack

Cloudflare WAF → LiteSpeed Web Server → PHP 8.2 FPM
PostgreSQL/MariaDB 10.6 (Encrypted table-spaces)
UpdraftPlus Engine → Google Cloud Storage Bucket
Wordfence Premium Gateway & Anti-Malware

Deployment Checklist

• [ ] Staging compatibility checks pass (zero console errors, zero PHP warnings).
• [ ] Complete offsite database backup executed.
• [ ] Maintenance window enabled on production gateway.
• [ ] Theme changes, database migrations, and updates pushed to production.
• [ ] Post-deploy form validation and donation gateway dry-run completed.
• [ ] PDPP Act cookie compliance checked in incognito browser.
• [ ] Production cache cleared and system warm-up executed.

*This case study documents our operational execution of a professional Annual Maintenance Contract (AMC). All practices strictly align with data privacy, security, and staging-first workflows suitable for mission-critical NGO deployments.*