un hijo propio

Un hijo propio no es solo una metáfora familiar: en ingeniería de software, describe con precisión casi dolorosa lo que ocurre cuando un equipo decide construir su propia plataforma, framework o herramienta interna en lugar de adoptar una solución del mercado.

La decisión de criar un hijo propio tecnológico -un motor de reglas, un sistema de autenticación, un orchestrator de despliegues o un data pipeline custom- suele nacer de una mezcla de ambición técnica y frustración legítima con herramientas externas. Sin embargo, ese hijo exige mantenimiento, guardias, documentación y una devoción que rara vez se presupuesta en la fase de diseño. En este artículo analizamos cuándo vale la pena, cuándo es una trampa y cómo tomar la decisión con rigor técnico.

El síndrome de "un hijo propio" en equipos de ingeniería

El término "un hijo propio" se usa en organizaciones de Software para referirse a sistemas desarrollados internamente que adquieren una carga emocional y política difícil de separar de su valor técnico. Un claro ejemplo es el framework interno de frontend que reemplazó a React porque "no se adaptaba a nuestra forma de trabajar", o el sistema de CI/CD construido sobre scripts de Bash porque Jenkins "era demasiado pesado". Estos proyectos generan identidad de equipo, pero también resistencia al cambio.

Desde la perspectiva de arquitectura, el problema no es construir: es construir sin un contrato claro de mantenimiento. En producciones reales hemos visto cómo un hijo propio de orquestación de contenedores, creado antes de que Kubernetes madurara, se convierte en una capa de abstracción imposible de migrar. El equipo original se fue, la documentación quedó obsoleta y los nuevos desarrolladores aprenden a "no tocar" ciertos directorios. La herramienta dejó de ser un activo y se convirtió en un pasivo técnico.

Cuándo tiene sentido criar tu propia plataforma interna

Construir un hijo propio es defendible cuando existe un diferencial competitivo real que no puede obtenerse del mercado. Netflix no adoptó un CDN genérico: construyó Open Connect porque la latencia y el ancho de banda eran variables críticas de su negocio. Shopify desarrolló internamente gran parte de su infraestructura porque la escala y el modelo de tenants requerían optimizaciones que ninguna plataforma comercial ofrecía. En estos casos, el software propio no es capricho: es inversión estratégica.

Para evaluar si corresponde, usamos una matriz de cuatro ejes: diferenciación estratégica, complejidad regulatoria, capacidad de mantenimiento a largo plazo y costo total de propiedad (TCO). Si la solución no aporta diferenciación, si existen alternativas open-source maduras como Apache Kafka para streaming, Prometheus para métricas o Keycloak para identidad, y si tu equipo no tiene capacidad de mantenerla por al menos cinco años, entonces no es hora de tener un hijo propio. Es hora de adoptar.

Costos ocultos de mantener un sistema propio en producción

El costo visible de un hijo propio es el tiempo de desarrollo inicial. El costo real aparece en los años siguientes: parches de seguridad, migraciones de dependencias, capacitación de ingenieros nuevos, incidentes a las 3 a m y refactorizaciones acumulativas. Según estimaciones de Stripe y el informe "Developer Coefficient" (2018), los equipos dedican en promedio un 33% de su tiempo a pagar deuda técnica. Gran parte de esa deuda proviene de herramientas internas que crecieron sin gobernanza.

En entornos de producción hemos observado que un hijo propio de autenticación, por ejemplo, requiere actualizaciones continuas ante vulnerabilidades como CVE recientes, rotación de tokens, cumplimiento de OAuth 2. 0 (RFC 6749) y adaptaciones a cambios en navegadores respecto a cookies de terceros. Eso sin contar la carga de soporte interno. Auth0, Okta o Keycloak tienen equipos completos dedicados a eso. Tu equipo de cinco personas, probablemente no,

Arquitectura y decisiones técnicas difíciles de revertir

Cuando decides crear un hijo propio, estás tomando decisiones de arquitectura con alto coeficiente de fricción de migración? El lenguaje de programación, el modelo de datos, los protocolos de comunicación y los contratos de API se vuelven puntos de no retorno parciales. Si construyes un pipeline de datos en Python con Pandas y luego necesitas escalar a Spark, la refactorización no es lineal. Si diseñaste una API REST propia en lugar de adoptar gRPC o GraphQL donde correspondía, pagarás el costo de compatibilidad eterna.

Un principio útil es el de reversible decisiones descrito por Martin Fowler: diferenciar entre decisiones de alto impacto y bajo costo de reversión versus decisiones de alto impacto y alto costo de reversión. Adoptar una librería es reversible. Construir tu propio message broker no lo es, o al menos no sin una migración que puede durar años. Antes de dar el paso, documenta explícitamente cuál sería el plan de salida de tu hijo propio si falla.

Conocimiento tácito, bus factor y la sostenibilidad del equipo

Uno de los riesgos más subestimados de un hijo propio tecnológico es la concentración de conocimiento tácito. El código puede estar en GitHub, pero las razones por las que se tomaron ciertas decisiones, los bugs conocidos, los workarounds y los límites de escala viven en la cabeza de una o dos personas. Si esas personas se van, el sistema no deja de funcionar, pero su mantenibilidad colapsa. En SRE llamamos a esto el bus factor: el número mínimo de personas que - si desaparecen, bloquean el proyecto.

Para mitigarlo, el código propio debe tener estándares más exigentes que el código de producto. Requiere ADRs (Architecture Decision Records) - runbooks actualizados, tests de contrato, diagramas de arquitectura validados y sesiones de onboarding estructuradas. En nuestra experiencia, un sistema interno sin documentación viva pierde un 40% de su velocidad de iteración cada año. Eso convierte a un hijo propio en un cuello de botella organizacional, no en un acelerador.

