Technical writing & publishing

I write about systems I can actually understand.

I’m an engineer first. I can read the code, question the architecture, interview the people who built it, and write for the reader who was not in the room.

Discuss a writing project What I can deliver

What I can deliver

Technical depth without committee-written prose.

I can work from interviews, source code, product notes, public research, or a draft that is accurate but difficult to read.

Articles

Bylined or ghostwritten articles that explain the product without flattening the engineering behind it.

What I can deliver

Bylined or ghostwritten drafts
Research and source checking
Editing, metadata, and publication

Documentation

Product and developer documentation shaped around the task, not the internal structure of the company.

What I can deliver

Getting-started and concept guides
API and integration documentation
Information architecture and maintenance

Technical reports

A clear, sourced account of a system, market, risk, or technical decision for the people responsible for acting on it.

What I can deliver

Research synthesis
Technical and product analysis
Decision-ready structure and diagrams

My approach

I do the technical homework before I write.

I begin by understanding what is true, what is still uncertain, and what the reader needs from the finished piece.

Read and ask

I review the code, documentation, research, and product history, then interview the people closest to the subject.

Find the argument

I agree the reader, the central claim, the level of detail, and the questions the piece must answer.

Write and challenge

I draft in a direct voice and take uncertain claims back to the people who can verify them.

Finish the publication

I prepare the final copy, diagrams, metadata, links, and CMS entry when publication is part of the brief.

Useful when

The team understands the subject. The reader does not—yet.

A product needs documentation before customers or developers can adopt it.
A technical team has expertise but no time to turn it into a strong article.
Research needs to become a report that a decision-maker can actually read.
An existing draft is accurate but needs structure, editing, and publication.

Practical guides

Before commissioning the work.

AEO, GEO, LLMO and ASO: an AI-search glossary

A sourced guide to the terms for generated-answer visibility, agent readiness, retrieval, and AI-search measurement.

Agentic Engine Optimization for technical documentation

My field note on source selection, answer structure, internal links, schema, llms.txt, and retrieval testing.

Technical writing fees

EUR starting points, representative project ranges, scope assumptions, and the work each engagement is designed to create.

How to hire a technical writer

A buyer’s test for technical depth, source handling, review, samples, and scope.

How technical digital PR earns links

A responsible framework for source assets, editorial outreach, sponsorship, and measurement.

FAQ

Questions about technical writing

Can you write from source code and technical interviews?

Yes. I can work from repositories, product documentation, research, and interviews with the people closest to the system.

Can you handle publication as well as writing?

Yes. The final delivery can include diagrams, metadata, internal links, CMS entry, documentation structure, and publication checks when access is available.

Can you edit an existing technical draft?

Yes. I can restructure, fact-check, tighten, and prepare an existing draft without erasing the author’s knowledge or voice.

Have something difficult to explain?

Send me the material and tell me who needs to understand it.

Discuss a writing project