Why I Taught Myself to Build Software for a Treatment Campus

I am not a programmer. I want to say that first, because everything else in this piece depends on it

For years, the operational backbone of our campus was a stack of paper binders and a sprawl of spreadsheets. Schedules lived in one place, attendance in another, medication verification on a clipboard, housing assignments in someone’s head. Every one of those systems worked, more or less, as long as the right person was in the building. The trouble with a system that depends on the right person being in the building is that recovery does not pause when that person takes a day off.

I kept waiting for someone to solve it. Eventually I understood that in a field with thin margins and enormous demands, the tool I wanted was not coming. So I decided to specify it myself.

What I learned in the process is the reason I am writing this down.

The hard part was never the technology. The hard part was the thinking that has to happen before anyone writes a line of code.

To specify a system, you have to say exactly what your operation does - not what you tell people it does, and not what the policy manual claims. Who is allowed to see this? What happens when the answer is no? Which of these steps exists because it protects a client, and which exists only because someone did it that way years ago? I could not describe a workflow in software until I genuinely understood it, and there were more places than I care to admit where the honest answer was that our process had never been designed at all. It had accumulated.

That is the quiet gift of building the tool yourself. You cannot automate a mess. The act of specifying forces a clarity that operations meetings rarely produce.

The second thing I learned is that permissions are ethics written in a technical language. Deciding who can see which piece of a person’s clinical information is not an IT question. It is a question about dignity, and about federal law, and about what it feels like to be a client walking past a screen. Every rule I wrote came down to the same instinct that governs good clinical practice: give people exactly what they need to do their work, and not one thing more.

The third lesson was about failure. In most software, a small error is an annoyance. In a treatment setting, a screen that quietly fails to save a medication verification is not an annoyance - it is a gap in someone’s care that nobody notices until it matters. So the standard we built toward is simple to say and demanding to keep: nothing fails silently. If something breaks, it says so, loudly, to someone who can fix it. Every release gets verified against live data before and after it ships.

People sometimes ask what the payoff has been. The honest answer is not the dashboards, satisfying as they are. It is the hours. Time that used to go into reconciling binders now goes back to clients. Staff stopped being the system of record and went back to being clinicians. A peer leader can recognize someone’s progress in the moment instead of at the end of the week. Those are small things that compound, which is the only way anything durable gets built in this field.

I am aware of how this sounds coming from someone whose background is clinical and operational rather than technical. But AI-assisted tools have quietly moved the line of what an operator can build, and I think more of us in behavioral health should walk up to that line and look over it. Not because leaders should become engineers - I have no illusions there - but because nobody understands the workflow of a treatment campus better than the people running one. The judgment about what should be built is the part that cannot be outsourced. The building is increasingly the easy half.

I have said for years that structure is an act of compassion. It turns out that is as true in a database schema as it is in a treatment plan. The tools are just a way of making sure the care we intend is the care that actually happens - on the days the right person is in the building, and on the days they are not.