How I work

I take the whole problem, and I stay with it afterwards.

So you can tell early whether I am the right shape for the role. I work best owning the outcome rather than a ticket queue.

Four things I actually do

I start from the constraint, not the stack

On Antragslotse the binding fact was a sentence in German social law; on ESF-Plus, an auditor asking questions in 2029. The technology followed.

I turn the rule that matters into a check

Written rules get forgotten, security rules first, so the one that matters becomes a check that runs on every change.

I write down decisions, including the wrong ones

On ESF-Plus the audit trail was built before the feature that needed it, and what that call cost is written down beside what it bought.

I use agentic tooling daily, and the boundary is a check, not a prompt

The failing test is committed before the agent writes anything, and the rules that matter are build failures rather than sentences in a contributing guide. How I use agents has the commits, the rules and the parts that do not flatter me.

Two rules in ESF-Plus

The case study has the architecture behind both.

The account administration table, headed 718 accounts in total, showing its first three rows. The organisation, contact-person and both e-mail columns are covered by one black redaction bar.
Fig. 02 — 718 accounts, one per organisation. Who may see a document is decided in one layer, not screen by screen.
The contact-data entry grid, shown empty, with columns for surname, first name, street, postcode, town, telephone and e-mail, and buttons to import, validate, upload and export.
Fig. 03 — the upload grid. Validation runs on the server before a row is stored.

One I got wrong

Validating an internal retrieval platform of mine, one with no users and nothing in it but my own fixtures, a fresh tenant read every other tenant's documents and conversations. The row-level security policies were correct and were never evaluated: the application connected to Postgres as a superuser, and a superuser bypasses row-level security.

The isolation tests had only ever run against SQLite, which has no such thing, so they had never exercised a policy at all. Pointed at Postgres they would have connected as that same superuser and passed anyway. A test that shares the privilege it is testing will always agree with you.

The runtime now connects as a role that cannot bypass it, migrations run as a separate principal, and every tenant-scoped table forces the policy even for its owner.

Where my evidence is strongest

DeliverySystems built alone or in very small teams, with the rollout, the provider coordination and the stakeholder conversations attached. I have not led a standing engineering team.
InfrastructureLinux VPS, Docker, Coolify and CI for my own systems · Microsoft 365, Entra ID and Intune at work. Not Kubernetes at scale and not hyperscaler platform engineering.
Applied AIRAG, supervisor and worker orchestration, vector and keyword retrieval, self-hosted embeddings, and the limits on what a model may decide. I build around foundation models rather than training or fine-tuning them.
Agentic engineeringClaude Code and Codex in the normal workflow. Architecture, tests, CI and review stay the control layer, and I work best where tooling of that kind is approved.

Each row says what the systems on this site actually show, and where that evidence stops.

Happy to walk through any of these in detail, including the parts that went wrong.