Card 01 / 23Architecture
- Problem
- An assistant that only answers saves little: the work is changing things.
- Rejected
Let it write alone, with an undo button- Chosen
- A before-and-after card for each change, built by the server
Back
/notesEngineering notes
Decisions, not tutorials.
The reasoning behind the tools I build: what the problem was, what I decided, and why. Written from production code, not from theory.
- notes
- 23
- min of reading
- 108
- since
- July 2026
23Logbook
Everything written, in order.
23 of 23 notes
- An assistant that writes with permissionI gave my dashboard's assistant permission to change projects, milestones, follow-ups and messages, and to prepare quotes. No write goes through without a card showing before and after, and testing against the real model found three bugs no test had caught.
- Quoting with a range that closesI built Plano, the quoting tool I use for every proposal. The price starts as a range and closes with every answer, the client receives their project drawn as a floor plan, and the AI reads the conversation without being able to write a single figure.
- The agreed price does not moveI built Cotiza, the tool I use to run my logistics consulting engagements. The price is set up front and never reopened; anything that comes later is an add-on, with its own price and the client's approval before the work starts. The AI helps count, but never charges.
- An analyst that proposes but does not decideI put an AI agent to work reading this site's attack log. The hard part was not getting it to reason well, but letting it wait hours for me to approve a block, never letting it see an IP, and making sure it ignores the orders attackers write into their own requests.
- A security showcase cannot lie, even by accidentI redesigned this site's security page to show the defense instead of describing it. The most useful part wasn't the animation, but the five things the page said that weren't true.
- The blocker that was never a credentialTwo months with the last lab phase waiting on a Vercel secret that, once added, opened no door at all. The load test never needed a permission, it needed someone to reread its own guardrail.
- Translating a site without opening a back doorPutting the site into English looked like writing work. What I found while planning it is that a language prefix gives every route a second name, and that all of my security guards authorize by comparing names.
- Some providers bill you, others cut you offGoing over a quota can only mean two things, and they cost very different things: money, or your site down. Why my infrastructure cost simulator paints them in different colors.
- The clientId never comes from the URLI built a portal where every client sees their projects, their invoices, and their documents. The number one risk wasn't someone getting in without permission: it was someone getting in with their own and seeing somebody else's.
- Two logins on one site, and neither knows the otherMy admin panel already had authentication solved with OAuth and JWT. When I built the client portal, the hard decision wasn't how to authenticate them: it was not reusing anything that already worked.
- Escalating IP blocks without locking myself outDetecting threats wasn't enough anymore. The portfolio's micro-SIEM gets real enforcement - a TTL that escalates with repeat offenses and honeypots that block on the request itself, not on the next cron.
- More than a green scanWiring npm audit, CodeQL, and axe-core into a panel of my own with history and dedup - so a security and accessibility scan tells a story instead of showing a checkmark nobody looks at twice.
- Mutating my code to find out if my tests actually workCoverage tells you which lines ran. Mutation testing asks something more uncomfortable - if I break this line on purpose, does any test notice? Plus Zod contracts, so an endpoint can't change shape without anyone realizing.
- Scanning any domain without putting your own at riskTurning a diagnostics endpoint only I could use into a public tool for my classmates - and why that means solving abuse and SSRF first, not the analysis itself.
- Charging for field work without the WhatsApp APINot all my work is code. I needed to charge for on-site tech support from my phone, out in the street, without paying for the WhatsApp Business API or exposing the amount in a link anyone could edit.
- E2E tests that check what actually mattersClosing the testing pyramid with Playwright without making it brittle - disposable databases, a sentinel that proves the demo's isolation, and why every test needs its own IP.
- Building a micro-SIEM for my portfolioScanners hit any site with a public IP, this one included. Instead of ignoring the noise, I built an engine of my own that detects it, classifies it, blocks it, and shows it in public.
- RAG - when it fits and how not to ruin itRetrieval-Augmented Generation isn't magic, and it isn't a replacement for fine-tuning. It's an architectural decision with clear trade-offs - and most failures happen in retrieval, not in the model.
- Revocable sessions on top of a stateless JWTMy admin panel used plain JWTs; a stolen cookie was unstoppable until it expired. Here's how I added a device list, remote revocation, and alerts without giving up the JWT.
- Chaos engineering that can't hurt youInjecting failures in production to prove the alerts work - with fail-open, a mandatory TTL, and a panic button, so the chaos can never become a real incident.
- SLOs and error budgets for small projectsUptime as a percentage is misleading. Adapting Google's SRE discipline - SLI, SLO, error budget, and burn rate - to a portfolio of small projects.
- Why I built my own uptime monitorUptimeRobot kept telling me everything was fine while production served the wrong page. So I wrote the check engine I actually needed.