Evalve Out Louder

The newsletter sent itself two Fridays in a row, on its own, with nobody clicking anything. The same week, the job board drop sat finished and unsent on a Tuesday and told me nothing at all. I spent the week finding out why, and the answer was not in the part that does the work.

I built a toy cash register app for my daughter. Then I was scrolling the special education subreddit and found a transition teacher asking whether anyone knew of a banking and point-of-sale app his high school students could use to practice budgeting with real money skills. I had already built the thing he was describing, so I sent him the TestFlight code.

That is where this episode actually starts. Because the moment I sent it, I realized the app was the small part. What that teacher needed was a curriculum, and curriculum design is my own training: backwards design, the Indicator 13 transition standards, the DLM essential elements. So I built a four-year scope and sequence that moves students from support toward independence, and then past independence toward generalization and fluency, which is the part most transition planning skips. A student doing a task correctly in a classroom is not the same as a student handling a situation nobody planned for. The register app got rewritten as Evalve Point of Sale to anchor the whole thing.

This episode is also the most direct answer I have given to the question of why I build at all. I am not banking the business on app revenue and I do not have numbers saying anyone wants to buy these. I build because building is the work. Not a slide deck about the work, not a podcast about the work. The thing itself.

Listen on Spotify · Listen on Apple Podcasts · Every episode on the site

A summer of AI bans in schools by Anna Merod

The two largest districts in the country both restricted student AI use for this school year. New York City paused it for elementary and middle school, Los Angeles Unified restricted it for all students. Read past the headline to the part that matters: districts are not saying AI is worthless, they are saying they do not have the resources to implement it safely. That is a capacity problem wearing a policy costume, and capacity is fixable. Three in five teachers in this piece use AI on the job themselves while their students cannot.

Nation's Broadest Generative AI Moratorium in Schools by the New York City Mayor's Office

Go to the primary source on this one, because the carve-outs are the story. The moratorium covers roughly 600,000 students in grades 2-K through 8, and it explicitly exempts assistive technology for students with disabilities, multilingual learners, and career readiness programs. Teachers keep using AI for planning. So the most restrictive student AI policy in the country still protects access as an accommodation. If you work in special education, that exemption is the shape of every argument you are about to have.

Microsoft Report Highlights Trends in K-12 AI Adoption by Kellie Escoto

Vendor research, so weigh it accordingly, but one number in here is worth the read on its own: four in five school leaders say their AI guidance is clear, and only half of teachers and students agree. Seventy-seven percent of students and fifty-three percent of educators report no formal training. Leaders are not lying. They are reading their own guidance, which is a different act than trying to use it on a Tuesday. Go ask one teacher to find your AI guidance without help and time how long it takes.

Pick one automation you rely on, and break it on purpose.

I spent this week on a bug that was not really a bug. My publishing system sent the newsletter by itself two Fridays running. The same system let the job board drop sit unsent on its Tuesday, fully written, thumbnail and SEO and all, just never armed. Here is the part that cost me the week: nothing told me. The job crashed one line before the code that would have alerted me, so there was no send and no alert. From outside, a silent failure and a quiet success look identical.

So, the exercise. It takes about twenty minutes.

Pick the one automated thing you would be most annoyed to lose. The report that assembles itself. The reminder that goes out. The overnight sync. Now make it fail: rename the input file, revoke the credential, point it at a folder that does not exist, whatever the cheapest sabotage is.

Then answer three questions.

Did anything tell you? Not "is there a log." A log you have to remember to read is not a notification. Did a message reach you, on a surface you actually look at, without you going to look for it?

How long did it take? If you found out because you checked, write down the gap. That gap is your real exposure, and it is the number to shrink.

What did it say? "Error" is not useful. A good failure message names what broke and the next action. Mine now pages me with the draft id and the editor URL, so I can fix it from my phone.

Then put it back and fix what the test exposed. Usually it is one line: wrap the whole run in a catch-all, so any unexpected failure reaches you, not just the one you predicted.

Most of us build automation and then test whether it works. Almost nobody tests whether it can say so when it doesn't. That second test finds the failures you would otherwise hear about three weeks later, from a subscriber.

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