September 18, 2026

I had a behavior and IEP goal tracking app that worked. This week I found out what it was missing.

The gap between "it runs on my phone" and "someone else can depend on it" turned out to be about a day of focused work and thirteen bugs I did not know were there. That gap is the whole subject of this issue, because it is the same gap that sits between a district's promising AI pilot and a tool anybody trusts in October.

The app collects behavior and IEP goal data. Frequency counts, duration, latency, interval recording, the formats special education staff use every day and mostly still run on paper or on a clipboard app that was not built for it.

I built the first version because I needed it. It worked. I used it. So this week I sat down to answer a different question: what would it take to hand this to another teacher and not have to stand next to them?

Here is what that question found.

The bugs were not in the features. They were in the edges. The chart drew every data point as a separate series instead of one line, so a week of progress looked like confetti. The duration timer reset if you dismissed the sheet, which is exactly when a timer matters. CSV export wrote timestamps in UTC with no goal text attached, so the file was technically correct and practically unusable at an IEP meeting. Archived items could not be reopened. Behavior intervention markers existed in the data and could not be reached from the interface. Thirteen of these, none of them visible in the demo, all of them the kind of thing that makes someone quietly stop using a tool without ever filing a complaint.

Then the things that were missing entirely. Full JSON backup and restore, because data that lives in one place on one device is not data you can put in a legal document. Face ID and passcode lock, in its own window so it covers a presented sheet rather than sitting politely behind it. Undo and per-record delete, because everyone mis-taps during a session. Editing behaviors and goals after you create them, which sounds obvious and was not there.

And then proof. Thirty-four unit tests and a UI smoke test passing, zero code warnings, and a verified data migration from the prior build so nobody loses a month of collection when they update. That last one is the part that separates a project from a product. If updating the app costs a teacher their September data, the app is worse than paper.

The decision underneath all of it: I am selling this one. Paid up front, one price, no in-app purchases, no subscription, no ads inside a tool that holds student behavior data. That is a change from how I have described this business, and I want to name it rather than let it happen quietly. I have said Evalve is engagement work, not packaged software. This is one app, and it is a deliberate exception I am testing, not a pivot.

What I would take from this if I were running a district pilot. The feature list is the easy half. The half that decides whether the thing survives to spring is the boring half: what happens when someone taps the wrong button, what the export looks like when it lands in a meeting, and whether a person who did not build it can pick it up cold. Nobody schedules time for that. It is the entire difference between a pilot people talk about and a pilot people use.

One more thing, and it is the part I would rather skip. While that app got built, nothing shipped. No newsletter for three Fridays, no podcast for four weeks. Both jobs started, the mornings I used for this work disappeared, and the publishing stopped before I noticed it had. I am writing that here because a newsletter called Out Louder does not get to only report the good weeks.

OSSE Releases AI Model Policy to Guide Responsible Staff Use in Schools by the DC Office of the State Superintendent of Education

A model policy for staff AI use, built on a stoplight framework: where AI is off limits, where it needs oversight, where it is fine with human review. The red light list is the part worth reading closely. No AI grading, no AI in discipline, and no AI weighing in on IEP decisions for students with disabilities. It is guidance, not a mandate, which means districts get to adapt it, and I would rather adapt something specific than write from a blank page.

Teens in the AI Era: Schoolwork and Skills That Matter by Common Sense Media's Youth AI Safety Institute

A survey of more than 1,000 U.S. teenagers, August 2026. Seventy percent use AI for schoolwork. Thirty percent say a teacher has ever talked with them about using it safely. Set those two numbers next to each other and the policy conversation looks different: the students are not waiting for the adults to finish deliberating. If you are on a committee that meets monthly, this is your urgency argument.

What's Next in Special Education: What Every Educator Should Know for the Year Ahead by the Council for Exceptional Children

A field-level look at where special education is heading this year, including the shift from collecting data to using it well. I read it right after spending a day inside a data collection tool, and the two lined up. Most teams I talk with are not short on data. They are short on data in a shape anyone can act on before the next meeting.

Days 1 to 30 of the Evalve 30/60/90 AI Implementation Plan asks for one thing that almost nobody does: audit the invisible work your team already does, and write down the baseline time cost so day 90 has something to compare against.

Here is the smallest version of that. It takes two weeks and costs nothing.

Pick one recurring task that runs on paper or on a spreadsheet. Behavior data collection, progress monitoring notes, parent communication logs, service minute tracking. One task, one team, not the whole department.

For ten school days, have every person doing that task write down two numbers at the end of the day. Minutes spent on it, and the number of times they had to redo, recopy, or re-enter something. Two numbers. On a sticky note is fine. If you build a form for this, you have already made it too big and people will stop.

On day ten, add it up and compute three things. Total minutes across the team. Minutes per person per week. Percentage of that time that was re-entry rather than original work. That last number is usually the one that changes the conversation, because re-entry is pure loss and everyone recognizes it immediately.

Then write one sentence and put it somewhere you will find it in three months. "As of [date], this task costs us X minutes a week across Y people, and Z percent of that is re-entry." Date it. That sentence is your baseline.

Now you can evaluate anything. A vendor demo, a free tool, a thing I build for you, a workflow one of your teachers rigged up on their own. In ninety days you run the same count and compare. Not a vibe, not a testimonial from the one enthusiastic teacher, a number against a number.

I will tell you what usually happens, because it is the reason this exercise is worth the ten days. Teams find that the task they were about to buy software for is not the expensive one. The expensive one is two doors down and nobody had ever counted it.

If you want the full plan the baseline step comes from, it is here: Your First 90 Days of District AI.

That's it for this one. If something here was useful, share it with someone who'd get something out of it. If it wasn't, that's part of the deal too. You can find more of what I'm working on at evalveconsulting.com, or book a call if you want to talk through what you're dealing with.

Talk soon,

Chris