El impacto financiero y operativo de elegir mal una tecnología o arquitectura, más allá del costo inmediato de desarrollo: mantenimiento, retrabajo, rotación de equipo y oportunidades perdidas.
Cuando un empresario o un gerente escucha que un proyecto de software fracasó, la explicación suele girar alrededor de lo evidente: el proveedor no cumplió, el equipo no tenía la experiencia necesaria, el alcance se descontroló. Pero hay un tipo de fracaso que rara vez se cuenta en esos términos y que, sin embargo, es responsable de una porción significativa del dinero que se pierde en proyectos tecnológicos: las malas decisiones técnicas que se tomaron al inicio y que parecían inofensivas.
Elegir una base de datos que no soporta el volumen de datos que el negocio va a tener en dos años. Elegir un framework que dentro de 18 meses va a quedar sin mantenimiento. Elegir una arquitectura que obliga a reescribir todo cuando aparece un requisito nuevo que era previsible. Estos no son errores de implementación: son errores de decisión. Y su costo no se limita a lo que costó desarrollar sobre la decisión equivocada. Se extiende durante años, en formas que no siempre son obvias para quien no está cerca del código.
Este artículo pone números —no cifras exactas, imposibles de generalizar, sino órdenes de magnitud— al costo de una mala decisión tecnológica. El objetivo no es asustar, sino dar argumentos para que la elección de tecnología se trate como lo que es: una decisión de negocio.
Una decisión técnica equivocada no produce un solo costo. Produce al menos cinco, que se acumulan en el tiempo y que, juntos, suelen superar ampliamente lo que costó desarrollar el producto en primer lugar.
Es el más evidente y el que cualquier presupuesto de corrección contempla: volver a construir lo que ya se construyó, pero con la tecnología correcta. Si una funcionalidad costó 100 horas desarrollarla sobre la tecnología equivocada, rehacerla sobre la correcta va a costar otras 100 horas —en el mejor de los casos—, más el tiempo de migrar los datos y adaptar las integraciones.
Pero el retrabajo rara vez es 1:1. Cuando se migra una base de datos, por ejemplo, no basta con mover los datos: hay que reescribir todas las consultas, todos los procedimientos almacenados, todas las integraciones que dependían de esa base. El costo real de una migración de base de datos suele estar entre 1.5x y 3x el costo de haberla construido sobre la tecnología correcta desde el inicio.
Migrar un sistema en producción implica hacerlo sin interrumpir el servicio, manteniendo dos entornos funcionando en paralelo durante la transición, y con la presión adicional de que cualquier error afecta a usuarios reales. El costo de migrar un sistema en producción es significativamente mayor que el de construirlo desde cero con la tecnología correcta.
Cada tecnología tiene un costo de mantenimiento distinto. Un sistema construido sobre una tecnología con poca comunidad, documentación escasa o pocos desarrolladores disponibles en el mercado va a costar más de mantener —en horas y en dinero— que uno construido sobre una tecnología madura y con ecosistema amplio.
El mantenimiento inflado se manifiesta de varias formas:
Un sistema que sobre una tecnología mainstream requiere 20 horas mensuales de mantenimiento puede requerir 40 o 50 sobre una tecnología marginal. Esa diferencia, mes a mes, durante años, es un costo que nunca apareció en la decisión inicial pero que el negocio paga igual.
Los desarrolladores quieren trabajar con tecnologías que tengan demanda en el mercado laboral, porque eso protege su empleabilidad futura. Un equipo que trabaja con una tecnología marginal o anticuada tiene más riesgo de rotación. Y cada rotación cuesta: reclutamiento, selección, onboarding, curva de aprendizaje y pérdida de conocimiento acumulado.
El costo de reemplazar a un desarrollador se estima típicamente entre el 50% y el 200% de su salario anual, dependiendo de la seniority y de la especificidad del conocimiento que se pierde. Si la tecnología que usás reduce el pool de candidatos disponibles, ese costo tiende al extremo superior del rango.
Este costo no es exclusivo de equipos internos. También aplica a proveedores externos: una agencia que trabaja con tecnologías poco demandadas va a tener más dificultad para retener talento, y esa inestabilidad se traduce en entregas inconsistentes, cambios de equipo frecuentes y pérdida de contexto sobre el proyecto.
Los negocios cambian. Aparecen nuevas funcionalidades que los clientes piden, nuevas integraciones que se vuelven necesarias, nuevas regulaciones que obligan a modificar procesos. Cada vez que el negocio necesita que el software se adapte, la tecnología sobre la que está construido determina cuánto tiempo y cuánto dinero va a costar hacerlo.
Una tecnología con buen soporte para testing automatizado, con herramientas de integración continua maduras y con una arquitectura que permite cambios localizados, va a permitir adaptarse en días o semanas. Una tecnología que no tiene nada de eso puede requerir meses para el mismo cambio. Y esos meses de demora tienen un costo de negocio: clientes que se van, oportunidades que se pierden, competidores que llegan antes.
La guía sobre qué decisiones técnicas pueden limitar el crecimiento detalla cómo ciertas elecciones tempranas se convierten en frenos cuando el negocio necesita velocidad.
Es el más difícil de medir y, con frecuencia, el más grande. Mientras el equipo está migrando una base de datos, reescribiendo un módulo o peleando con una tecnología que no escala, no está construyendo funcionalidades que agreguen valor al negocio. No está mejorando la experiencia del usuario. No está reduciendo costos operativos.
Ese tiempo —que puede ser meses o incluso años— tiene un costo de oportunidad concreto: el valor que el negocio dejó de generar porque sus recursos técnicos estaban ocupados apagando incendios en lugar de construir.
Las malas decisiones tecnológicas rara vez se toman por ignorancia. Se toman por tres motivos que conviene conocer para poder contrarrestarlos:
Por inercia: "usemos lo que ya conocemos". Es la razón más frecuente y, en muchos casos, la correcta. Pero cuando lo que ya se conoce es una tecnología que no es adecuada para el problema, la inercia se convierte en un lastre.
Por moda: "usemos lo que está de moda". Las tecnologías nuevas tienen momentum, casos de éxito ruidosos y community managers activos. Pero lo nuevo también tiene menos trayectoria, menos casos de uso en producción a escala y más probabilidad de tomar decisiones de diseño que después se revelan equivocadas.
Por precio: "usemos tecnología open source para no pagar licencias". El costo de licencia de una tecnología es una fracción de su costo total de propiedad. Ahorrar USD 500 por mes en licencias y gastar USD 5,000 por mes en desarrolladores que luchan con una herramienta sin soporte no es un ahorro: es una transferencia de costo.
No necesitás saber programar para evaluar si una decisión tecnológica es razonable. Necesitás hacer cuatro preguntas, y prestar atención a las respuestas —y a lo que no se responde—.
1. ¿Cuántas empresas similares a la nuestra usan esta tecnología en producción? No en pruebas, no en proyectos personales: en producción, con usuarios reales, a una escala comparable a la que tu negocio necesita. Si la respuesta es "ninguna" o "muy pocas", hay un riesgo que merece explicación.
2. ¿Cuántos desarrolladores en el mercado local conocen esta tecnología? No se trata de si existen desarrolladores —siempre existen—, sino de cuántos y a qué costo. Si el proveedor te dice que no te preocupes porque ellos tienen el equipo, la pregunta siguiente es: ¿y si el equipo rota?
3. ¿Qué tan activa es la comunidad y cada cuánto se publican actualizaciones? Una tecnología sin actualizaciones frecuentes puede estar madura y estable —eso es bueno— o puede estar abandonada —eso es pésimo—. La diferencia está en si las actualizaciones que se publican corrigen errores y vulnerabilidades de seguridad.
4. ¿Qué pasa si dentro de dos años necesitamos cambiar? Ninguna decisión tecnológica es para siempre, pero algunas son más difíciles de revertir que otras. La explicación sobre deuda técnica para founders desarrolla este punto en profundidad. Si la respuesta a esta pregunta es vaga o empieza con "no va a ser necesario", hay que insistir.
Pedile a tu proveedor que te explique, en términos de negocio, por qué la tecnología que propone es la mejor para tu caso específico —no para cualquier caso. Si la respuesta se apoya solo en ventajas técnicas ("es más rápido", "es más moderno"), pedí que lo traduzca a impacto en tu negocio: tiempo de desarrollo, costo de mantenimiento, facilidad para encontrar equipo.
No toda decisión que se desvía del camino más transitado es mala. Hay contextos donde usar una tecnología menos popular es la decisión correcta: cuando el problema es tan específico que las alternativas mainstream no lo resuelven bien, cuando el equipo tiene una expertise profunda en esa tecnología que compensa los riesgos, o cuando la tecnología ofrece una ventaja competitiva real —no percibida— que justifica asumir el costo adicional.
La diferencia entre una decisión informada y una mala decisión no está en la popularidad de la tecnología, sino en si quien la tomó entendió los costos que estaba asumiendo y los consideró aceptables frente a los beneficios esperados. Una decisión informada incluye un plan de contingencia. Una mala decisión no.
El costo de una mala decisión tecnológica no se paga de una vez. Se paga en cuotas mensuales, durante años, en forma de mantenimiento más caro, cambios más lentos, equipo más difícil de encontrar y oportunidades que se pierden mientras el equipo está ocupado en cosas que no deberían ser necesarias. La buena noticia es que, con cuatro preguntas bien hechas, la mayoría de esas decisiones pueden evitarse antes de que cuesten algo.
¿Quieres evaluar cómo aplicar esto a tu proyecto?
Cuéntanos tu caso →