Cuando una startup comienza, muchas decisiones tecnológicas se toman con una prioridad bastante clara: hacer que funcione. Construimos un MVP con los recursos que tenemos. Usamos un servidor porque alcanza. Elegimos una arquitectura sencilla porque necesitamos salir rápido. Postergamos automatizaciones y resolvemos algunos procesos manualmente. No necesariamente son malas decisiones; muchas veces son exactamente las decisiones que necesita una empresa que todavía está intentando validar su negocio.

El problema aparece después.

El producto funciona, llegan clientes, aumenta la operación y aquello que construimos para validar una hipótesis empieza a sostener un negocio real. Entonces aparece una situación que viví muchas veces: sabemos que tenemos que cambiar algo, pero nunca encontramos el momento para hacerlo.

Siempre hay una nueva funcionalidad más urgente, un cliente que necesita algo, una oportunidad comercial o un objetivo del trimestre. La reconstrucción vuelve a quedar para después. Hasta que el costo de esperar empieza a ser mayor que el costo de cambiar.

El MVP cumplió su función

Hay algo injusto en la forma en que muchas veces hablamos de deuda técnica. Miramos una solución construida varios años atrás y decimos: "Esto está mal diseñado." Pero estamos juzgando una decisión pasada con información que en ese momento no existía. Quizás aquella arquitectura permitió lanzar el producto seis meses antes. Quizás evitó contratar cinco personas cuando la empresa todavía no tenía ingresos. Quizás permitió validar un mercado que nadie sabía si existía.

Por eso, una de las preguntas que más me interesa no es "¿por qué construimos esto así?", sino:

¿Sigue teniendo sentido hacerlo así hoy?

Una decisión puede haber sido correcta en 2023 y convertirse en un problema en 2026. No cambió necesariamente la calidad de aquella decisión.

Cambió el negocio.

El verdadero problema es no encontrar el momento para cambiar

Cuando una empresa crece rápido aparece una tensión permanente entre dos tipos de trabajo. Por un lado está todo lo que permite avanzar: nuevas funcionalidades, nuevos productos, clientes e integraciones. Por el otro está aquello que permite seguir avanzando en el futuro: arquitectura, seguridad, automatización, infraestructura, datos y procesos.

El primero suele tener un retorno visible. El segundo muchas veces no. Si asignamos cinco desarrolladores durante tres meses a reconstruir una parte de la plataforma, alguien va a preguntar qué funcionalidad nueva tendremos después de esos tres meses. Y quizás la respuesta sea: ninguna.

Por eso estas decisiones son incómodas. Estamos sacando capacidad de algo que puede generar ingresos hoy para invertirla en evitar un problema que quizás todavía no ocurrió. El error es evaluar solamente el primer lado de esa ecuación.

"Tenemos deuda técnica" no es un argumento de negocio

Si un CTO necesita recursos para resolver un problema estructural, no alcanza con decir que la arquitectura quedó vieja, que tenemos deuda técnica o que deberíamos adoptar un patrón más moderno.

Hay que traducir el problema.

Tenemos que entender qué riesgo operacional estamos asumiendo, cuánto trabajo manual genera, qué ocurre con seguridad, cuántas personas necesitamos para sostener la operación, qué posibilidades de crecimiento estamos limitando y cuánto podría costarnos un incidente. Ese cambio de lenguaje es fundamental.

El NIST Cybersecurity Framework 2.0, por ejemplo, incorporó Govern como una de sus seis funciones principales justamente para conectar la gestión de ciberseguridad con el contexto, la estrategia y el riesgo de la organización. En marzo de 2026, NIST publicó además la versión final de SP 1308, una guía que conecta explícitamente ciberseguridad, gestión de riesgo empresarial y decisiones sobre workforce.

La discusión deja entonces de ser:

"Tecnología necesita tres meses para refactorizar."

Y pasa a ser:

"¿Qué riesgo y qué costo estamos dispuestos a aceptar si no hacemos este cambio?"

Ahí la conversación ya no pertenece solamente a Tecnología.

Es una decisión de negocio.

El costo de no cambiar también se puede calcular

