Custom Software for Education Technology (EdTech)
Secure, flexible, and compliant architecture tailored for the unique challenges of the Education Technology (EdTech) sector.
Vivek Mishra — Founder & Lead Architect, ERPStack
Quick Answer
In short: an edtech platform stands or falls on rostering and the FERPA school-official boundary. ERPStack builds custom edtech systems on LTI 1.3, OneRoster 1.2 and Ed-Fi, with the COPPA Rule duties that bite on 22 April 2026, district NDPA data maps, WCAG 2.2 AA, and learning telemetry kept out of the student records database.
Why Custom ERP for Education Technology (EdTech)?
Operating in the Education Technology (EdTech) sector requires a systems architecture designed for high scalability, operational flexibility, and strict regulatory compliance. Standard off-the-shelf software forces your teams to reshape their workflows to fit rigid software packages. A custom ERP for the Education Technology (EdTech) industry maps directly to your exact business logic. Deployed to your secure cloud infrastructure (AWS or Azure), the system isolates database schemas, automates redundant reporting tasks, and scales without user seat licensing fees. This ensures your corporate data remains under your absolute control, eliminates vendor lock-in, and lowers long-term operational technology costs by up to 70% over a 3-year period.
Industry Pain Points
- Rostering breaks every August when the SIS re-issues OneRoster sourcedIds and the ERP upserts blindly
- LTI 1.1 shared secrets still in production long after LTI 1.3 moved to OAuth, OpenID Connect and JWT
- A separately negotiated NDPA per district, so nobody can say which fields the PostgreSQL schema holds
- Grade passback failing because Assignment and Grade Services 2.0 writes to a line item last night's CSV replaced
- No retention clock anywhere in the schema, which COPPA section 312.10 now requires in writing
- A VPAT claiming support while the React portal fails WCAG 2.2 target size, focus and dragging criteria
Engineering Blueprint
An edtech platform does not pick its own API surface — 1EdTech does. ERPStack builds the edtech ERP on LTI 1.3, OneRoster 1.2 and the Ed-Fi Data Standard, because those are the contracts a district already runs, and a bespoke REST API is the one thing a procurement office will refuse.
LTI 1.3 launch, OneRoster 1.2 rostering
LTI 1.3 retired the LTI 1.1 shared secret for the 1EdTech Security Framework — OAuth 2.0, OpenID Connect and a signed JWT — so an edtech tool is now an identity relying party, not a form post. ERPStack ships all three LTI Advantage services: Names and Role Provisioning 2.0 for the roster, Assignment and Grade Services 2.0 for score passback, Deep Linking 2.0 for placement. Rostering runs beside it on OneRoster 1.2 in both the REST and CSV bindings, because a large district hands you a nightly file and a small one hands you an API key. SSO arrives through the same OAuth flow rather than a per-district password table.
The August problem, solved in the schema
Rostering breaks in August. Districts renumber sections, teachers move, the student information system re-issues keys, and an edtech ERP that upserts on a natural key orphans a term of coursework. ERPStack keys every OneRoster record on its sourcedId inside a district tenant, applies Idempotency in API Design per sync run, and validates each payload with Zod before it reaches Postgres. PostgreSQL holds the record of record under Drizzle ORM migrations; the district boundary is Multi-tenant Architecture enforced by RBAC and a Row-Level Security policy, not a WHERE clause a developer might forget. Sentry traces a failed sync back to the district that sent it.
// Drizzle ORM on PostgreSQL — OneRoster 1.2 enrolment, tenant-scoped
export const enrolments = pgTable('enrolments', {
districtId: uuid('district_id').notNull(), // RLS tenant key
sourcedId: text('sourced_id').notNull(), // OneRoster identity
classSourcedId: text('class_sourced_id').notNull(),
role: text('role').notNull(), // student | teacher
schoolYear: text('school_year').notNull(), // survives August
retainUntil: timestamp('retain_until'), // COPPA 312.10 clock
}, t => [primaryKey({ columns: [t.districtId, t.sourcedId] })]);Learning telemetry is not a student record
Caliper Analytics 1.2 and xAPI — IEEE 9274.1.1-2023, with its Learning Record Store — emit thousands of events per learner per week. They belong in a ClickHouse Analytics Database or TimescaleDB, never in the education records tables, because a clickstream write and a transcript write are opposite access patterns. ERPStack moves them as Event-Driven Architecture messages on Apache Kafka, keeps assessment items in QTI 3.0, issues credentials as Open Badges 3.0 and Comprehensive Learner Record 2.0, and displaces an incumbent Blackboard, Moodle, Salesforce or Zoho Creator build with the Strangler Fig Migration Pattern: rostering first, gradebook last. The Next.js, React and TypeScript front end ships to AWS or Vercel from GitHub Actions.
Our Solutions
- LTI 1.3 tool with Names and Role Provisioning 2.0, Assignment and Grade Services 2.0 and Deep Linking 2.0 over OAuth and JWT
- OneRoster 1.2 REST and CSV ingest keyed on sourcedId, idempotent per run, in PostgreSQL with Drizzle ORM
- FERPA school-official boundary as per-district RBAC and Row-Level Security, with an Immutable Audit Trail
- Caliper Analytics 1.2 and xAPI events on Apache Kafka into a ClickHouse Analytics Database or TimescaleDB
- Retention and deletion clocks inside the edtech ERP that execute the written COPPA policy on live tables
- Next.js, React and TypeScript portals at WCAG 2.2 AA, deployed to AWS or Vercel with Terraform
Compliance & Security
In edtech the audit is a contract, signed district by district before any code runs. FERPA Education Compliance is the school official exception, and the whole PostgreSQL schema follows from it.
34 CFR §99.31(a)(1)(i)(B) is a schema constraint
An edtech vendor touches education records only as a school official: performing a service the institution would otherwise staff, under its direct control for use and maintenance, bound by §99.33(a) on redisclosure. §99.7(a)(3)(iii) makes the district publish criteria for legitimate educational interest; §99.32 makes it log every disclosure. ERPStack ships that as multi-tenant Row-Level Security in PostgreSQL, an Immutable Audit Trail, RBAC per district and short-lived JWT sessions in Redis — purpose limitation you can query.The amended COPPA Rule and the 22 April 2026 clock
The FTC’s amended Rule at 16 CFR Part 312 (90 FR 16918) took effect 23 June 2025; compliance fell due 22 April 2026. Three changes land in the edtech schema: §312.5(a)(2) demands separate verifiable parental consent before third-party disclosure; §312.8(b) a written information security program with a named coordinator and annual risk assessments; §312.10 bans indefinite retention. Biometric identifiers are now personal information, so a proctoring feature’s voiceprints are in scope. Selling into the EU adds GDPR Article 8 — lawful at 16, never below 13. ERPStack encodes each as a Zod-validated Postgres column.One product, four hundred signed agreements
The contract an edtech vendor signs is the Student Data Privacy Consortium’s National Data Privacy Agreement — v2 in April 2024, v2.2 on 19 November 2025, built by 28 state Alliances, more than 275,000 executed since 2016. New York Education Law §2-d adds a Parents’ Bill of Rights and a data security and privacy plan, with penalties of $1,000, $5,000 and $10,000 by offence; California SOPIPA (Business and Professions Code §22584) bans targeted advertising, profile-building and sale of pupil data. ERPStack ships that as a per-district policy table in PostgreSQL, enforced in the API.The accessibility gate moved — twice
The Department of Justice ADA Title II web rule (89 FR 31320) adopts WCAG 2.1 Level AA for public schools and universities. An interim final rule at 91 FR 20902, effective 20 April 2026, pushed compliance from 24 April 2026 to 26 April 2027 for entities serving 50,000 or more, and to 26 April 2028 for smaller entities and special district governments. Procurement still asks for WCAG 2.2 AA — the 12 December 2024 Recommendation adding 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 and 3.3.8 and retiring 4.1.1. ERPStack builds Next.js, React and TypeScript portals to 2.2 AA, tests them with Playwright in CI/CD Deployment Pipelines, and delivers the Section 508 report.
Standards we engineer to
- FERPA (34 CFR Part 99)
- COPPA Rule (16 CFR Part 312)
- PPRA (20 U.S.C. 1232h)
- NY Education Law 2-d
- SOPIPA (Cal. B&P Code 22584)
- WCAG 2.2 AA / Section 508
- GDPR Article 8
- SOC 2
Get the Blueprint
Download our comprehensive Systems Architecture Blueprint to see how we architect compliant solutions.
Download BlueprintMetrics & Integrations
Illustrative engineering targets for this sector — the SLAs and capacities we design and build toward, not a live service dashboard.
OneRoster 1.2 resync into PostgreSQL, 50k users
LTI 1.3 launch to first byte on Vercel
Caliper 1.2 events onto Apache Kafka
COPPA retention purge across tenants
Integration: LTI 1.3 / LTI Advantage
Integration: OneRoster 1.2
Integration: Ed-Fi Data Standard v6.1
Integration: Caliper Analytics 1.2
Integration: xAPI (IEEE 9274.1.1-2023)
Integration: QTI 3.0
Implementation Process
FERPA and NDPA data map
A Schedule of Data listing every student field the edtech ERP touches, district by district.
Rostering contract
OneRoster 1.2 REST and CSV ingest keyed on sourcedId, idempotent per sync, landed in PostgreSQL.
LTI 1.3 conformance
LTI Advantage build-out over OAuth and JWT: rosters, grade passback and Deep Linking 2.0.
Telemetry plane
Caliper 1.2 and xAPI statements onto Apache Kafka; the education records stay in PostgreSQL.
Accessibility conformance report
WCAG 2.2 AA audit of the Next.js portal, producing the Section 508 report procurement reads.
Retention and deletion engine
Per-district COPPA 312.10 clocks executed by a Node.js worker against live tables.
Frequently Asked Questions
The FERPA school official exception, 34 CFR 99.31(a)(1)(i)(B). An edtech vendor may hold education records only while it performs a service the institution would otherwise staff, stays under that institution's direct control over the use and maintenance of those records, and honours 99.33(a) on redisclosure. ERPStack enforces the boundary as per-district RBAC and Row-Level Security in PostgreSQL.
The FTC's amended COPPA Rule (16 CFR Part 312, 90 FR 16918) took effect on 23 June 2025, with compliance due 22 April 2026. For an edtech product that is three build items: separate verifiable parental consent before third-party disclosure under 312.5(a)(2), a written information security program with a named coordinator under 312.8(b), and a published retention policy under 312.10, which ERPStack implements as a retention clock column in the education technology platform's PostgreSQL schema.
In practice yes, though not from scratch. Most US districts contract on the National Data Privacy Agreement from the Student Data Privacy Consortium: v2 in April 2024, v2.2 on 19 November 2025, built across 28 state Alliances, with more than 275,000 executed since 2016. The real cost to an education technology vendor is the Schedule of Data, which must list every student field the PostgreSQL schema touches.
Yes, and it stops being optional quickly. LTI 1.3 replaces the LTI 1.1 shared secret with OAuth 2.0, OpenID Connect and a signed JWT, and only LTI 1.3 unlocks LTI Advantage: Names and Role Provisioning 2.0, Assignment and Grade Services 2.0, Deep Linking 2.0. Every education technology feature that reads a roster or writes a grade rides those services, and SSO arrives with them.
Because August is when identifiers move. Districts renumber sections, reassign teachers and let the student information system re-issue keys, so an edtech ERP that upserts on a natural key orphans a term of coursework. ERPStack keys OneRoster 1.2 records on sourcedId inside a district tenant in PostgreSQL and makes each sync idempotent, so a replayed CSV file or REST run is a no-op — the one rostering rule an education technology build cannot skip.
Often you should. If the workflow is coursework, discussion and grading, a plugin inherits the platform's LTI 1.3 certification and costs far less than custom ERP development. A custom edtech build earns its place when the differentiating object is not a course at all: a state reporting pipeline, a multi-district assessment bank in QTI 3.0, a credential ledger in Open Badges 3.0. Those bend an LMS data model until it breaks, and that is where a custom education technology build pays.
The rule says 2.1; procurement asks for 2.2. The Department of Justice ADA Title II web rule (89 FR 31320) adopts WCAG 2.1 Level AA, and an interim final rule at 91 FR 20902 moved compliance to 26 April 2027 for public entities serving 50,000 or more and 26 April 2028 for the rest. ERPStack still tests Next.js and React education technology portals with Playwright against WCAG 2.2 AA, published 12 December 2024.
Only inside the same legal frame as any other subprocessor. Sending education records to an external model is a disclosure: it has to sit under the FERPA school official exception with direct control retained, satisfy the COPPA 312.8(c) written assurances, and appear in the district's NDPA Schedule of Data. An edtech platform therefore needs a per-district switch, zero-retention model terms, and an Immutable Audit Trail of every prompt that carried student data.
Not in the records tables. Caliper Analytics 1.2 and xAPI (IEEE 9274.1.1-2023) statements land thousands of times per learner per week, and mixing that clickstream with transcript writes is why edtech reporting crawls. ERPStack streams them as Apache Kafka events into a ClickHouse Analytics Database or TimescaleDB, and keeps the education records in PostgreSQL under their own retention clock.
For recruitment and advancement, usually enough. Salesforce and Microsoft Dynamics 365 model the constituent lifecycle well, and ripping out a working CRM is rarely the win. The gap opens at institutional reporting — IPEDS under 20 U.S.C. 1094 and 34 CFR 668.14(b)(19), Clery Act statistics under 20 U.S.C. 1092(f), multi-term tuition recognition — where a custom education data layer in PostgreSQL beside the CRM beats bending the CRM.