How I Build

Thirty-plus years of infrastructure engineering taught me what careless changes do to live systems. So before AI wrote a line of code here, I wrote the rules it works under. Every project in the portfolio (SouthpawStrings, desk-engine, the AI Orchestrator and this site) is delivered the same way. AI agents, which are AI tools that can read and change code themselves, draft, investigate and write code quickly. I review, approve and take responsibility for every step that matters. These rules are written down inside each project’s code repository. That way every agent, and every future session, follows my rules instead of making up its own.

I write the documentation while the work happens, not afterwards. Every release gets a new version number and a changelog entry (a dated note of what changed). Each working session ends with a written checkpoint: what changed, what was decided and why, what is still open, and the exact next command. The next session, human or AI, picks up from there instead of guessing. Decisions are recorded with their reasons. Half the changelog entries in these repositories read like short write-ups of what went wrong and what I learned, because that is what they are.

Step by step

The same seven steps for every project

Websites, code libraries, the AI Orchestrator and the PowerShell automation all follow the same seven steps. The tools change with the technology. The order and the checks do not.

1 · DecideWrite down what, and whyWork starts as a written objective. Big choices get a decision record: the options I considered and why I picked one. Each project opens with an introduction that explains the problem before any technical detail.

2 · BuildAI agents follow written rulesEvery repository has its own rules for AI agents: the technology, where the key files live, and what must never be saved there. Automatic checks block risky commands. Before any code is uploaded, a scan checks it for passwords and keys. Uploading or publishing needs an explicit confirmation.

3 · ReviewEvery important change gets reviewedI review every change that matters. Where it matters most, the system enforces review instead of just expecting it. Changes to SouthpawStrings can’t join the main version of the code until an independent reviewer approves them. The AI Orchestrator has a separate AI review the work before a person decides.

4 · TestRun every automated checkBefore every release, the full set of checks runs, not just the tests near the change. They check the code for type and style errors, run the tests and build the app. Tests guard against problems that have happened before. On this site, for example, a test fails if a phone number or email address ever appears in a public page’s code.

5 · ReleaseNumbered, recorded, scriptedEach release gets a new version number in the standard major.minor.patch format, and a changelog entry sorted into Added, Fixed, Changed, Security and Removed. Projects that run as live services then go live only through their own deploy script, described below.

6 · VerifyCheck the live serviceAfter a release, the deploy script checks what is actually running: the exact build, whether the service is ready, and the version it reports. For this site it also loads every public page. If a check fails, the script says which one and how to undo the release.

7 · Hand over & learnLeave it ready for the next sessionEach session ends with a checkpoint in a fixed format: what changed, what was decided, what is blocked, what must not be saved to the repository, and the exact next commands. When something goes wrong, I write it up and turn the lesson into a standard.

How releases go live

Nothing goes live by hand

No hand-typed deploysScripts, or it didn’t shipEvery project that runs as a live service keeps its release steps as scripts in its repository. A build run by hand, or a command typed straight into the live system, counts as an incident waiting to happen. The rule exists because one did.

Stop when unsureUnsaved work blocks the buildBuild scripts refuse to run if any change has not been committed (saved in version control) and uploaded. The build server builds a saved version of the code. Anything unsaved would be quietly left out, so the release would look new but be out of date. Database changes take a backup first, check it, and refuse to run without one.

No accidentsPreview first, then a typed confirmationBy default, deploy scripts only show exactly what would change. Going ahead takes a typed confirmation word or a deliberate setting. A stray keypress or an automatic “y” can’t trigger it.

The code matches realityExact builds, recorded in gitEach release is recorded by its digest, a unique fingerprint of the exact build. That record lives in configuration files tracked in git (version control). Nobody patches the live system directly. So the repository always shows exactly what is running, and undoing a release means applying one file, chosen in advance.

Proof, not assumptionsCheck the result in detailA release finishing is not the same as a release working. The scripts check the version the live service reports, its health checks, and that it still refuses access when it should. If something fails, they say exactly what.

Tested, not assumedUndo plans get practisedWhen this site moved to version 1.0.0, I ended the switch-over by undoing it on the live site. The old site came back in one restart. Only then did I move forward for good. An undo plan that has never been tried is a hope, not a plan.

AI, in practice

AI drafts. A person decides.

I keep the AI side deliberately boring. Agents do the long, careful work: reading whole codebases, moving pages to new code, tracking down a timing fault in how the web server looked up network names. Every step that can’t be undone comes through me. Uploading code and deploying to the live service need explicit confirmation in the session. A scan for passwords and keys checks every upload, and scripts with built-in checks make the safe way the easy way. I don’t trust AI output until it has been checked, limited and tested in the real environment. That doubt is a working part of the process here, not a slogan.

The speed is real, but it comes from the discipline. It doesn’t replace it. I rebuilt this site for version 1.0.0 in a single working day: moving the content, the desktop-style interface, the packaging, and the step-by-step switch-over. That was possible because years of groundwork already existed. There were standards to follow, earlier projects to copy from, checkpoints to resume from, and an engineer who knew exactly what “done and verified” had to mean. The AI Orchestrator turns the same idea into a product: my approval steps and evidence records, built into software instead of relying on willpower.

When something breaks anyway, the lesson becomes a standard. An hour-long outage happened because the web server (nginx) looked up another service’s address only when it loaded its settings. That became a written pattern every web server setup here now follows. A build server quietly filling up with leftover build files became a “clean as you check” rule: every build script clears old files each time it checks for space. The process gains a new rule every time reality wins an argument.

Documentation

Written to an aviation standard

My technical documentation follows a house standard based on ASD-STE100 Simplified Technical English. This is the controlled, deliberately limited English the aerospace industry uses for aircraft maintenance manuals. Aviation writes instructions for people working under pressure, often in a second language, where a misread step has consequences. A tired engineer reading a runbook (a step-by-step guide to running a system) during an outage is the same kind of reader.

In practice that means short sentences, one instruction per sentence, the action word first, warnings before the step they apply to, and one word for one thing. I pair it with Orwell’s six rules for plain English. When the two disagree, the answer is simple. In anything that could destroy data or take a live service down, the strict rules win. Everywhere else, the clearer sentence wins.

The standard covers runbooks, system design documents and operating guides. Pages written for people, like this one, keep a human voice.

How the documentation is written

What stays private

Only reviewed material is public

Everything on this site has been reviewed for public release. The live services, source code, admin consoles, operating guides and deployment records are all private. Public pages contain no server names, network addresses, access details, operating commands or passwords. Each public document is checked for these before it is published. Operating documentation is private by default. The public summaries are written separately, not cut down from the private ones.