No todos los problemas tecnológicos pueden traducirse perfectamente a dinero. Pero muchos permiten, como mínimo, construir escenarios. Supongamos una operación que procesa 100.000 casos mensuales. Un 3% termina en excepciones que requieren intervención manual y necesitamos 10 personas para resolverlas.

Eso significa 3.000 excepciones por mes. Ahora supongamos que el negocio crece diez veces y llegamos a un millón de casos mensuales. Si no modificamos nada y la tasa de excepciones continúa siendo del 3%, pasamos de 3.000 a 30.000 casos manuales por mes. Si la productividad permanece constante, podríamos pasar de necesitar 10 personas a necesitar aproximadamente 100.

Pongamos un número deliberadamente hipotético para poder hacer la cuenta: un costo total para la empresa de USD 30.000 anuales por persona. La estructura destinada a resolver excepciones pasaría entonces de aproximadamente USD 300.000 a USD 3 millones anuales. Ahora imaginemos que rediseñar y automatizar parte del proceso permite bajar las excepciones del 3% al 0,5%, y que hacerlo requiere cuatro desarrolladores durante cinco meses.

Recién ahora tenemos una discusión interesante.

Ya no estamos preguntando:

"¿Vale la pena dedicar cinco meses a mejorar algo que funciona?"

Estamos comparando el costo de esa inversión contra el costo operativo que podríamos acumular si no la hacemos. Los números del ejemplo son hipotéticos.

La cuenta no debería serlo.

Poner los dos lados sobre la mesa

No pretendo convertir esto en una fórmula financiera exacta, pero me resulta útil pensar la decisión de esta manera.

Costo de cambiar

Desarrollo + migración + riesgo de implementación + costo de oportunidad

frente a:

Costo esperado de no cambiar

Costo operativo incremental + crecimiento de headcount + riesgo de incidentes + oportunidades que no podemos capturar + costo futuro de hacer el cambio más tarde

No todos esos componentes van a poder medirse con la misma precisión. El costo de cinco desarrolladores durante cuatro meses es relativamente sencillo de calcular. El impacto de una arquitectura que dentro de dos años podría impedir lanzar un nuevo producto es mucho más incierto.

Pero incertidumbre no significa cero. Nuestro trabajo es explicitar esos supuestos para que el negocio pueda decidir qué riesgo está dispuesto a asumir.

Cuatro señales que miro

No existe una fórmula universal que indique cuándo hay que reconstruir algo. Pero sí hay señales observables que pueden decirnos cuándo conviene volver a hacer la cuenta.

1. Costo marginal

¿Qué ocurre con el costo por operación, cliente o transacción cuando crecemos?

Si el negocio aumenta diez veces y nuestros costos aumentan diez veces —o más—, necesitamos entender por qué.

2. Capacidad absorbida

¿Qué porcentaje de la capacidad del equipo estamos dedicando a sostener lo existente?

Que exista mantenimiento es normal. Que trimestre tras trimestre necesitemos dedicar una proporción mayor del equipo simplemente a mantener la operación puede indicar un problema estructural.

3. Dependencia de personas

¿Podemos operar y modificar el sistema sin depender de determinadas personas que conocen toda su historia?

Cuando el conocimiento crítico está concentrado en dos o tres personas, el problema ya no es solamente tecnológico. También tenemos riesgo operacional.

4. Radio de impacto

¿Qué pasa hoy si algo falla?

Un incidente sobre una plataforma con 1.000 clientes no tiene necesariamente las mismas consecuencias cuando esa misma plataforma tiene 100.000. El software puede ser exactamente el mismo.

El riesgo no.

Ninguna de estas señales obliga por sí sola a reconstruir. Lo que hacen es indicarnos que llegó el momento de volver a hacer la cuenta.

El mismo sistema puede representar un riesgo diferente

Una solución aceptable para un MVP puede dejar de serlo cuando cambia la escala de la empresa, aunque técnicamente no haya cambiado nada. No necesariamente apareció una nueva vulnerabilidad. Cambió lo que tenemos para perder. Un sistema con cien usuarios y uno con un millón pueden utilizar exactamente la misma tecnología y representar riesgos completamente diferentes. Lo mismo ocurre con disponibilidad, fraude, privacidad, backups, controles de acceso o monitoreo.

