I take the whole problem, and I stay with it afterwards.
This page exists so you can tell early whether I am the right shape for the role. I work best when I own the outcome rather than a ticket queue, and I am slower than you would like in a place where every decision needs three sign-offs.
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 it was that an auditor would ask questions years later. The technology followed. When someone opens with a preferred framework I usually ask what breaks if we get it wrong.
I turn the rule that matters into a check
Written rules get forgotten, and security rules get forgotten first. So the important one becomes a test that runs on every change. It is cheaper than a review culture and it does not depend on anyone being awake.
I write down decisions, including the wrong ones
UM Schedule has 92 numbered decisions and some of them reverse earlier ones. That record is the reason a second person can pick the project up, and it is the reason I can tell you why something is the way it is a year later.
I use agentic tooling daily, and I set the boundaries first
Claude Code, Codex and similar command-line agents are part of how I work every day, including on the systems listed here. The architecture, the layering and the rules are decided before any generated code lands, and those rules are machine-checked so the tooling cannot quietly drift past them. It is a large part of why one person could build and run this much.
Two of those rules, in the product
Both of these are UM Schedule, the course-planning pilot. They are here because a rule is easy to write down and harder to point at.
Fig. 02 — the planner board. "Viewing as planner" is the role the service layer checks on every write.Fig. 03 — the same period, as a teacher sees it. A clash is a shape and a word, never colour alone.
One I got wrong
On an internal retrieval platform I was testing tenant isolation. A freshly created tenant could read every other tenant's documents and conversations. The row-level security policies were written correctly and were never being applied: the application connected to Postgres as a superuser, and a superuser bypasses row-level security entirely.
The part worth keeping is why the tests did not catch it. They connected to the database as the same superuser, so the isolation checks passed for exactly the reason the product was broken. A test that shares the privilege it is meant to be testing will always agree with you. Isolation tests now run as the restricted application role, and the rule is written down where the next person will find it.
What I am not
CertificationsNone. No TOGAF, no ITIL, no ISO lead implementer. If a role needs the certificate on day one, I am the wrong candidate.
Team scaleEverything above I built alone or nearly alone. I have run rollouts and steered vendors, and I have not led a standing engineering team.
InfrastructureI run VPS, Docker, Coolify and CI for my own systems. No Kubernetes at scale, no on-call rotation.
Model workI architect systems that use models: retrieval, embeddings, and hard limits on what a model is allowed to decide. I do not train or fine-tune models, and I have not run an evaluation pipeline in production.
ToolingI work with agentic coding tools every day. I need a workplace where approved tooling of that kind exists, though not a particular vendor. Self-hosted or enterprise-approved works fine. If they are banned outright, I am the wrong fit.
I would rather you know this now than in the third interview.
Happy to walk through any of these in detail, including the parts that went wrong.