We spent this weekend in Orlando at FETC (Future of Education Technology Conference), one of the largest gatherings of ed-tech vendors in the country.
However, our mission wasn’t to buy software. Instead, it was to tear it apart.
At Bledsoe Labs, we are obsessed with “friction removal.” Consequently, whether we are building for co-parents using Custodyo or business clients at Carl’s Consulting Agency, our goal is always the same: build systems that work when people are stressed, tired, and in a hurry.
There is no environment more stressful than a school emergency. Therefore, we walked the expo floor to answer one question: Is the current generation of school safety software actually helping, or is it just adding noise?
Here is what we found, and more importantly, how we think the industry needs to do better.
The Problem: Engineering for the "Best Day"
Walking the aisles at FETC, we saw incredible dashboards. Specifically, we saw “AI-powered threat detection,” complex incident command maps, and multi-layered reporting tools.
In a quiet, air-conditioned demo booth with perfect Wi-Fi, these tools look amazing.
But as operators, we know that software never runs in a vacuum. Designing for the “Best Day” (perfect signal, calm users, full battery) is easy. In reality, we need to build for the “Worst Day.”
Consider the failure points: What happens when the school Wi-Fi is overloaded? Furthermore, can a teacher actually navigate a three-step menu when their hands are shaking? Finally, does the system fail completely when the data connection drops?
How We Can Make It Better
Ultimately, we believe the next generation of safety software needs to move away from “feature density” and toward radical simplicity. Here are the engineering principles we would apply to fix this broken market:
1. Zero-Friction Activation
If a safety tool requires a login, a 2-factor code, and three clicks to send an alert, it is useless in a crisis. In our view, safety software interfaces should be as crude and reliable as a fire alarm handle. Big buttons. High contrast. Immediate action.
2. Privacy as a Safety Feature
we noticed a disturbing trend of vendors collecting vast amounts of student behavioral data to feed “predictive” algorithms. At Bledsoe Labs, we practice Data Minimization. After all, the safest data is the data you don’t collect. Safety software should focus on communication (connecting the right people instantly), not surveillance.
3. "Boring" Reliability
We saw a lot of tools relying on cutting-edge (and often unstable) tech. Yet, when safety is on the line, “boring” is a compliment. We need systems built on proven, redundant infrastructure that can route messages via SMS, data, or voice—thereby ensuring the message gets through even when the network is congested.
The Takeaway
We left Orlando with a lot of notes and a renewed validation of our own philosophy.
The industry doesn’t need more AI. Nor does it need more complex dashboards. Instead, it needs tools that respect the human element of a crisis. Ultimately, it requires technology that gets out of the way so the teachers and administrators can do their jobs.
We are going to keep watching this space. Because if the current vendors won’t build the practical, privacy-first solutions schools need, someone else will have to.