La madurez tecnológica debería evolucionar junto con la madurez del negocio. NIST SP 1308 plantea precisamente que las decisiones sobre personas, procesos y tecnología deberían responder al apetito y tolerancia al riesgo de la organización, sus objetivos, presupuesto y capacidades disponibles.

No necesitamos el mismo nivel de controles para validar un MVP que para operar una empresa consolidada. Pero necesitamos reconocer cuándo dejamos de ser aquel MVP.

El costo tecnológico ya no es solamente cloud

También está cambiando la forma en que la industria piensa estos problemas. En febrero de 2026, FinOps Foundation modificó una palabra en su misión: pasó de hablar de las personas que gestionan el "value of cloud" a las que gestionan el "value of technology". Los números explican bastante bien por qué.

Según State of FinOps 2026, el 98% de los equipos relevados ya gestiona gasto relacionado con IA, frente al 31% dos años antes. El 90% gestiona SaaS o planea hacerlo, además de licencias, private cloud, data centers y otras categorías tecnológicas. No cambió solamente cuánto gastan las organizaciones.

Cambió lo que tienen que administrar.

El FinOps Framework 2026 incluso incorporó Executive Strategy Alignment como una nueva capability, buscando conectar explícitamente las decisiones de optimización tecnológica con estrategia, resultados de negocio y trade-offs ejecutivos. Para mí, esa evolución refleja bastante bien el cambio que necesitamos hacer también desde el liderazgo tecnológico.

La conversación no debería ser solamente cuánto cuesta nuestra infraestructura. Debería ser qué valor obtenemos de nuestra inversión total en tecnología y cómo ese costo evoluciona cuando crece el negocio.

El tiempo es otra variable de la ecuación

Hay algo más que no deberíamos perder de vista. Quizás hoy sea más barato no hacer nada. Eso no significa que debamos cambiar inmediatamente. Supongamos que sabemos que una plataforma necesita ser reconstruida, pero todavía puede operar razonablemente durante dos años. Al mismo tiempo, la empresa tiene una oportunidad comercial crítica durante los próximos seis meses.

Probablemente tenga sentido seguir adelante. La decisión cambia completamente si estimamos que dentro de tres meses el crecimiento esperado va a duplicar el equipo necesario para sostener la operación.

Por eso no alcanza con preguntar:

¿Hay que cambiarlo?

Hay una pregunta mejor:

¿Cuánto tiempo tenemos antes de que no cambiarlo empiece a costarnos más?

Puede ser un mes, puede ser tres años o puede ser nunca. Las tres respuestas son perfectamente válidas.

No todo lo que está viejo necesita ser reemplazado

También hay que evitar transformar esta lógica en una excusa para reconstruir permanentemente. Que exista una solución más moderna no significa que debamos adoptarla. Que una arquitectura tenga deuda técnica tampoco significa automáticamente que haya que reemplazarla. Si algo funciona, tiene un costo razonable, no representa un riesgo significativo y no limita lo que el negocio quiere hacer en los próximos años, quizás la mejor decisión tecnológica sea:

no tocarlo.

La tecnología no debería cambiar porque apareció algo más interesante para usar. Debería cambiar cuando exista una razón suficiente para hacerlo. Y cuestionar una decisión para terminar concluyendo que sigue siendo correcta no es tiempo perdido. También es parte del análisis.

La otra mitad de la cuenta

Cuando evaluamos una decisión tecnológica solemos empezar por una pregunta:

¿Cuánto cuesta hacerlo?

Es lógica, concreta y relativamente fácil de responder. Pero es solamente la mitad de la cuenta.

La otra pregunta es:

¿Cuánto nos puede costar no hacerlo?

A veces la respuesta será dinero. Otras veces será riesgo, velocidad, personas, seguridad o capacidad de crecimiento. Y algunas veces, después de poner todo sobre la mesa, la conclusión será que todavía conviene esperar.

Eso también es una buena decisión.

Porque el trabajo del liderazgo tecnológico no consiste en modernizar todo. Consiste en entender qué tenemos que cambiar, por qué tenemos que cambiarlo y cuánto tiempo tenemos antes de que no hacerlo empiece a costarnos más que hacerlo.

Fuentes y lecturas