Integración con ecosistemas abiertos y estándares de la industria

Un hijo propio tecnológico no debe vivir en una isla. Cuanto más se desvíe de estándares abiertos, mayor será el costo de integración y mayor la dificultad para contratar talento. Si tu sistema de colas propio no implementa AMQP o MQTT, cada nuevo servicio debe aprender tu protocolo. Si tu framework de frontend no es compatible con npm o no sigue convenciones de React/Vue, cada desarrollador nuevo enfrenta una curva de aprendizaje innecesaria.

Los estándares existen precisamente para reducir esa fricción, and hTTP/2 (RFC 7540), OAuth 21, OpenTelemetry, Prometheus exposition format o OpenAPI son ejemplos de interfaces comunes que permiten interoperabilidad. Cuando construyas algo interno, pregúntate: ¿puedo exponerlo a través de una interfaz estándar, Si la respuesta es no, tu hijo propio probablemente esté generando más deuda que valor.

Métricas objetivas para decidir construir o adoptar

Para evitar que la decisión se convierta en un debate religioso, aplicamos métricas cuantificables. Algunas que hemos usado en evaluaciones reales incluyen: time-to-market estimado, costo de oportunidad del equipo, número de ingenieros necesarios para mantenimiento, frecuencia esperada de cambios regulatorios y nivel de customización requerido. Si la solución comercial cubre el 90% de los casos y el 10% restante puede resolverse con una capa de adaptación, rara vez justifica un desarrollo propio.

Además, considera el total cost of ownership a cinco años, no solo la licencia anual. Una solución SaaS como Datadog o PagerDuty puede parecer cara, pero incluye soporte, SLA, cumplimiento y evolución del producto. Compararla solo contra el costo de salario de un ingeniero es engañoso. En múltiples ocasiones hemos visto que un hijo propio de observabilidad interna termina costando más que una plataforma comercial equivalente, sin alcanzar la misma profundidad de análisis.

Estrategias de transición cuando el sistema propio ya no escala

A veces el problema no es haber creado un hijo propio, sino no saber cuándo dejarlo crecer. La transición requiere una estrategia de migración gradual, no un "big bang". El patrón strangler fig, descrito por Martin Fowler, es especialmente útil: envuelves el sistema viejo con una nueva capa, rediriges tráfico incrementalmente y desactivas componentes solo cuando el reemplazo demuestra estabilidad.

En la práctica, esto significa mapear los flujos críticos, identificar los contratos más acoplados y construir adapters hacia la nueva plataforma. Si tu hijo propio es un motor de notificaciones, podrías migrar primero los canales no críticos (push informativas) antes que los transaccionales (recuperación de contraseña). Cada etapa debe tener métricas de éxito claras: latencia p95, tasa de error, throughput y satisfacción del equipo. Sin datos, la migración se convierte en un proyecto político, no técnico.

FAQ: Preguntas frecuentes sobre construir software propio

• ¿Qué significa "un hijo propio" en tecnología? Se refiere a una herramienta, plataforma o sistema desarrollado internamente por un equipo, al que se le tiene afecto o dependencia, y que requiere mantenimiento continuo a largo plazo.
• ¿Cuándo es válido crear un sistema propio? Cuando existe diferenciación estratégica, requisitos regulatorios específicos o limitaciones técnicas que ninguna solución del mercado resuelve de forma rentable.
• ¿Cuáles son los principales riesgos? Deuda técnica acumulada, concentración de conocimiento tácito, altos costos de mantenimiento, dificultad para escalar y resistencia organizacional al cambio.
• ¿Cómo se compara con adoptar software open-source? El open-source reduce el costo inicial, pero requiere evaluar la madurez de la comunidad, la frecuencia de actualizaciones de seguridad y la capacidad interna de contribuir o mantener forks.
• ¿Qué hacer si ya tenemos un hijo propio que no escala? Documentar el estado actual, medir el costo real de mantenimiento, diseñar un plan de migración gradual usando patrones como strangler fig y definir métricas de éxito antes de comenzar.

Conclusión: amar tu sistema propio sin dejar de ser honesto

Tener un hijo propio en ingeniería de software no es inherentemente malo. Puede ser la decisión que define la ventaja competitiva de una empresa. Pero debe ser una decisión consciente, medida y reversible en la medida de lo posible. La peor versión de este patrón es la que nace del orgullo técnico, se alimenta de la inercia organizacional y termina ahogando la velocidad del equipo.

Si estás evaluando construir una plataforma interna, sé exigente con los números. Calcula el TCO real. Compara contra soluciones open-source maduras como Temporal, Backstage, ArgoCD o Grafana. Define criterios de salida antes de escribir la primera línea de código. Y si ya tienes un hijo propio en producción, hazle una auditoría honesta: ¿sigue aportando valor proporcional a lo que cuesta mantenerlo?

Llámanos o escríbenos si necesitas una evaluación técnica de tu arquitectura actual. En Denver Mobile App Developer ayudamos a equipos a decidir entre construir, adoptar o migrar sistemas críticos, con foco en escalabilidad, costos y sostenibilidad del equipo. Enlace interno: servicios de arquitectura de software

What do you think?

¿Has vivido un caso donde un sistema propio pasó de ser un activo estratégico a un pasivo técnico? ¿Qué señales te indicaron que había que cambiar de rumbo?

¿Consideras que el orgullo técnico o el "not invented here" sigue siendo un problema dominante en los equipos de software actuales, o ha disminuido con la adopción del cloud y del open-source?

¿Cuál crees que es el umbral mínimo de documentación y gobernanza que debe exigirse a un sistema interno para que no dependa exclusivamente de una o dos personas?