Por qué armé este espacio

Este espacio —y El Radar, el newsletter que lo acompaña— nacieron de una necesidad concreta: no hay manera honesta de presentarme como desarrollador con solo un listado de tecnologías y screenshots de proyectos. Podés poner React, Next.js y Django en el CV y no decirle nada a nadie sobre cómo tomás decisiones cuando el producto está en producción y algo falla.

Este blog existe por eso. El Radar también.

El problema que intento resolver

Estuve casi una década en gestión comercial antes de pasarme al desarrollo. No vine de un bootcamp de tres meses ni de una universidad — vine de años entendiendo cómo las empresas convierten inversión en resultado. Eso cambió radicalmente la forma en que programo.

Cuando trabajo en un sistema, no pienso solo en que el código funcione. Pienso en qué decisión técnica tiene consecuencias para el producto, para el equipo que lo mantiene, para el negocio que depende de él. Y esas decisiones rara vez aparecen en el código final — están en los commits que no se hicieron, en las abstracciones que se descartaron, en los tradeoffs que elegiste un jueves a las once de la noche.

Acá voy a documentar esas decisiones.

Qué tipo de contenido vas a encontrar

Tres categorías, sin relleno:

Performance — No tutoriales de "cómo mejorar tu LCP en 5 pasos". Sino: qué decisión arquitectónica tomé en un producto real, qué métricas cambió, y qué sacrifiqué para llegar ahí. En FerrelonStock, un sistema de inventario que construí con Django y React, redujimos el tiempo de carga inicial de 4.2s a 1.8s. El cambio no fue heroico — fue una combinación de code splitting por rutas, ajustes en el caching del servidor y eliminar una dependencia que nadie había cuestionado en dos años. Lo interesante no es el número final. Es el proceso de encontrar el cuello de botella correcto.

Producto — La intersección entre ingeniería y criterio de negocio. Cómo se diseña una arquitectura que el equipo pueda mantener cuando el desarrollador original ya no está. Cuándo tiene sentido agregar complejidad y cuándo no. Por qué algunos sistemas bien escritos fracasan igual.

Automatización — Herramientas de IA aplicadas con criterio, no por tendencia. Cuándo automatizar acelera de verdad y cuándo agrega una capa de magia que nadie entiende seis meses después.

Para quién es esto

Para devs en transición que saben que aprender un framework no es suficiente para construir productos sólidos. Para founders técnicos que toman decisiones de arquitectura bajo presión. Para equipos evaluando contratar — acá podés ver cómo razono antes de escribir una sola línea de código.

No está dirigido a principiantes buscando tutoriales de introducción. Eso no quiere decir que sea exclusivo o difícil — quiere decir que asumo que ya sabés programar y que lo que buscás es criterio, no sintaxis.

El formato

Cada post en la web viene acompañado de una versión en carrusel para LinkedIn. No es el mismo contenido recortado — es el mismo argumento reformateado para un contexto diferente. El carrusel sacrifica profundidad por claridad; el post sacrifica brevedad por contexto completo.

Frecuencia: uno o dos posts por semana, sin calendario fijo. Publico cuando tengo algo concreto que decir, no para llenar un schedule.

La razón real

Construir presencia como desarrollador independiente requiere más que mostrar que sabés escribir código. Requiere mostrar que sabés cuándo no escribirlo, cómo evaluar tradeoffs y qué preguntas hacerse antes de abrir el editor.

Este blog es el registro de ese proceso. No editado para quedar bien — documentado para ser útil.