Building Regulated Software With ADHD: Why I Automate Everything

There's a version of ADHD that people think they understand, the one where you can't sit still, you chase shiny things, you're basically a golden retriever in human form. That version is, at best, incomplete, and at worst it's the reason people don't take you seriously when you tell them why you built an entire self-hosted CI pipeline just to stop yourself from pushing broken code at two in the morning.

I'm a solo developer building regulated software (medical billing, media audit compliance, news intelligence) and I'm also the former CISO of a national IT governance division, so I know what governance is supposed to look like. I'm also neurodivergent in ways that make traditional governance basically impossible to maintain through willpower alone.

The thing is, ADHD doesn't mean I can't focus, and that's genuinely the most misunderstood part. Once I'm in flow I can hyperfocus for hours. I'll look up and it's dark outside and I've forgotten to eat. The problem isn't focus, it's initiation. Starting is the hard part, not because the work is difficult or because I don't want to do it, but because the mechanism that translates "I should do this" into "I am now doing this" is unreliable. It's like having a car with a perfect engine and a starter motor that works maybe sixty percent of the time.

"Just sit down and work on it" is advice that neurotypical people give because for them it actually works. From my side, sitting down and working on it requires a chain of micro-decisions (open the right project, remember where I left off, recall which tests were failing, figure out what the next step is) and every one of those decisions is a potential point of failure. Not because they're hard, but because my brain will simply not do them. It'll do something else instead, something with a lower activation energy, and I won't even notice the switch happened until an hour later.

So I automated the decisions away. Every project runs in a containerised dev environment that's identical every time I open it, so I don't have to remember setup steps because there are no setup steps, a provisioning script handles it. The container mounts a shared knowledge volume so context from previous sessions is already there when I sit down, and convention documents get loaded automatically at the start of every Claude Code session, so even my AI tooling knows what it's supposed to be doing without me having to brief it.

In terms of governance, I run self-hosted git through Forgejo with CI enforcement that won't let me skip tests. This isn't because I'm disciplined, it's because I know with absolute certainty that at some point I'll be tired, or frustrated, or deep in a hyperfocus tunnel, and I'll convince myself that the tests can wait. They can't (this is regulated software) so the system doesn't ask me. It just fails the push. I've effectively removed my future self's ability to make that particular bad decision.

There's also a more practical reason: AI coding agents hallucinate, and they write some truly unbelievable spaghetti code when left unchecked. Having repeated, enforceable tests in CI is genuinely the only way to make sure the code actually works in production. It's enormously frustrating getting the agent to chase down errors, because each CI run takes minutes and you're just sitting there watching it, but those minutes save hours of debugging later on. The alternative is trusting that the AI got it right, and I've been burned on that enough times to know better.

The same logic applies everywhere. I have a fail-fast checker that catches diagnostic spirals before I disappear down a rabbit hole for three hours, and governance hooks that inject reminders automatically, because "I'll remember to do that later" is a lie my brain tells with enormous confidence and zero follow-through. Automated time tracking syncs to a GitHub gist so I don't have to remember to log hours (I definitely would not remember to log hours), and conversation snapshots persist context between Claude Code sessions, because context doesn't survive between sessions in my head.

Also worth saying: I self-host a Kanban tool called Fizzy, and one of its features that I rely on heavily is auto-postpone, where cards that go stale get surfaced again automatically. Without that, stale cards become invisible. They're still there, technically, but my brain stops seeing them. It's not that I've decided they're not important, they've just fallen below the threshold of what registers as real, and auto-postpone makes them real again.

I think people look at this kind of infrastructure and assume it's over-engineering. A solo developer with self-hosted git, CI gates, diagnostic spiral detection, automated state syncing, that's a lot of machinery for one person, and I'd probably agree if the machinery existed because I thought it was architecturally elegant. It doesn't. It exists because without it I can't reliably produce software that meets the standards I'm legally required to meet, and honestly, that I want to meet. I don't want to create a rubbish product. Every piece of automation removes one decision, one "I should remember to...", one moment where my brain could silently drop something critical.

There's another angle to it too: I want to think something through deeply, once, get it right, embed that discipline into the system, and then only have to revisit it when I get new information or my workflow genuinely needs to change. That's a lot of upfront work, but the long-term upside is enormous, because the alternative is making the same decision over and over again and hoping I make it correctly every time. I know how that ends for me.

The irony (and I genuinely do find this funny) is that my brain is quite good at designing systems like this. Architecture, structure, seeing how pieces fit together, thinking about failure modes: that's where ADHD gives me something back. I can hold complex systems in my head and reason about them in ways that feel almost effortless, whilst simultaneously being unable to remember to run the linter before I commit. So I built a system that plays to what my brain does well and compensates for what it doesn't.

This isn't a limitation story, although it might sound like one. It's a design story. The constraints made the system better, because I had to think about every point where a human (specifically, me) could fail, and the infrastructure ended up more resilient than anything I'd have built if I could just rely on discipline. Discipline is a finite resource even for neurotypical people, I just ran out of it faster, so I had to find something more sustainable earlier.

If you're a neurodivergent developer and any of this sounds familiar (the starting problem, the context evaporation, the quiet horror of realising you've been working on the wrong thing for an hour) I suppose what I'd want you to take from this is that the way your brain works isn't something you have to fight. You can design around it, and you can build systems that make the right thing the default thing so you don't have to rely on remembering to do it. That's not a workaround. That's just good engineering, applied to yourself.