Creative-tech developer at TUKK.

Reliability, alignment, efficiency — and, of course, fanciness. Based in Madrid; unreasonably interested in the half of software nobody demos.

Creative and technical work fails in the same boring way. The version that shipped isn't the one that got approved. The decision that mattered is buried somewhere in a chat thread. The automation did something and now nobody can reconstruct what.

Nobody sets out to build it that way. It just happens, quietly, while everyone is busy with the interesting parts.

So I build the unglamorous stuff that stops it: versioned state, changes you can audit after the fact, and automation that stays inside a fence and hands you a receipt on the way out. It should be reliable enough to trust, aligned enough to understand, efficient enough to use — and nice enough that people actually want to.

At TUKK, a small company I helped start, I work on internal tooling: design systems and tokens, CI that gates instead of decorating, branch governance with codeowners that genuinely block things, and infrastructure for routing across LLM providers without the whole thing falling over when one of them does.

Mostly TypeScript, Python, and a frankly worrying amount of YAML.

Almost all of it lives in private repos, so treat this as context rather than a portfolio. The contribution graph is the honest version.

I want to take the pattern I use privately every day and pull one small, generic, public piece out of it: a tool that checks whether a thing is actually ready — right version, right metadata, approvals present, evidence attached — before it goes out the door. Local-first, runs from a repo, useful on its own.

It doesn't exist yet. When it does, it'll be linked right here instead of described in the future tense.

• Reliability. State before interface; if the model of what changed isn't durable, the UI is decoration.
• Alignment. Automation has a defined boundary, returns evidence and remains reviewable afterwards.
• Efficiency. Small and finished beats large and abandoned. I have the abandoned repos to prove it.
• Fanciness. Clarity and care are part of the job. Useful things should not have to look or feel like a compromise.
• Proof. A direction isn't a result, and I try not to blur the two.

If you maintain something in developer tooling, workflow automation, or anywhere creative work needs a real audit trail — I'd rather show up with one small useful fix than a grand proposal. Issues and discussions here work fine.