The thing that ends an edtech company usually isn't a competitor or a bad product. It's a lawyer. Pearson agreed to pay $18.2 million to settle a biometric privacy case in Illinois, over palm scans at its test centers and facial checks in its own remote-proctoring system, collected without the written consent the law requires. That number is the whole lesson. In this market the compliance posture isn't paperwork you do after the build, it's a load-bearing part of the build, and most how-to guides skip it entirely.
Edtech sits in the most aggressive corner of privacy law for two reasons that compound. You handle minors' data, and increasingly you handle biometrics, the webcam feeds and face checks that proctoring needs. Each one alone is heavily regulated. Together they're a category lawyers specifically watch. The moment your platform captures a student's face to verify a test, you've walked into a body of law with per-violation penalties large enough to be existential, and not knowing about it has never been a defense anyone won with.
Four laws, and what each one forces
Four bodies of law decide most of it, and you should know exactly what each one demands. Illinois' biometric act, BIPA, is the one with teeth: it requires written, informed consent before you collect a face or palm scan, and it's the law behind that Pearson settlement. GDPR governs anyone with European users, and its Article 22 is the one that reshapes your architecture, because you cannot make a consequential decision about a person on automated processing alone. An AI that flags a student for cheating with no human reviewing it is illegal there. COPPA governs data collected from children, which is most of your users, and it just got heavier: the FTC's amended COPPA rule took effect in June 2025 and its compliance deadline, April 22, 2026, has already passed. For the first time it sets mandatory retention limits, you can no longer hold a child's data indefinitely, and it requires separate parental consent before sharing that data with third parties. State student-data laws then layer more rules on top depending on where your users sit.
The law moves under you, in both directions
If the four laws were static you could comply once and move on, and they are not. BIPA is the clearest case. In 2023 the Illinois Supreme Court ruled in Cothron v. White Castle that a violation accrues on every single scan, not once per person, which put White Castle's theoretical exposure above seventeen billion dollars for time-clock fingerprints. The legislature then amended the act in August 2024 to cap repeated same-method collection at one recovery per person. So the pendulum swung hard both ways inside eighteen months, and here is the practical lesson: even after the cap, one to five thousand dollars per student across an edtech user base is still an existential number, and you cannot re-architect a platform every time a legislature moves. You build to the strictest plausible reading, once, and the amendments become someone else's emergency.
And if the penalties still feel theoretical, the enforcement record says otherwise. Epic Games paid $275 million for COPPA violations in Fortnite, the largest penalty ever obtained for breaking an FTC rule, and the record it beat was YouTube's $170 million, also for children's data. Nor is this history. With the amended rule in force, FTC leadership has said it is "willing and eager" to enforce it, at up to $53,088 per violation, counted per child and per day. And the first education-specific action of the new era has already landed: PlayOn Sports took a $1.1 million California privacy fine in March 2026 for sharing student data with advertising partners without proper consent. The regulators' message across all of it is consistent: collecting from kids without verifiable consent is the thing they make examples of, and edtech collects from kids as its core function.
It changes what you build, not just what you file
This isn't a checklist you run at the end, it decides the architecture. GDPR Article 22 is the reason the proctoring piece insists on a human in every consequential decision; that's not a nicety, it's how you stay legal. BIPA is the reason consent has to be explicit and logged before a single biometric is captured, not buried in a terms page nobody reads. COPPA and the state laws are why data minimization, collect the least you can and delete what you don't need, has to be an architectural default rather than a cleanup task. Build the platform without these in the foundation and retrofitting them later means tearing up the floor with users already on it.
Selling to schools adds a fifth body of law
Everything above assumes you sell to families. The moment a school or district signs the contract, the ground shifts again. Student records in a school relationship fall under FERPA, the federal education-records law, and a stack of state student-privacy statutes written specifically for vendors like you, many modeled on California's rule that student data can be used for the contracted educational purpose and nothing else. Consent works differently too: under the FTC's long-standing guidance a school can authorize collection on parents' behalf, but only for educational use inside that contract, which forecloses exactly the secondary uses, ads, profiling, product analytics beyond the service, that a consumer app might rely on.
The build consequence is that B2C and B2B2C are two different data architectures, not two lines on a pricing page. Who consents, what the data can touch, how long you may hold it, and who can demand deletion all change with the contract type. Deciding which market you serve is an architecture decision, and it's far cheaper to make it before the schema exists than after a district's counsel sends the questionnaire.
Accessibility is compliance too
There's a quieter piece that catches teams off guard, and it's accessibility. Section 508 and the ADA require that your content works with a screen reader, and for a math-heavy SAT platform that means the math itself has to be machine-readable, which is a real engineering constraint covered in the math-rendering layer of the build guide. An inaccessible platform isn't only bad practice, it's a complaint waiting to be filed, and it tends to arrive the same week as the others.
What's coming by 2028
This only gets heavier. As proctoring and biometric verification spread, regulators are paying more attention, not less, and the penalty examples keep getting larger. A wave of state age-verification and age-appropriate-design laws is rolling in behind the federal rules, each with its own definitions and duties, which mostly compounds the same architectural point: platforms that treated minors' data conservatively from the first commit keep absorbing new laws as configuration, and platforms that didn't keep rebuilding. By 2028 the platforms still standing won't be the ones that bolted compliance on after a scare, they'll be the ones that treated it as a first-class engineering concern from the first commit. The uncomfortable framing, and the accurate one, is that an edtech platform in 2026 is a data-compliance fortress that happens to teach, not a teaching tool that happens to hold data.
What 2muchcoffee covers
We build edtech with this posture from the start, the consent flows, the human-in-the-loop gates, the data-minimization defaults, because retrofitting them is how budgets and timelines die. If you're putting webcams or minors' data anywhere near your product, that's the conversation to have before the architecture sets, not after the demand letter. The plain way in is the AI work we do.
One concrete action
List every piece of data your platform collects about a student, and next to each row write why you need it and when you delete it. The rows where you can't answer both are your compliance risk, and there are almost always more of them than the team expected. This is one layer of building an SAT prep platform, and it's the one that quietly decides whether the company survives its own success.
