Skip to main contentSkip to footer
    Back to Case Studies
    WHD ReachWilliam H. Douglas Foundation
    NonprofitMulti-Tenant SaaSEducation

    WHD Reach

    The digital backbone for a college-access foundation: student roadmaps, scholarships, consent and advocacy in one platform that other nonprofits can run too.

    Project Preview

    Live website preview - whdfoundation.org

    5
    Roles: student, guardian, advocate, org admin, platform admin
    30
    Application modules
    63
    Database migrations, RLS on every table
    14
    Database-level security test suites

    Advising & roadmap

    Tasks, appointments, milestones, messaging and shared resources between a student and their assigned advocate.

    Scholar forms & intake

    Template-driven forms engine with per-scholar packets, guardian token signing and an admin template editor.

    Find funding

    Curated scholarship and grant catalog, per-student saved lists, award tracking that flows into the Outcomes Ledger.

    Explore colleges & careers

    Live search on the U.S. Department of Education College Scorecard and Department of Labor CareerOneStop.

    Consent at the database layer

    COPPA, SOPIPA and FERPA-aware consent model: a guardian's revocation locks access instantly through row-level security.

    Back office for the foundation

    BizDev CRM with Grants.gov import, grant-fund allocations, board governance, donations with receipts, email marketing.

    The problem

    The William H. Douglas Foundation is a California 501(c)(3) named for a man who went from a ninth-grade education and a cotton farm in Tennessee to retiring as an aerospace engineer at North American Rockwell, having started there as a janitor. The foundation's work is advocacy: keeping students from under-resourced backgrounds close to an adult who knows the path to college, and moving them along it.

    When we started, that work ran on files. A scholarship tracker in Excel, copyrighted 2017 and still in daily use, with a hand-built cost-of-attendance calculator for Pell, institutional grants, Stafford and PLUS loans. High school and college graduation schedules tracked A-G credits and GPA per student in spreadsheets. Student profiles lived in PowerPoint decks: test scores, GPA, photo, home address, a parent's phone number. Most of those students are minors.

    What the foundation needed

    • One system of record: Roadmaps, forms, scholarships, colleges and communication in one place, scoped to the right adult.
    • Compliance that does not depend on staff remembering: Minors' data means COPPA, California's SOPIPA, FERPA by contract, and verifiable parental consent. The rules had to live in the database, not a policy binder.
    • Room to grow: The foundation wanted partner nonprofits to be able to run their own programs on the platform later, without a rebuild.
    • Technology that serves the relationship: The stated design principle: tech amplifies advocacy, it never replaces the advocate.

    Where AI fits, and where it deliberately does not

    WHD Reach contains no language-model features, and that is a decision rather than an omission. The platform holds sensitive data about minors, and the foundation's product principle is that a human advocate is the product. We used AI heavily in how we built it: the platform was delivered in agent-driven slices with an AGENTS.md contract, automated tests and a CI gate on every push, which is how a 30-module, five-role, multi-tenant platform reached a working pilot in weeks. But no student record is ever sent to a model, and none of the external integrations receive anything but a search term and an API key.

    How we built it

    A modular monolith with the database as the last line of defense

    WHD Reach is a Next.js 16 App Router application on Vercel with Supabase Postgres in a US region. Authorization has three layers. A coarse gate in Next's proxy layer, per-segment role checks that also enforce TOTP multi-factor for staff, and row-level security on every table as the backstop. Every tenant row carries an organization ID. Helper functions in a private schema answer questions like "is this user a guardian of this student" without the policy recursion that usually makes RLS painful.

    The consent model

    Student owns, parent consents

    Date of birth drives minor status. A guardian's consent moves through pending, granted, revoked or expired, in two scopes: participate, and allow messages. Revocation locks access immediately through RLS while retaining the record.

    Append-only evidence

    The consent ledger and the audit log cannot be updated or deleted; a trigger blocks both. Fourteen SQL test suites, from consent gating to roster-import consent, run against the real policies.

    Integrations that fail safe

    Every external integration is dormant-safe: with no credentials configured, it becomes a friendly no-op and the app still builds and deploys. That covers the College Scorecard, CareerOneStop, Grants.gov federal grant discovery with one-click CRM import, QuickBooks Online, Stripe for donations and membership, Resend for email and reCAPTCHA on public forms. Background work runs through a Postgres job queue drained by a Vercel Cron endpoint every five minutes, claimed with SKIP LOCKED, and swappable for a hosted queue without touching the code that enqueues jobs.

    What each role gets

    Students: intake, roadmap and milestones, tasks, appointments, messaging, scholarship search and saved lists, College Scorecard college list, career explorer, resources, documents
    Parents and guardians: consent portal, visibility into the student's college list, family area, payments and fees
    Advocates: caseload workspace, student messaging, tasks, academics with GPA and attendance
    Organization admins: forms template editor, roster import, events and programs, college tours, timekeeping, fiscal budgets, board governance, org-scoped reports
    Platform admins: cross-tenant roll-up, BizDev CRM, grant-fund allocations and expenditures, Outcomes Ledger, email marketing, billing, giving and donations, partner-org CRM

    Timeline

    1. 15 to 16 June 2026: Scaffold plus the first seven functional slices: auth, tenancy, consent, roadmap, forms, funding, colleges.
    2. 17 to 27 June 2026: BizDev CRM, grant-fund utilization, analytics, partner-org CRM, engagement back office, email marketing.
    3. July 2026: The foundation's legacy spreadsheets and profile decks handed over and mapped into the data model.
    4. August to September 2026: Stripe donations and invoicing, giving receipts, board portal, careers page, housing partnership page, reCAPTCHA, branding. Staff and org admins live in pilot.

    Problems worth talking about

    Reports that cannot leak

    The Outcomes Ledger exports CSV and PDF impact reports for funders. They carry de-identified counts and dollars only, and a database test proves no individual record can reach the export.

    A free tier guaranteed in code

    The features the foundation promised would always be free live in a frozen constant that the price catalog can only add to. A unit test fails if anyone tries to move them behind a paywall.

    Secrets that cannot reach the browser

    The service-role client is guarded by a server-only import, so using it in a client component is a build error rather than a data breach.

    Next.js 16 edges

    Awaited params and search params, the middleware-to-proxy rename, a password reset that ignored the code parameter, and a checkout that never reached Stripe were all caught by the CI gate or the runbook before a student ever saw them.

    Where it stands

    A pilot, reported honestly

    Staff and organization admins are live at app.whdfoundation.org. Onboarding of real minors is intentionally gated behind two things we do not control: production email delivery and legal counsel's sign-off on the typed-name e-signature flow for liability and medical consent. We do not publish student counts or outcome numbers for a platform that has not yet enrolled its first cohort. The foundation's mission metrics, enrollment, retention and graduation, are the ones the Outcomes Ledger was built to measure, and they will appear here when there is a baseline.

    Technology here amplifies the human advocacy relationship; it never replaces it.

    — WHD Reach architecture principle

    What This Project Does Well

    Multi-tenant from day one: Organization is the tenant boundary, so partner nonprofits can run their own programs on the same platform
    Row-level security on every table, with SECURITY DEFINER helpers that end policy recursion
    Append-only consent ledger and audit log: UPDATE and DELETE are blocked by trigger
    No student PII leaves the platform: external integrations receive search terms and a key, nothing else
    Impact reporting is aggregate-only by construction, proven by a database test
    CI gate on every push: lint, type-check, tests, dependency audit and build

    Technologies Used

    Next.js 16 (App Router, React 19, TypeScript, Turbopack), Tailwind CSS v4 with a token-driven WCAG 2.2 AA design system, Supabase Postgres with row-level security (US region), Supabase Auth with TOTP MFA for staff, Vercel, Postgres-backed job queue drained by Vercel Cron, College Scorecard API, CareerOneStop API, Grants.gov, QuickBooks Online, Stripe (donations and membership), Resend, reCAPTCHA v3, Vitest, GitHub Actions

    Ready to Build Something Similar?

    Let's discuss how we can help transform your business with a custom digital solution.

    Visit whdfoundation.org📅 Schedule Consultation