Build vs buy: cómo decido y cómo monto lo que construyo

el problema

Hay dos errores que salen caros, y son opuestos. Uno: pagar por todo, acabar con doce suscripciones, los datos repartidos por medio mundo y atado de pies y manos a cada proveedor.

El otro: construirlo todo a mano y terminar manteniendo un montón de cacharros que solo entiendes tú —y vuelta al punto único de fallo de siempre. El criterio está en el medio, y casi nadie se lo escribe.

qué monté

No monté una herramienta: monté una forma de decidir. Antes de construir nada, lo paso por cuatro preguntas. Si las tengo claras, la decisión casi se toma sola.

cómo lo hice

En la práctica: si no es mi terreno y ya existe algo estándar y bueno, pago sin complejos —mi tiempo vale más. Si es parte de mi ventaja, o no hay nada que encaje, o me espanta el lock-in, lo construyo y lo aprendo.

Un ejemplo mío: el panel de métricas de esto que estás leyendo.

Podía pagar una herramienta de analítica. Pero no era mi core, el coste mensual no me convencía y, sobre todo, no quería mis datos en la nube de otro. Así que lo monté con Metabase y PostgreSQL en Docker, en mi servidor. Coste: 0 €. Lo mantengo yo, sí, pero es sencillo y los datos son míos. La web, igual: GitHub Pages en vez de pagar hosting.

el resultado

Decido más rápido y con menos culpa. Pago lo que toca sin sentir que "fallo" por no hacerlo yo, y construyo donde de verdad aporta. Y lo que construyo es poco y deliberado, no un museo de proyectos a medias.

qué aprendí

Que la pregunta de verdad no es build vs buy. Es: ¿esto dónde quiero gastar mi tiempo? Constrúyelo si te hace más fuerte. Págalo si solo te quita un problema de encima. Y escribe tu criterio una vez, para no rediscutirlo cada vez.