Custom Software for Education — Built on Interoperability and Student-Data Privacy

Education software handles some of the most protected records in any sector — grades, attendance, IEPs, behavioral notes, and the personal information of minors. FERPA governs how those records are accessed and disclosed. COPPA adds a layer when a product touches children under 13. And a growing patchwork of state laws, from California's SOPIPA to dozens of others, often goes further than federal rules. A product that ignores this gets bounced by a district's privacy review before a single classroom uses it.

We build with those constraints from the first data model. Access to student records is least-privilege and role-aware, with the FERPA distinction between parent and eligible-student access enforced in code. Disclosures are logged. Data collection is minimized to what the educational purpose requires. And rostering and single sign-on run through the standards districts already trust — Clever, ClassLink, OneRoster, and LTI — so adoption is a configuration, not a fight.

The privacy regime is layered in a way few sectors match. A single student record can simultaneously fall under FERPA as an education record, COPPA as data from a child, and a state student-privacy statute that bans secondary use or targeted advertising outright. The product has to satisfy all of them at once, and a district's privacy officer will check. Getting this wrong is not a fine months later — it is a failed procurement today.

Interoperability is the other half. Education runs on specific, unforgiving standards: OneRoster for rostering, LTI 1.3 for launching tools inside an LMS, Clever and ClassLink for single sign-on and data sync, QTI for assessment content. Each has exact conformance expectations, and a near-miss implementation simply will not connect to PowerSchool or Canvas. We have built against these standards and know where the conformance details bite — usually in LTI launch signing and OneRoster delta-sync semantics.

FERPA. When you act as a service provider under the school official exception, you inherit obligations on how education records are used and protected. We enforce least-privilege access, log disclosures, support directory-information opt-outs, and handle the parent-versus-eligible-student access distinction in the data model. We do not give legal advice — we build the controls your counsel and your district customers expect.

COPPA. For products touching children under 13, we minimize collection, design consent flows, and support the school-consent model many edtech tools rely on. Data is collected for the educational purpose and not repurposed.

State student-privacy laws. SOPIPA in California and similar statutes in many states often ban targeted advertising, secondary use, and sale of student data outright. We bake those restrictions into the architecture so a single misconfigured analytics tag does not create a compliance problem.

Ransomware and data theft. The education sector is among the hardest hit. We harden authentication, rostering integrations, and family-facing portals, require MFA on administrative accounts, and keep an immutable audit trail so an incident can be reconstructed.

Accessibility. Public-education software is expected to meet WCAG and Section 508 expectations. We build accessible by default — keyboard navigation, screen-reader support, and color-contrast compliance — because a procurement will check and an inaccessible product excludes students.

Next.js 16 on the App Router with React and TypeScript end-to-end for portals and tools. Postgres for the system of record, with row-level isolation when the product is multi-tenant across districts. Prisma or Drizzle as the type-safe ORM. LTI 1.3 and OneRoster libraries for interoperability, and Clever or ClassLink SSO wired through a standard auth layer so families never see another password.

Background workers (Inngest or BullMQ on Redis) handle roster delta-syncs and analytics rollups that should not block a request. Sentry plus a log aggregator for observability, with student-PII-aware redaction in the logger. Accessibility is enforced in the component layer and checked in CI. The web tier deploys to Vercel; the data plane moves to a hardened VPC when a district's data-protection agreement requires stricter controls.

First, building the product and bolting on privacy at procurement time. A district's privacy review will ask exactly where student data lives, who can see it, what is logged, and what is shared with third parties. If those answers were not design decisions, the deal stalls while the team re-architects. Design for the privacy review first.

Second, treating LTI and OneRoster as ordinary REST APIs. They are not — LTI launch signing and OneRoster delta-sync have exact conformance rules, and a near-miss simply will not connect to Canvas or PowerSchool. Budget for the conformance details, because the demo that worked against a mock will fail against the real LMS.

Third, ignoring the eligible-student transition. FERPA rights move from the parent to the student at 18 or upon postsecondary enrollment. A portal that hard-codes parent access creates a compliance gap the day a student turns 18. Model the access rules so the transition is data, not a code change.

Student data is a trust you do not want sitting on an anonymous contractor's laptop overseas. Districts ask pointed questions about who handles the data and where it lives, and "an offshore team we have never met" is not an answer that wins procurement. We are US-based and founder-led, and the person who designs your privacy posture is the person who can defend it in a vendor review.

William Beltz writes or reviews every line that touches student records, rostering, and access control. NDAs are mutual and signed before discovery. Source code lives in your GitHub organization, not ours. The handoff is documented for either ongoing collaboration or in-house ownership — your call.

Schools and edtech vendors are heavily targeted by ransomware and data-theft crews because student records are valuable and defensive budgets are thin. We run penetration tests mapped to the MITRE ATT&CK techniques the education sector actually faces, then deliver a heatmap of which techniques succeed, which get detected, and which get blocked.

For the student portals, LTI tools, and rostering integrations that carry student data, web application penetration testing covers authentication, authorization, single sign-on, and the API surface that connects to district systems. Every finding maps to ATT&CK technique IDs so your team knows what to alert on.