When we tell people that EdTrust runs on school data, the immediate reaction is usually about security: encryption, certifications, where the servers are. Those things matter. But schools have a second set of requirements that most software vendors miss.
It's the data of children
That should be the start and end of the conversation. Children can't meaningfully consent to data processing, so the responsibility falls entirely on us, and on the schools that act as data controllers. We design every feature with that asymmetry in mind. If we're not sure whether to log something, we don't.
It's also the data of families
A grade is a piece of information about a student. A parent message is a piece of information about a family. The difference matters: a single parent might react very differently to a low grade than two parents reading it together. Our messaging tools are built for that nuance, for example, separating routine notifications from sensitive updates that should land in the right channel.
It's seasonal
September spikes. December lulls. June explodes. School software has a workload pattern that nothing in the consumer world matches. Designing for that means thinking carefully about cost, reliability, and how to keep things fast for teachers during the worst week of the year.
It can't disappear
When a school stops using a software product, the data shouldn't vanish, it has to go somewhere the school can keep it, in formats they actually understand. Export tools that produce 400-MB ZIPs full of UUIDs aren't real exports. We treat graceful exit as a feature.
It's regulated locally
Tunisia's regulations aren't Kenya's. Kenya's aren't Europe's. Building one platform for many countries means accepting that compliance is plural, not singular, and putting the configuration in the hands of the schools who know their context best.
Engineering for schools is humbling. The constraints are tighter, the stakes are higher, and the tolerance for "move fast and break things" is rightly zero. We wouldn't have it any other way.