Cuando hablamos de escalabilidad en tecnología, la conversación suele ir rápidamente hacia infraestructura. ¿Cuántas requests soportamos? ¿Tenemos autoscaling? ¿Podemos agregar más servidores? ¿La base de datos aguanta? Son preguntas importantes. Y conviene hacer una aclaración: escalar cómputo suele ser relativamente sencillo; el estado, y particularmente la base de datos, muchas veces sigue siendo una de las partes difíciles.

Pero incluso si resolvemos perfectamente esa dimensión, todavía no sabemos si la empresa puede escalar. Porque soportar más tráfico y escalar un negocio son dos problemas diferentes.

Supongamos que mañana vendemos diez veces más

Imaginemos una empresa que hoy procesa 10.000 solicitudes mensuales y, producto de un crecimiento extraordinario, pasa a procesar 100.000. La infraestructura responde. La aplicación sigue disponible y los tiempos técnicos se mantienen dentro de lo esperado.

¿La empresa escaló?

Todavía no lo sabemos.

Necesitamos mirar qué pasó con las excepciones, la atención al cliente, fraude, conciliaciones, operaciones, seguridad, datos y el equipo que mantiene todo eso funcionando. Porque si las ventas aumentaron diez veces pero también necesitamos diez veces más personas para sostenerlas, técnicamente soportamos más volumen.

Económicamente quizás no escalamos.

Esta es la distinción que más me interesa.

El problema aparece cuando el crecimiento se convierte en trabajo manual

Los sistemas suelen funcionar bien mientras todo ocurre por el camino esperado. El problema aparece con las excepciones: una solicitud que no pudo procesarse, un pago que no concilió, un documento que no pudo validarse o una integración que devolvió algo inesperado.

Y aparece una persona.

Cuando tenemos cien casos y dos requieren intervención manual, probablemente no importe demasiado. Pero si multiplicamos el negocio por diez y multiplicamos también esas excepciones, una persona puede convertirse en cinco, cinco en veinte y, eventualmente, en un equipo completo dedicado a compensar aquello que el sistema no pudo resolver.

Para mí, esa es una señal muy clara:

Cuando el crecimiento empieza a trasladar sistemáticamente trabajo desde los sistemas hacia las personas, hay que volver a mirar el diseño.

Eso no significa que toda intervención humana sea mala. Algunas decisiones requieren contexto, juicio o un nivel de riesgo que hace razonable que exista una persona involucrada. El objetivo no debería ser eliminar al ser humano del proceso. Debería ser reservar la intervención humana para aquello donde realmente aporta valor.

Escalar es generar apalancamiento

Pensemos en una fintech que administra una cartera de créditos. Supongamos que multiplica sus ventas por diez. Si para administrar una cartera diez veces mayor necesita multiplicar también por diez su equipo operativo, existe una relación prácticamente lineal entre negocio y estructura.

Ahora imaginemos que la empresa vende diez veces más, procesa diez veces más solicitudes y administra una cartera diez veces mayor, mientras que el trabajo requerido por los equipos aumenta solo marginalmente.

Ahí ocurre algo diferente.

La tecnología está generando apalancamiento. Para mí, esa es una buena forma de definir escalabilidad:

Una empresa escala cuando su capacidad de generar negocio crece mucho más rápido que los recursos necesarios para sostenerlo.

No significa que el headcount nunca deba crecer. Significa que volumen y estructura no deberían estar obligados a crecer en la misma proporción.

El costo por unidad cuenta mejor la historia

Una forma práctica de analizar esto es dejar de mirar solamente el costo total y empezar a observar el costo por unidad de negocio. Supongamos que hoy procesamos 100.000 solicitudes mensuales. Entre infraestructura y operación humana, cada solicitud nos cuesta USD 0,50:

  • USD 0,15 de tecnología;
  • USD 0,35 de trabajo operativo.

El costo mensual asociado sería de aproximadamente USD 50.000. Ahora el negocio crece diez veces y procesa un millón de solicitudes. Si existe apalancamiento, parte de los costos fijos se distribuye entre muchas más operaciones. Quizás el costo unitario baje a USD 0,30. El negocio aumentó 10×, pero el costo asociado pasó de USD 50.000 a USD 300.000: creció 6×.

Eso puede ser una muy buena señal.

Pero imaginemos el escenario contrario. Las excepciones aumentan, necesitamos incorporar más personas, aparecen nuevos procesos manuales y el costo por solicitud sube a USD 0,70. Ahora un volumen 10× mayor genera un costo de USD 700.000 mensuales.

La empresa creció.

Pero cada nueva unidad de negocio se volvió más cara de producir. El concepto de Unit Economics de FinOps apunta justamente a relacionar el gasto tecnológico con el valor generado por los productos, servicios o actividades de la organización, en lugar de analizar el gasto tecnológico de manera aislada.

Una factura de cloud más alta no significa necesariamente que exista un problema. Puede ser simplemente una consecuencia del crecimiento.

La pregunta relevante es:

¿Qué ocurre con el costo necesario para producir cada nueva unidad de negocio cuando aumenta la escala?

El apalancamiento también introduce riesgo

Hay que evitar convertir la automatización en un objetivo por sí mismo. Supongamos que automatizamos todas las excepciones de un proceso de originación de crédito. Eliminamos gran parte de la intervención manual y reducimos mucho el costo operativo.

Excelente.

