APIs, integrations, automation, observable systems.
No simulated data, no toy projects.
I started early by reaching for systems that were too big for the level I had at the time. While most people around me were building beginner CRUDs, I was obsessed with what actually happens behind a real product: queues, caches, concurrency, deployments, sockets, infrastructure. The turning point was the day I stopped seeing backend as "just APIs" and started seeing it as designing systems that do not fall apart the moment people actually use them. That is when I got hooked for good.
Most of what I know came from breaking things. Deploys that took entire services down, badly configured proxies, concurrency bugs that were impossible to reproduce, PostgreSQL migrations done in a rush, middleware throwing absurd redirects in production. That is exactly where I learned the most. I realised I enjoy debugging complex systems and chasing real bottlenecks far more than building pretty interfaces. Understanding why something fails at a low level and fixing it elegantly is the closest I get to flow at a desk.
Over time my projects shifted toward real architecture work: automated pipelines, real-time SSE, multi-service Docker stacks, reverse proxies with nginx, scraping and trend systems, content automation, internal tooling. I never cared much for "generic apps". I want to build infrastructure that is useful, fast and stable for products that actually move.
The list below is what I reach for first, not what I tolerate. Picked by years of production wear, not by reading announcements.
A small number of real systems, each one live for an actual user base. Not a portfolio of half-finished demos.
Multi-tenant publishing platform tracking 11 trend sources, scoring opportunity, generating and reviewing articles, shipping to 13 niche sites in 12 languages. Postgres, pg-boss workers, Claude integration, custom QA pipelines, and a dashboard with live tail of every queue.
kramaru.esFour polyvps strategies running 24/7 with smart take-profit, hourly gates and circuit breakers. Real money, not a backtest. Daily metrics dashboard, kill-switch, audit log of every entry.
Football pick-settlement engine on OpenFootball plus Sofascore enrichment, wired into a Dockerised stack with per-container hardening. NGINX, Postfix, Server Actions encryption keys pinned to prevent header-replay attacks after a past incident.
Flutter Desktop POS, Node backend, MySQL, thermal printing, WhatsApp integration. Real customers, offline-first.
Public demo on mkir.es: a single .NET 8 process fans out database change events to many browsers via Server-Sent Events. Zero client dependencies, plain HTML rendering Postgres triggers as they happen.
mkir.esThe full version of one project I usually compress into a sentence. The hard decisions, the things I broke, and what is actually live.
TopSec exists to aggregate, synchronise and visualise data in real time without leaning on huge infrastructure or stacks that are overweight for what the product actually needs. The brief was simple to say and hard to deliver: keep the data live, fast and consistent while several services talk to each other at the same time.
Drawing a clean line between what lives in the .NET 8 backend and what is solved from Next.js. A subtle case made the line obvious: /api routes plus the next-intl middleware were producing 307 redirects to /es/api/*. Technically valid, practically broken. Real-time and stats endpoints were silently breaking on certain locales.
The patch nobody asks you to write is the one that earns the engineer rate: instead of fixing redirect rules one by one, I rebuilt the middleware matcher to exclude /api entirely. Small visual change, large architectural one.
Optimising too early is bad. Ignoring performance from day one is worse. Working principle
The other call was sticking with PostgreSQL as the single source of truth. For this product, consistency and the ability to write complex queries was worth more than the speed wins you could squeeze from a NoSQL store. Boring is fine when boring is correct.
Production broke once because I assumed a Docker image had genuinely been rebuilt. The "new" code kept behaving like the old code. The actual culprit was npm ci failing silently because package-lock was missing, leaving the build in an inconsistent state. I spent hours debugging application logic for what was a pipeline problem.
Strong takes earned through production incidents, not Twitter. If any of these makes you tense, we will probably get along.
Saying no makes the yes more reliable. These are the projects where I would not be the right hire.
Freelance and contracting since 2022. Open to remote-first roles or hybrid in Málaga and the Costa del Sol when the project earns the commute. Not interested in deeply corporate environments where engineering disappears under process.
Email gets the fastest reply. LinkedIn for warm intros, GitHub for code.