skip to content

04 · the writing is the sample

Technical writing

Documentation people actually follow, working notes worth citing, product copy that respects the reader. Written by someone who builds the systems being described — which is why it's accurate.

every line of copy on this site is the sample — including this one · scroll — the instrument is live ↓

the instrument — the copy edits itself — the redline, performed

the editing method, live

the edit, performed live


Weleveragebest-in-classsynergiestoholisticallyempoweryourdigitaltransformationjourney.

We fix what's broken, and prove it.

the work — manifest

  • w-01

    Developer docs, runbooks, and handovers — the kind a stranger can execute at 2am.

  • w-02

    Long-form technical content for companies that want authority without ghostwritten mush.

  • w-03

    Copy for technical products: precise, unhyped, conversion-aware.

  • w-04

    Machine-legible writing: content structured so answer engines cite it, not just crawl it.

how it's different


  • Every case study, note, and doc on this site is the writing sample.

  • I've read the code, so the prose doesn't lie.

  • The self-redlining instrument below is the editing philosophy, performed.

method — how it runs

01

read the source

code, configs, and commits before interviews. Accuracy comes from the system, not from what people remember about it.

02

write for the 2am reader

every runbook is tested against the person executing it under pressure, alone, without you on call.

03

cut until it's load-bearing

if a sentence isn't doing work, it goes. The redline instrument on this page is the method, live.

manifest — what lands on your desk

jm/technical·04

  • 01

    docs and runbooks a stranger can execute

  • 02

    long-form pieces with sources, not vibes

  • 03

    product copy that converts without embarrassing you

  • 04

    structure that machines can cite — headings, anchors, schema

signed — one operator, no handoffs

04 items

engagement — the terms

Per-piece or retained. Source access preferred — accuracy beats interviews.

proof — on the record

this site's copy

live

every page, panel, and label — written as the sample it claims to be.

field notes

on record

the writing practice in public — restarted clean, written slow.

read them

asked straight — answered straight

01What kind of writing is this?

Arguments with the reasoning shown: the protocol layer, AI citation mechanics, schema reality versus schema theatre, where the industry is fooling itself. Not listicles, not reheated news. Thirty-one pieces are live on this site as recordings — several in my own voice.

02Do you ghost-write for founders and teams?

Where the thinking is genuinely yours, yes — my job is the rigour: sourcing, checking, and building the argument so it survives contact with an expert reader. I don't manufacture opinions to order.

03Why does writing sit next to the engineering disciplines?

Because writing something down forces a rigour that talking doesn't — you cannot hand-wave in public. Clients get the same benefit: the reasoning behind every technical decision, written down, becomes an asset your team keeps using after the engagement ends.

04Do you write documentation?

The kind that survives the author leaving: runbooks, handovers, decision records. This site's own build is documented that way — it's how one person ships systems without a bus-factor problem.