~/about

I'm Diego. I work on cloud infrastructure, Kubernetes, and the tooling that sits between them, mostly on the parts that decide whether an incident is a ten minute fix or a long night.

This site is where the rest of it ends up. Tools I built because something annoyed me enough, security work and CTFs, and writeups of problems that took a lot longer to understand than to fix.

Why I build things

Almost everything I've shipped started as a specific irritation rather than a product idea. I needed to sign a PDF, noticed I was about to upload a bank statement to a stranger's server, and built a PDF editor that never sees your files. I had a work Claude account and a personal one on a machine that only holds one login, so I made the account a property of the directory instead of something I had to remember. I watched teams put off a Helm chart upgrade because no diff would tell them what was about to break, and wrote one that understands Kubernetes semantics.

The pattern I keep landing on is that these failures were never invisible because they were subtle. They were invisible because nothing was looking. Most of what I build is an attempt to put something in the path that looks.

Security and CTFs

I play CTFs and write up the ones that teach me something. A data perimeter CTF that turned into a lesson about how AWS access decisions really compose, and an airline chatbot that gave up its secrets to prompt injection.

How I work

A few things I believe strongly enough to argue about, with the reasons attached, because an opinion without one is just a slogan:

• Security is an architecture problem, not a checklist. Checklists catch the failures somebody already had. Architecture decides which failures are possible at all.
• The best platforms fade into the background. If people have to think about your tool to use it correctly, the thinking is the product, and you shipped homework.
• If you can't explain it at 3 a.m., it's too complex. The audience for your design is a tired version of you with an incident open.
• Boring in production beats clever in review. Clever code gets applause once. Someone owns the boring version for years.

In practice that means Go and Bash for infrastructure tooling, TypeScript when it needs a browser, Python for everything in between, and a strong preference for the solution I'll still understand a year from now.

Elsewhere

Email: me@dcotelo.dev
GitHub: github.com/dcotelo
LinkedIn: linkedin.com/in/dcotelo
X: @dcotelo13