Generado artificialmenteBau es selbst: hazlo tú mismo
Durante décadas el software estándar fue la decisión sensata: listo, probado, más barato que cualquier cosa propia. Esta cuenta se ha dado la vuelta. No porque el software estándar haya empeorado, sino porque construir lo propio se ha abaratado en órdenes de magnitud. Lo que queda son los costes que siempre comprabas con el estándar y hasta ahora tenías que aceptar.
El motivo por el que se elegía el estándar ha desaparecido
La decisión por un sistema listo nunca fue una declaración de amor. Era una cuenta de costes: construir lo propio significaba años de desarrolladores, y los años de desarrolladores eran lo más caro de la casa. Frente a eso, cualquier licencia era barata, y cualquier framework gratuito imbatible.
Esta única magnitud ha cambiado. Lo que antes era un trimestre hoy es una tarde. Con eso cae el argumento que sostenía toda la construcción.
Queda el otro lado de la cuenta, que antes a nadie le importaba porque no había alternativa: la adaptación a ideas ajenas, la espera de calendarios ajenos, arrastrar legados ajenos, y una superficie de ataque que tú no elegiste.
Estos conceptos siempre estuvieron en el balance. Solo que nunca fueron el problema, porque la alternativa era más cara. Ahora ya no lo es.
Tú no compras un trozo de software, compras un árbol genealógico
Los 79 son el número más importante de esta serie. Un equipo se decide por un paquete y con ello asume las decisiones de docenas de personas a las que nunca conoció, sobre código que nunca leyó. En septiembre de 2025 bastó una sola credencial de acceso de desarrollador comprometida para meter código malicioso en dieciocho paquetes que juntos llegan a 2,6 mil millones de descargas por semana suman. Ninguno de estos paquetes era dudoso. Solo estaban en todas partes.
No peor. Localizable.
Aquí está el punto en el que la mayoría de los textos sobre este tema se desvían. Afirman que lo casero es más seguro. Eso no es verdad. Tu sistema construido por ti mismo tiene con alta probabilidad más errores que un proyecto establecido en el que mil personas han revisado durante años.
La diferencia está en otra parte, y es más importante que el número de errores: MonocultivoEl término viene de la agricultura. Un campo con una sola variedad se puede cultivar de forma eficiente, pero una plaga que encaja con esa variedad se lleva todo el campo. La diversidad es ineficiente y sobrevive. hace reutilizables los ataques.
Un sistema propio no está en ninguna de estas listas. No es más seguro, es no buscable. Quien quiera atacarlo tiene que entenderlo primero, y eso es trabajo manual sobre un solo objetivo, en lugar de un bucle sobre cien mil. Eso no desplaza la calidad de tu código, sino la economía del ataque, y esa economía decide si apareces en absoluto.
La segunda parte de ello es la visibilidad misma. Un sistema estándar delata desde fuera lo que es. Rutas, cabeceras, nombres de archivo y páginas de error son huellas dactilares. Cualquiera que mire tu sitio conoce tu plano, antes de que haga el primer intento.
Donde el estándar sigue ganando, y de forma clara
Una tesis que no conoce límite es una ideología. Así que aquí el límite, y sigue una sola pregunta: ¿Hay en este punto intercambio con el mundo exterior?
Donde algo sale de tu sistema o entra en él, el estándar no solo está permitido, sino que es obligatorio. Un formato de fecha propio, un formato de imagen propio o un protocolo de transmisión propio no te hace independiente, te hace inalcanzable.
El caso más duro es el cifrado. Escribir criptografía propia es un camino conocido y bien documentado para hacerte daño a ti mismo. No porque lo casero sea malo en principio, sino porque aquí los errores son invisibles: un procedimiento de cifrado roto funciona a la perfección en la prueba y aun así no protege nada. Lo mismo vale para los procedimientos de inicio de sesión, las zonas horarias, la codificación de caracteres y el procesamiento de pagos.
La regla no dice por tanto «no tomes nunca algo ya hecho». Dice: En los márgenes estándar, en el núcleo propio.
La línea divisoria no discurre entre grande y pequeño, sino entre intercambio y núcleo.
| Área | Elección | Justificación |
|---|---|---|
| Protocolos, formatos, juegos de caracteres | Estándar | Pura superficie de intercambio. Propio significa aquí aislamiento. |
| Cifrado, inicio de sesión, pago | Estándar | Los errores permanecen invisibles y no se pueden probar. |
| Base de datos, tiempo de ejecución, servidor web | Estándar | Maduro, intercambiable, sin rasgo distintivo. |
| Tus procesos y reglas | Propio | Justo aquí te diferencias. Un sistema ajeno te obliga a su visión de ello. |
| Tus interfaces y herramientas | Propio | El esfuerzo de adaptación a un sistema terminado supera ya la construcción. |
| Tus datos y su estructura | Propio | De lo contrario, los esquemas ajenos determinan qué preguntas puedes plantear en absoluto. |
Lo transferible es el conocimiento, no el componente
El consejo "constrúyelo tú mismo" se malinterpreta a menudo como "empieza de cero". Se quiere decir lo contrario.
Cuarenta años de construcción de software han aportado conocimientos que son acertados: separar el estado, hacer visibles los errores pronto, mantener las interfaces estrechas, no duplicar nada. Estos principios son lo valioso. No cuestan nada, no generan dependencia y no se quedan obsoletos.
El componente en cambio no trae los principios. Trae la interpretación de los principios hecha por gente ajena, además de sus compromisos, sus legados y su hoja de ruta.
Esa es también la razón por la que los sistemas existentes siguen siendo valiosos, solo de forma distinta a lo pensado: como plantilla, no como fundamento. Lees cómo un proyecto maduro resolvió un problema, entiendes por qué y lo construyes de la forma que encaja en tu propio caso. El plano es el rendimiento, no el edificio.
Adoptar un sistema estándar es un proceso de clonación. Obtienes una copia exacta de algo que surgió para otro propósito, y cada copia posterior es idéntica. Eso es eficiente y es un estancamiento: una copia no puede nada que el original no pudiera ya.
Construir por ti mismo significa que tu sistema lleva tu propia instrucción de construcción. Cada adaptación es una pequeña desviación, y la mayoría de ellas no valen nada. Pero algunas sí, y esas permanecen.
La mutación es el motor de la evolución. Un sistema que solo copia no tiene ese motor. Puede mejorarse esperando a que alguien más mejore algo. Nada más.
La pregunta ha girado
Ya no dice «¿podemos permitirnos la construcción propia?», sino «¿podemos permitirnos que decisiones ajenas determinen nuestro negocio?».
No todo de una vez
El camino no es el gran reemplazo. Es la pieza que hoy más duele, luego la siguiente.
El estándar permanece en los bordes
Protocolos, cifrado, bases de datos. Quien construye lo propio aquí no ha entendido el punto.
La piedra de toque
Pregunta en cada componente: ¿determina cómo trabaja tu negocio? Si es así, te pertenece. Si solo transporta datos, toma el estándar y alégrate.
- Sonatype, State of the Software Supply Chain 2026. Paquetes maliciosos 2025, cantidad acumulada, proporción por directorio de paquetes. sonatype.com
- Socket, evaluación de CVE 2025. Volumen total de los reportes de vulnerabilidades y proporción del ecosistema de WordPress. socket.dev
- Unit 42, Palo Alto Networks. Superficie de ataque del directorio npm, cascada de septiembre de 2025. unit42.paloaltonetworks.com
Las cifras sobre vulnerabilidades y tiempos de explotación se refieren a 2025 y al primer semestre de 2026. Describen reportes e incidentes observados, no el número total de brechas existentes.
