Work¶

I'm the technical writer at Apteco, where I look after the Apteco Help Hub: documentation for four products in a marketing data platform, plus admin guides, release notes, and technical updates. My readers range from marketers building their first audience to IT admins upgrading a production server.

What I built in 2026¶

At the start of the year our docs lived in six separate MadCap Flare projects. By the end of it, they were one docs-as-code site, run by a team of one.

Moving to docs-as-code¶

I planned and ran the move of about 950 pages from six Flare projects to one site built with Markdown, Git, and Zensical. It launched in August 2026, and it felt like a fresh start.

• Publishing went from 7 or 8 minutes to about one.
• Readers search every product from one place, instead of picking the right help site first.
• Old links still work: the site has about 3,000 redirect rules, audited before and after launch.

A docs program, not just a docs site¶

• Docs work moved into Azure DevOps. We used to track docs in Notion. Now it sits in Azure DevOps with the developers' and product managers' work, so docs are visible in the same place as the features they describe, and it's easier for anyone to raise or follow a docs task.
• Analytics and feedback, for the first time. Traffic analytics, search tracking, and on-page feedback, plus a monthly report that uses them to decide what to work on next.
• Release notes every two weeks, drafted alongside development, so they're ready on release day.
• A security advisory process for publishing advisories on the Help Hub.
• Room to grow. The workflow is set up so more people can contribute directly as the docs grow. Developers and the technical teams already see docs work happening alongside theirs, and want to get involved.

A quality system that works for one writer¶

Content from six projects had to read as if one person wrote it, and stay that way with changes going out all the time. A house style guide sets the rules, Vale checks them with 16 custom rules I wrote, the checks run every time a page is edited, and an AI review agent checks each change and builds the site before a pull request.

Working as a team of one¶

When my colleague left at the start of 2026, I became Apteco's only technical writer. I decided it was the right time to move the docs to docs-as-code, and I was given the freedom to make that call.

That decision has paid off. Automating a lot of the routine checking meant I could run the migration and keep up with the day-to-day work at the same time, with more of my time going on the writing and the decisions that need a person. Alongside the migration, I merged 278 pull requests between February and November.

Case studies¶

• Migrating to docs-as-code: how I moved 950 pages from six Flare projects to one site on my own, and what I'd do differently
• Docs quality system: the style guide, automated checks, and review workflow behind every change

Things I've built and set up¶

The tooling around the docs is as much a part of the job as the pages.

• Docs for AI readers. I set up the Help Hub to publish an llms.txt index and a Markdown copy of every page, so AI assistants can read the docs as easily as people can.
• Custom code blocks for Apteco's expression language. I built a syntax highlighter (a Pygments lexer) with colours that match the expression editor in FastStats, and code blocks that show the language name in their title, so readers know what they're looking at.
• A "Copy page" menu, extended from the theme's copy button, that copies any page as Markdown, ready to paste into an AI assistant.
• Claude Code skills and agents for repeat work: drafting release notes and patch notes, drafting new pages to a consistent structure, reviewing changes against the house style, and writing a weekly docs update for the company.
• Social cards so shared Help Hub links get a proper preview, and build-time image compression.
• A winter snowfall effect in the Help Hub header, because docs can be fun too.

How I work¶

I use Claude Code every day, mostly to build things around the writing rather than to write for me: skills for repeat work, hooks that lint every edit as it happens, and review agents that check changes before anyone else sees them.

I keep a human in the loop for every page. An AI can check a sentence against a rule, but it can't care whether the page means the right thing to the person reading it.

Writing samples¶

Live pages I wrote on the Help Hub. They may have changed since.

• Troubleshooting dashboards: organised by symptom, not feature, with who can make each fix. It came out of an audit of about 50 dashboard pages.
• Combine audiences: a concept-and-task page that explains the key decision (Selector or Array) before the steps.
• ASP.NET Core 10 requirement: a change notice for IT admins, drafted months ahead and reviewed with the CTO.
• Orbit release notes: every two weeks, leading with what users can now do.

Work history¶