Architecture and code review
The same work in two forms. Before you build, I read the design and point at what will break in production. Once it runs, I read the code and its behaviour under load, and explain why it breaks now.
- Architecture design. The shape of the system — boundaries, data flow, what happens when it grows.
- Reliability and fail-safe design. How the system degrades, how it recovers, what it refuses to lose.
- APIs and hygiene. Contracts, versioning, dependencies, build.
- Security. Exposure, secrets, and how a vulnerability report reaches you.
Most of the evidence is public. OpenSMTPD ships in the OpenBSD base system since 2013 and parses hostile input on port 25 for a living. At Plakar I work on kloset, a content-addressable backup engine. The rest ran in production behind NDAs, including PCI-DSS environments. Read the code before you read this page.
Technical due diligence
For funds and acquirers, pre-seed through Series B, on infrastructure, developer tools and open source. The question is not whether the code is clean. It is whether the codebase matches the story in the deck, and whether the team could rebuild what they are demoing.
It now includes a newer question: how much of this was generated rather than engineered — and whether anyone on the team can still tell the difference.
The team gets read too, not just the repository. I studied occupational psychology for years; half of a diligence is people — who holds the knowledge, and what leaves when they do.
One to five days of work, sized to the deal. The deliverable is one written memo: what exists, what is fragile, what a fix would cost. Under NDA. Conflicts are declared up front — name the target in your first mail so they can be checked before anything is signed.
Mail infrastructure
I wrote OpenSMTPD, the mail server that ships in the OpenBSD base system. If your problem involves SMTP, you are talking to someone who implemented it.
- Review. An existing mail setup read end to end — topology, queues, filtering, TLS.
- Migration. Off hosted mail, onto servers you control.
- Deliverability. SPF, DKIM, DMARC, IP reputation, and why your invoices land in spam.
- Post-incident forensics. Headers, logs and queues, after a compromise or a loss.
AI in the workflow
Engineering workflows are being rebuilt around AI — some of it warranted, some of it theatre. I use these tools every day and know their upsides as well as their failure modes.
Changing how a team works is a productivity question before a tooling question. The work is concrete: take an existing workflow, decide where a model helps and where it has no business, put review where it belongs, and measure the result — neither buying the hype nor underusing what works.
Engagements
I am CTO of Plakar, full time. Consulting fits around that, which is why the formats are short and defined: a scoped start, a scoped end, a written result.
Advisory is the one recurring format: a monthly block of hours for the questions that do not justify an audit — a design to sanity-check, a hire to interview, an incident to read.
- Architecture review one day · €1,200–1,500
- Audit two to three weeks · €900–1,200 per day
- Due diligence one to five days · €1,400–1,800 per day
- Advisory monthly, capped hours · €2,000–3,000 per month
Rates exclusive of VAT. Fixed quote before work starts.
What I don't take on
- Backup and storage products. That is the day job at Plakar. It is not for sale here.
- Staff augmentation. I do not join your team, your standups or your sprint board.
- Anything with a conflict of interest. Targets and clients are checked against each other before an NDA is signed. When in doubt, I decline.
Contact
One mail is enough: the system, the decision it blocks, the deadline. For due diligence, name the target — conflicts are checked before anything else is discussed.