Pero ahora una decisión equivocada también puede ejecutarse automáticamente miles de veces. Un falso positivo de fraude puede bloquear clientes legítimos. Una regla incorrecta puede rechazar solicitudes válidas. Un error de conciliación puede propagarse antes de que alguien lo detecte.

La persona que antes resolvía una excepción no era solamente un costo. En algunos casos también era un control. Por eso la pregunta no debería ser solamente cuánto logramos automatizar. También necesitamos medir la tasa de error, el impacto potencial de una decisión incorrecta, los mecanismos de monitoreo y cuándo una operación debería escalar nuevamente a una persona.

Escalar no significa eliminar controles. Significa diseñarlos para la nueva escala.

Automatizar un mal proceso solo lo hace más rápido

Podríamos intentar solucionar cualquier problema automatizando. Pero automatización no garantiza escalabilidad. Si automatizamos un proceso mal diseñado, simplemente podemos ejecutar un proceso malo más rápido. DORA utiliza una idea parecida al analizar la incorporación de IA en desarrollo de software. Su State of AI-assisted Software Development 2025, basado en casi 5.000 profesionales tecnológicos, caracteriza a la IA como un amplificador: puede potenciar organizaciones con buenas capacidades, pero también amplificar problemas existentes.

La investigación encontró mejoras en throughput de entrega, pero también un aumento en la inestabilidad. La extensión que hago de ese concepto es simple:

la tecnología amplifica sistemas.

Por eso, antes de automatizar un proceso, conviene entender qué sistema estamos amplificando.

Las dimensiones que solemos olvidar

La infraestructura es solo una parte de la escalabilidad. Hay al menos otras dos dimensiones que suelen aparecer cuando el negocio ya creció.

Datos

Con pocos clientes podemos sobrevivir con información dispersa, procesos manuales, definiciones ambiguas o conocimiento almacenado en las cabezas de determinadas personas. Con diez veces más operación, eso empieza a romperse. Necesitamos medir, auditar, detectar anomalías, automatizar decisiones, construir modelos y entender mejor qué está ocurriendo.

Para hacer todo eso necesitamos haber pensado cómo capturamos, almacenamos, gobernamos y hacemos accesibles los datos. Una empresa puede tener infraestructura escalable y una arquitectura de datos que no lo sea.

Organización

Lo mismo ocurre con las personas.

Un equipo de cinco desarrolladores puede coordinarse hablando. Uno de cincuenta necesita mecanismos diferentes: ownership, documentación, estándares, observabilidad, procesos de desarrollo, plataformas internas y mecanismos para compartir conocimiento. DORA reportó en 2025 que el 90% de las organizaciones relevadas había adoptado plataformas internas y que el 76% tenía equipos dedicados a gestionarlas.

Eso no significa que toda startup necesite un equipo de Platform Engineering. Significa que las prácticas que funcionan con diez personas no necesariamente funcionan con cien. Y hay otra limitación importante: contratar tampoco escala instantáneamente. Una persona nueva puede necesitar semanas o meses para alcanzar productividad plena. Algunos perfiles además son escasos y el conocimiento crítico concentrado en dos personas no se multiplica simplemente aprobando presupuesto.

Por eso la escalabilidad humana no es solo una cuestión de cuánto cuesta contratar. También es una cuestión de cuánto tarda una organización en absorber nuevas personas y cuánto conocimiento puede transferir sin depender de individuos concretos.

El test de 10×

Hay una pregunta extremadamente sencilla que me gusta utilizar:

Si mañana multiplicamos por diez el negocio, ¿qué más tendría que multiplicarse por diez?

La respuesta funciona casi como un diagnóstico. Si necesitamos aumentar capacidad de cómputo, probablemente podamos resolverlo —aunque, nuevamente, el estado y la base de datos merecen un análisis particular—. Pero si también necesitamos multiplicar por diez el equipo operativo, las excepciones manuales, los incidentes, el fraude, los tiempos de respuesta o el costo por transacción, tenemos algo que revisar.

No todo tiene que mantenerse constante. Eso sería irreal. La pregunta es cuáles de nuestras variables están creciendo linealmente con el negocio y si realmente deberían hacerlo. Podemos hacer el ejercicio sobre cinco dimensiones:

  1. Tecnología: ¿qué infraestructura necesita crecer?
  2. Costo: ¿qué ocurre con el costo por unidad?
  3. Personas: ¿qué equipos necesitan crecer y cuánto?
  4. Procesos: ¿qué excepciones o tareas manuales se multiplican?
  5. Riesgo: ¿qué errores o incidentes aumentan su impacto con la escala?

La lista que surge de esas cinco preguntas nos dice mucho más sobre nuestra capacidad de escalar que saber cuántas requests por segundo soporta una API.

Escalar no es soportar más tráfico

Por eso no definiría escalabilidad como la capacidad de soportar más usuarios o más requests.

La definiría de otra manera:

Escalabilidad es la capacidad de aumentar significativamente el negocio sin aumentar en la misma proporción la complejidad, el costo y el esfuerzo necesarios para sostenerlo.

Eso incluye infraestructura, pero también arquitectura, procesos, datos, seguridad, personas y cultura. Y cambia la pregunta que debería hacerse un CTO.

Ya no es solamente:

“¿Nuestros sistemas soportarían diez veces más usuarios?”

Es:

“¿Nuestra empresa podría operar con diez veces más usuarios?”

La diferencia parece pequeña.

Pero puede ser la diferencia entre una empresa que simplemente está creciendo y una empresa que realmente está preparada para escalar.

Fuentes y lecturas