Complex software, made learnable.

When we moved from Mend to Arnica, the SBOM data came out with gaps in it. That mattered, because an incomplete bill of materials makes it harder to sign off on what's in the software. Filling the gaps by hand was slow, repetitive work, and the kind where small mistakes are easy to miss.

Build something that fills the gaps from the original package sources, is upfront about what it can't find, keeps proprietary code separate from third-party dependencies, and produces documentation an auditor can work from — without anyone having to redo the same judgement calls every cycle.

• Pulled component data straight from npm and Maven instead of trusting one incomplete export.
• Flagged anything it couldn't determine rather than guessing, so gaps stayed visible instead of getting papered over.
• Separated proprietary software from third-party dependencies so each one got handled properly.
• Generated branded Word and PDF outputs, so the result was ready to hand over rather than raw data someone had to tidy up.
• Saved reviewers' corrections to JSON and reused them next time, so the tool remembered decisions instead of asking again.
• Gave it a GUI so people who don't code could run it. I built the whole thing AI-first.

• About eight hours of manual work gone from every SBOM cycle.
• More consistent data feeding into compliance and security work.
• Review knowledge that lived in the tool instead of one person's head.
• Fewer of the small human errors that get expensive in an audit.

Python · npm & Maven ecosystem data · JSON · Word & PDF generation · GUI · AI-assisted development · SBOM / SCA (Arnica)

A recurring documentation job was being done by hand. It was slow, repetitive, easy to do inconsistently, and it only really worked when the one person who knew the steps was around.

Automate the repetitive part, then make it something people would use rather than a script that sits ignored because it's a pain to run.

• Automated the manual documentation work end to end.
• The tool worked; the problem was getting people to use it. So I used AI to build a GUI that lowered the effort of running it.
• Kept refining the usability until it was easy to pick up and hard to get wrong.

• A lot less repetitive work.
• A process people actually adopted, and one that didn't hang on a single person's memory.

Workflow automation · GUI built using AI · usability iteration

Updating versioned documentation meant a long run of mechanical work — finding affected topics, wrapping and conditionally tagging content, building outputs, generating a review PDF — repeated for every change. It was slow and repetitive, and the kind of slip it invites — a mis-scoped tag, a still-valid passage dropped from an older version — is a quiet one. Nothing flags it, so catching it depends entirely on careful review.

Automate the mechanical half without automating the judgement. Speed the work up, but keep every decision that affects what a customer sees — scope, version applicability, what to preserve, whether it's accurate, whether it's ready to publish — as a specialist human call.

• Split the work in two: the repetitive production (tagging, edits, builds, the review PDF) got automated; the judgement (what changes, whether it's right, what to keep for older versions) stayed human.
• Designed a reusable prompt architecture — an invariant preamble holding the tagging rules, plus a per-change schema (Locate / Preserve / Tag / Insert / Verify) that carries the decisions that can't be reused.
• Set the AI to escalate, not assume: if anything's uncertain it asks before acting, rather than confidently guessing.
• Built the guardrails from failure-mode analysis — mapped how the AI produces confidently-wrong output and added a specific control for each: preserve-don't-delete, validate in both version contexts, accuracy-check against the source, verify scope rather than accept it.
• Made every change produce a scoped PDF of only the changed pages, so review is quick and the change is auditable by the rest of the team.

• Roughly half the hands-on effort gone per update — a change that took about four hours now takes about two.
• The quality controls held: the speed came out of the mechanical work, not the review.
• A reusable system rather than a one-off, so it pays back on every future change of this type.

MadCap Flare · conditional content / versioning · prompt architecture · human-in-the-loop review · GitHub Copilot (VS Code Agent Mode) · Atlassian Rovo

PCI SSF certification calls for a full set of documentation covering how a product is built, secured, and maintained. The documentation needed to be complete, accurate, and in a state an auditor could work through.

Produce and maintain that documentation set — working with product managers and technical teams to get the detail right, and with auditors to make sure it covered what they needed.

• Worked with product managers and technical teams to understand how the product actually worked, and wrote it up accurately.
• Referred to the PCI SSF standards and supporting documentation to check what each document needed to cover.
• Produced a suite of around 50 documents covering all aspects of the product.
• Took documents through review with auditors and updated them in response to feedback.
• Repeated the process for other products in our area.

• A complete, audit-ready documentation set for each product.
• Documentation that stayed accurate as the products changed.
• An approach that carried over to the next product rather than starting from scratch.

PCI SSF · secure software documentation · audit support · working with product managers, technical teams, and auditors

Documentation was scattered and inconsistent. It was hard to version, hard to reuse, and copied across places that slowly drifted apart. Writing more pages wouldn't have fixed that — the setup itself was the problem.

Move the content onto a platform we could maintain, bring in conditional content and version management, and standardise how docs were structured and produced.

• Ran the Confluence migration and set up MadCap Flare for structured authoring.
• Set up conditional content so one source could produce different outputs for different audiences, rather than being copied and forked.
• Sorted out version management and standardised structure and style across the set.

• Consistent, reusable, version-controlled documentation.
• Less duplication, easier to maintain, and a system people could work in.

Confluence · MadCap Flare · conditional content / single-sourcing · version management

A new grocery order-management platform was changing how customer-service teams did their jobs. More than 500 colleagues needed to be able to use it from launch, and there was no training for it — none of it existed yet.

Learn a platform that was still being built, design the training for it, and get it to 500+ people in more than one country. I couldn't deliver all of that myself, so the trainers had to be able to.

• Worked with the software development team as the platform came together, so the training reflected how it actually behaved rather than how the spec said it would.
• Designed e-learning in Articulate Storyline, alongside classroom material, so each part was taught in the format that suited it.
• Built the training around what colleagues actually had to do in the role, rather than walking through the interface screen by screen.
• Ran train-the-trainer sessions so the people delivering it understood the platform well enough to handle questions, not just present the material.
• Worked with teams in Central Europe to adapt the customer-service and order-management training for the launch of a new call centre in Hungary.

• 500+ colleagues able to use the platform when it went live.
• Training that didn't depend on me being the one to deliver it.
• Material that carried over to another country's launch instead of being built again from scratch.

Articulate Storyline & 360 · e-learning & classroom design · train-the-trainer · multi-country rollout

Customer service managers were answering the same questions from scratch every time. The answers varied depending on who wrote them, the tone drifted, and writing each one took longer than it needed to.

Work out what customers were actually asking, and write a set of first-line responses that covered those queries consistently — accurate, in the right tone, and quick to use.

• Looked at what was actually coming in and grouped it into the queries that came up most, so the set covered real questions rather than assumed ones.
• Wrote around 200 templates covering those queries, in a consistent tone of voice.
• Structured them so they were quick to use but still left room to respond to the person asking, rather than sounding automated.
• Made sure the answers were accurate and stayed that way as things changed.

• Consistent answers across the team instead of variation from person to person.
• Faster contact handling, because the first-line answer was already written.
• A reference for what a good response looked like, useful for anyone new to the team.

Response design · tone of voice · content at scale · customer service operations

I document software for a living, and I wanted to know what building and shipping it actually feels like from the other side of the fence.

Design, build, and deploy a real-time multiplayer game on my own, and pick up real-time state, syncing, and what it takes to keep something live for other people.

• Built the game on Firebase for real-time backend state and hosted it on Netlify.
• Worked through the hard parts: multiplayer syncing, shared state, and keeping something running once real people could break it.

• A working multiplayer game that's live.
• A much better feel for the engineering I document and automate around, and easier conversations with engineers now that I've shipped something too.

JavaScript · Firebase · Netlify · real-time multiplayer