FFC delivers a charity website through an eight-stage lifecycle. Each stage has a clear exit gate, a clear owner role, and a documented way to handle the typical blockers. This page is the operations-team reference; the charity-facing version on freeforcharity.org describes the same flow from the charity's perspective.
The “filter out” philosophy
FFC's intake is intentionally selective: charities demonstrate readiness through the validation steps before service-delivery resources commit. This protects volunteer time and ensures every shipped site lands at a charity that can actually run it.
Eligibility floor
- US-based charity with US-citizen point of contact.
- 501(c)(3) status active (or pre-501(c)(3) using the pre501c3 track).
- At minimum Gold Candid seal (see wordpress-guidestar-guide).
- Revenue under $1M and not federally grant-funded (priority criterion).
Stage table
Stage 1 — Initial Contact & Onboarding
Charity discovers FFC and completes account setup through the WHMCS portal by selecting the "Charity Onboarding & Validation" product. Intake form is submitted at no cost.
Owner role: Intake Volunteer
Exit gate: WHMCS account exists, intake form is fully completed, charity has acknowledged the FFC AUP.
Blocker handling: Missing fields → reply with the specific gaps. International charities → polite decline, US-only restriction.
Stage 2 — FFC Validation Checks
External + internal validation runs against the intake record (501(c)(3) status, NTEE code, TechSoup, VolunteerMatch, Facebook, email, WHMCS / PayPal, financial sizing, content review, demographic).
Owner role: Intake Volunteer
Exit gate: All nine validation checks resolve to a documented pass or a documented exception.
Blocker handling: Below Gold seal → bounce back to GuideStar guide. Below US-citizen point of contact → polite decline. Pending TechSoup → put intake on hold with reminder cadence.
Stage 3 — FFC Offers Services
Approved charity receives a service offer based on mission fit and operational capacity. Priority is given to charities with under $1M revenue that are not federally grant-funded. FFC supports up to 100 organizations.
Owner role: FFC Global Admin
Exit gate: Charity accepts the offer in writing (WHMCS quote signed).
Blocker handling: Over capacity → backlog with a quarterly review. Mission misalignment → polite decline with rationale.
Stage 4 — Basic Services Package
Two FFC-funded foundations: (a) free domain, registered and maintained by FFC, connected through Cloudflare; (b) Microsoft 365 tenant via the Nonprofits program with domain validation.
Owner role: FFC Global Admin
Exit gate: Domain resolves through Cloudflare. Microsoft 365 tenant validates and grants nonprofit pricing.
Blocker handling: Cloudflare verification stuck → check registrar nameserver records first. M365 nonprofit validation rejected → re-submit with the charity's Candid profile link.
Stage 5 — Charity System & Website Setup
Branches by status. Pre-501(c)(3) charities complete the WordPress site checkout product and receive an auto-built starter site. 501(c)(3) charities complete the InterServer / Hostinger nonprofit application and designate FFC as tech sponsor.
Owner role: FFC Global Admin
Exit gate: WordPress install is live on its eventual production hostname; charity has admin credentials.
Blocker handling: Hosting application denied → escalate to the FFC founder for sponsor letter. WordPress install errors → see wordpress-hosting-techstack escalation order.
Stage 6 — Technical Stack Assignment
Volunteer admin configures the underlying WordPress infrastructure: SSO accounts, role assignments to charity stakeholders, two-factor enforcement, backup schedule.
Owner role: Web Developer Volunteer
Exit gate: Charity primary contact can log into WP admin and into the M365 tenant via SSO.
Blocker handling: SSO mismatch (charity using personal email instead of charity-domain mailbox) → block until charity-domain mailbox exists.
Stage 7 — Plugin & Theme Deployment
Install the WPMUDEV Dashboard plugin, Defender (security), Hummingbird / Smush (performance), Snapshot Pro (backups). Deploy Divi parent theme and the FFC child layout.
Owner role: Web Developer Volunteer
Exit gate: WPMUDEV Dashboard reports green across security, performance, backup. Divi child theme is active.
Blocker handling: Plugin licence conflicts → confirm the WPMUDEV account membership covers the site.
Stage 8 — Initial Site Launch & Configuration
Functional template site goes live in minutes, pre-populated with the charity's onboarding info. Upgrade PHP to the host-supported 8.x track. First production backup runs.
Owner role: Web Developer Volunteer
Exit gate: Site is reachable at production hostname over HTTPS, Lighthouse > 80, first backup successfully restored to staging as a smoke test.
Blocker handling: PHP upgrade breaks Divi → roll back to the previous PHP minor and open a Divi support ticket.
After Stage 8 — service expansion
Once the basic site is launched and the charity demonstrates they can actually operate it (post a few news items, respond to a contact-form submission, manage their own user accounts), FFC unlocks advanced services: full design polish, custom functionality, advocacy tooling, and increasingly, a static-site migration to the modern FFC Next.js stack.
Cross-references
- wordpress-charity-validation — Stage 2 detail.
- wordpress-guidestar-guide — Eligibility floor.
- wordpress-hosting-techstack — Stages 4-8 vendor map.
- WordPress-to-Next.js conversion guide — Where charities go after they outgrow the WordPress delivery.