From Paper to Pipeline
Architecting a FERPA-compliant SaaS pipeline for a 150-person youth-serving nonprofit with no centralized data infrastructure.
The Build
For my first year as the founding evaluation director, I sat inside a 150-person youth-serving nonprofit with no centralized data infrastructure. Program records lived in spreadsheets, intake forms ran on paper, and revenue was reconciled by hand. There was no single source of truth — not for participants, not for outcomes, not for revenue. The pilot below is how we built one.
The work had federal stakes. Participant data was protected under FERPA — the Family Educational Rights and Privacy Act, the federal law governing student educational records. Intake forms collected demographics, medical information, and parental consent for students enrolled across in-school program sites. Compliance had to live at the point of capture, not be retrofitted. The pipeline had to be FERPA-clean from the first record.
I was a department of one, building cross-functionally with IT, Operations, and executive leadership across siloed program departments. The pilot was scoped to a single department running programs across 7 school sites — 20 staff total — with planned expansion across the org once the architecture proved out.
The Architecture
A three-system SaaS pipeline, built end-to-end
The pipeline was three SaaS tools connected by API into a single data flow — intake to record to revenue. Each system did one job. The integration carried the work between them so staff didn't have to.
FERPA compliance shaped every layer. Data collection had to be permissioned at capture, transmitted securely, and stored with role-based access. The architecture below is what that looked like in practice.
Front-door data capture. Every participant intake form lived here — demographics, medical information, parental consent forms — built to FERPA standards from the first field.
Participant demographic and medical data, parental consent records, program-specific intake fields per school site.
Connected to Salesforce via API. Submitted forms wrote records directly into the central database with no manual re-entry.
FERPA compliance had to live at the point of capture, not be retrofitted. Building the intake layer to spec meant the rest of the pipeline inherited compliance by default.
The central record store and workflow hub. Every participant record lived here. Program staff worked here daily — enrollment, attendance, outcomes.
All participant records, program enrollment data, outcome tracking, staff activity logs, role-based permissions.
Received records from FormAssembly via API; passed payment data to Stripe; served as the single source of truth across the pipeline.
Replaced disconnected spreadsheets with one database that staff actually worked in. The system stopped being a reporting requirement and started being a daily tool.
Payment processing for program fees. Closed the loop from intake to revenue without manual reconciliation.
Transaction records, program fee payments, refund and adjustment history.
Integrated into Salesforce so payments attached to the right participant record automatically. Finance no longer reconciled by hand.
Revenue capture had been the slowest, most error-prone part of the prior process. Closing that loop inside the pipeline freed up staff time and reduced revenue leakage.
Outcomes
Beyond the pilot cohort, 60+ staff across the wider organization were trained on the system interface through monthly sessions sustained from early winter through spring. Training was the on-ramp; active adoption stayed scoped to the pilot department by design, until expansion.
By the end of my tenure, 600+ student intake records had flowed through the pipeline, completing enrollment for 20 summer programs across two departments. The system that didn't exist 18 months earlier was now running the org's most regulated program enrollment, end-to-end.
Where It Maps
The work was SaaS implementation, evaluation infrastructure, and change management at once.
Standing up the pipeline meant doing three jobs in parallel — picking and integrating the stack, designing for FERPA at the point of capture, and getting staff to actually use it. Each maps cleanly onto a different role.
The pilot was twenty staff and seven sites. The architecture was built for the full org — 150 people, ten-ish programs, multiple departments. At scale, the pipeline doesn't change. What changes is the cohort plan that walks each new department through adoption. The system was designed for that from day one.
Hiring for a role where this implementation muscle would land — SaaS operations, evaluation infrastructure, mission-driven tech? I'd love to talk.