Work
This site is mostly a record of what I build. Some of that work translates into engagements — security review, threat modelling, OPSEC for organisations and individuals handling sensitive data. The page below is what those engagements usually look like.
What I take
Code or architecture review
The most common shape. A team is about to ship a system that handles identity documents, financial data, or anything that would make the headlines if it leaked. I read the code and the design, ask uncomfortable questions, and write a report. Reviews run one to four weeks depending on how much code there is. The deliverable is one document — findings ordered by severity, an executive summary short enough that a non-engineer founder can forward it to the board, and remediation guidance specific enough that the engineering team knows what to change tomorrow morning.
Threat model
Two to five days. Most useful before a new product launches or a workflow changes shape (e.g. a document-handling firm moving from email attachments to a web upload). The output is the adversary classes you’re defending against, an asset list, the trust boundaries between zones, and a prioritised list of what to fix in what order. Cheaper than a full review; not a substitute for one.
OPSEC review — individuals
For people whose threat model is targeted attention: public figures, founders post-funding round, journalists working on something contested. One-off session or a short engagement. Phones, accounts, where to host email, what hardware to use for what, what to delete from where. Concrete; not a lecture.
Document-flow audit
For firms handling passport copies, medical records, client identity files. The question is the same every time: where does the data live, who can read it, what leaves the building, and what does the worst day look like. Two weeks typical. The report is practical — specific email rules, specific storage fixes, specific staff procedures, not a compliance checklist that tells nobody what to do with their actual inbox.
Sometimes also: pre-launch security review for a landing page or small application; cryptographic reasoning on a specific design (information-theoretic bounds, anonymity sets, statistical disclosure); an incident postmortem after the fact. These are scoped case-by-case.
What I don’t take
Penetration testing as a service — specialised firms exist and I’ll point at one if it helps. Compliance audits (ISO 27001, SOC 2, PCI) for the same reason. Anything in the immigration or legal-tech vertical. Engagements where the deliverable is a certificate I’m not qualified to issue. Anything I can’t reasonably scope in writing in one email exchange.
Starting
Email [email protected] with a paragraph or three. Useful to include: what you’re building or operating, the threat you’re trying to address, the rough shape and timing you have in mind, and anything that helps me decide whether I’m the right person.
I read every email. Reply within seven days. If it’s a fit, I send a short scope, a timeline, and a fixed fee in writing before any work starts. If it’s not, I point at someone who is.
How I work
Output is written. Reports, not slides. Sized to the engagement — a one-week threat model returns a tight document, not a hundred pages of padding. The buyer is the actual decision-maker (engineering lead, founder, partner), not a procurement gate.
Every engagement is fixed-fee, scoped in writing before work starts, with assumptions, deliverables, and what is explicitly out of scope. Changes are renegotiated; not absorbed into someone’s evening. Payment is on completion or by milestone, not by the hour. Standard NDA is fine; I don’t reference clients publicly without written consent.
The LED in the footer is the only availability signal: green = taking new work, amber = booked through next month, red = closed for new engagements. There is no calendar widget, no automated reply, no contact form. One email; the bar is low.