No. 07 · Writer & Maker, Embedded in Tech Teams · Updated April 2026
Writing that actually understands what you built.
An extra set of brains for teams shipping complex products. I embed, read the docs, sit with the engineers, and come back with copy that sounds like someone who actually understood the thing — because the technical bits are usually the parts worth reading.
Case Nº 01 · Filed April 2025 · Cybersecurity · 3-week embed
The third-party script breach that shook the world.
What the brief asked for: a post-mortem. What the audience actually needed: a piece that could survive being forwarded to a hostile security researcher.
Client
Retained · anonymised
Role
Research · Interviews · Writing
Format
Long-form · 3,400 words
Language
English
§ 01 — The Problem
The team had seen too many tidy post-mortems that smoothed out the bits that mattered. They needed a write-up that wouldn't embarrass them in front of the researcher community — a piece that read like someone who had actually been in the room.
§ 02 — Approach
Three-week embed. Four SOC calls, two engineering calls, one with the third-party vendor. Six drafts. Two meaningful rounds of pushback. Metaphor declined when a diagram would do.
"The first write-up I've seen that doesn't make me want to write a rebuttal in the margins."
— Head of Security, on the third draft
43k
Reads · 30 days
7
Reposts by researchers
1
Rebuttal (constructive)
2
Follow-up briefs
Case Nº 02 · Cybersecurity SaaS · Content series · ~12,000 words
Client-side security: a four-part series.
Four pieces on the same problem, written from different angles: the attack, the mechanics, the blind spots, and the defence. The audience was technical but not uniform — security engineers, compliance officers, and developers all needed to find themselves in the same text.
Writing for a security audience means writing for people who will spot anything imprecise or oversimplified immediately. The brief required real domain knowledge — not just the ability to explain things clearly, but the ability to earn the reader's trust on technical ground.
§ 02 — Approach
Each piece was researched from primary sources: CVEs, incident reports, technical documentation. The writing had to work for a developer who knows their DOM and a compliance officer who doesn't — without talking down to either.
§ 03 — From the work
"Magecart isn't about faking login or payment pages. It's about the abuse of your real login and checkout pages that customers trust."
"The browser doesn't care what you approved in a pull request. It executes whatever it's told to execute."
"User trust is visual. When attackers control what renders in the browser, they're in control of user trust."
"Traditional server-side controls won't catch client-side breaches. They don't see how JavaScript behaves in the browser at runtime. They're looking in the wrong place."
"No inventory = no visibility = no control."
4
Pieces
~12k
Words total
3
Audiences served
1
Domain, learned from inside
About the writer.
Hilde Decrem. Journalism-trained, technology-pulled. I embed with one or two teams at a time, read source when source exists, and write copy that respects the reader's intelligence.
My bet is simple: most product writing sounds like it was written from the next building over. The fastest way to fix that is to be in the building.
I work with Claude and a small set of AI tools — for research, structure, and pressure-testing. The voice, the judgement, and the final edit stay mine.
$ cat about.yml
name:Hilde Decrem
based_in:Brussels, BE
languages:[EN, NL, FR]
trained_as:journalist
now:writer-maker
tools:
- editor
- terminal
- Claude (as collaborator)
- p5.js (occasionally)
availability:
ongoing:2 slots
one_off:open
email:hd@hildedecrem.com
§ Manifesto
01I will not write a word I do not understand.—
02I will spend more time with the product than with the brief.—
03I will not turn a feature into a metaphor if the feature is the story.—
04I will push back on copy the engineers wouldn't sign.—
