Building tools people can run without me

The through-line of everything I have built in the last few years is a constraint most developers treat as someone else's problem: the client has to be able to run this without me. Not a support contract. Actually run it. That single requirement changes how you design everything upstream of it.

The problem

A nonprofit or a civic project needs a tool. A benefits calculator, a research environment, a website they can update themselves. They have a real need and a small budget, and they have usually been burned once already by a build that shipped, worked for a while, and then quietly became unmaintainable the moment the developer moved on. The software outlived the relationship and nobody left could change it.

So the brief is never just make the thing work. It is make the thing work, and make it survivable, on a budget that assumes I will not be here next year.

How I work it

Every project starts from the hand-off, not the launch. I build CMS-backed sites and tools designed for non-technical people to operate themselves, and I design the whole stack around what happens after I leave rather than around what is fastest for me to ship. That constraint drives real architectural decisions. My own site, for example, runs on a local-first deploy that consumes zero continuous-integration build minutes, because a build pipeline nobody is paying for is a bill and a failure point waiting to land on someone who cannot fix it.

The work spans further than one stack on purpose. I have built an AI platform that reads resumes with language models and regenerates tailored ones, a multi-agent automation system where AI agents hand tasks to each other through workflow orchestration, a headless-browser pipeline that searches transcripts, pulls timestamps, and cuts video clips while archiving the metadata in a database, and localized automation running on Raspberry Pi and ESP32 microcontrollers. When a records question needed answering, I filed Freedom of Information requests with the city and analyzed what came back. When public data was locked in filings, I built pipelines that parse IRS and campaign-finance records into datasets a person can actually query.

That last one is worth sitting on. A forensic research environment that tracks entities, evidence, and the relationships between them, built to turn scattered public records into something you can investigate, is the same job I did at a bank fifteen years ago, following a fraud through the evidence. The tools got enormously more powerful. The instinct is identical.

To make sure the self-taught stack was not just self-assessed, I put it against outside standards and completed Meta's certifications across front-end, back-end, digital marketing, and version control. Not because a certificate builds anything, but because I would rather have my range verified than assumed.

What it comes down to

The measure I care about is whether the client is still using the thing, unassisted, a year later. That is a harder target than a clean launch, and it is the one that reflects whether the work was actually good. Anyone can ship. Building something a non-expert still owns and runs long after you have moved on is the skill that took twelve years to develop, and it is the one I am still sharpening.