Technical Writing and Documentation Engineering Services

01

Technical Writing

Working closely with the devs, engineers, and users, I build documentation that fits your product. As I work in the code base myself, our review process is easily handled through pull requests and git updates. This process gives peace of mind that the final product is accurate and up to date.

• Installation and setup guides
• Configuration and upgrade manuals
• Tutorials, training, and onboarding materials
• Release Notes and Changelogs
• API Reference material
• Internal handbooks and style guides

More on API reference writing →

02

Documentation Sites

I build static documentation websites, which are lightweight and load fast, include search engines and are small enough to host and run cheaply. Documentation is written as code in AsciiDoc or Markdown, then versioning and updates are managed in Git.

• Antora for larger projects, spanning many repos and requiring multiple versions
• Where the project is lighter, we can simply use a lighter generator, usually Docusaurus
• UX theming can be updated to match your product.
• Search inbuilt using existing Antora and Docusaurus systems

More on Antora and Docusaurus sites →

03

Docs-as-code Pipelines

Using the generators and code repository CI/CD, I build a self-updating website creation pipeline. The site rebuilds and updates when you merge to the correct branch, with review steps and preview sites being used to check content.

• CI/CD from GitHub, GitLab, or Bitbucket
• Can also implement build pipelines using Jenkins
• UI and UX design implemented during this process. The same system enables quick and simple UI updates
• Preview site to review content before publishing to customer
• Release versioned sites, easily achieved with release tags

More on docs-as-code CI/CD pipelines →

04

Migration and audit

Assessing existing document structure and overseeing moving to a more suitable solution. Audit existing material on a content and structural level to analyse existing weaknesses.

• Confluence, Notion, or other wikis to AsciiDoc or Markdown
• Inventory content for what is missing, cull what is duplicated or outdated
• Oversee all aspects of the migration, including redirects of old URLs, and notifications to clients
• Audit takes a maximum of one week, with a priority plan to ensure it runs smoothly

More on Confluence to AsciiDoc migration →

What are your project timelines?

I set an audit at a week. From there, it depends on the size of the project and needs. Depending on your needs it can vary from 1-2 weeks for a manual, to 3-4 months for a revamped self-publishing pipeline and migration.

Can you work within our existing code review process?

The key to good docs-as-code is to fit neatly into your existing development and DevOps system. I prioritise this methodology, and work within whichever systems you are currently running.

What time zones do you cover?

I am open to any distance, and would be interested in calls from clients worldwide. We can arrange overlap windows to stay in contact, and synchronise our work.

Can you work with our existing toolchain?

More often than not, my static sites can run in any standard git repo environment. I seek to fit my contributions in rather than replace a whole toolchain, where possible.

What if we have no docs at all?

Then I can easily set up the skeleton with no need to worry about conflicts within your system. I can also give you my advised strategy at audit with complete confidence.

Can you give us a style guide?

I have written many style guides designed for both devs and PMs to be able to follow. I can also create templates as starting points for new projects, giving confidence in new documentation after I leave.

How do you handle versioning and releases?

Antora sites have an inbuilt process for including a version switcher. Release notes are standardised and planned, so they can fit the same process as all other docs.