Si no sabes cuanto te cuesta una transacción, no estas dirigiendo tecnología.

En casi todos los talleres que hago con CTOs casi siempre llegamos al mismo comentario: alguien habla de escalabilidad con mucha convicción y, cuando pregunto cuánto costaría doblar el número de clientes mañana, se hace silencio.

No un silencio de “déjame calcularlo”. Un silencio de “nunca me lo he preguntado en serio”.

Y ahí está la diferencia entre saber que tu arquitectura puede escalar y saber qué significa económicamente que escale. Son conversaciones distintas. Y la segunda es la que te va a hacer el board.

Hay tres métricas que deberían ser de primero de CTO y que rara vez están calculadas con rigor:

𝗖𝗼𝘀𝘁𝗲 𝗽𝗼𝗿 𝘂𝘀𝘂𝗮𝗿𝗶𝗼 𝗮𝗰𝘁𝗶𝘃𝗼. No el coste total dividido entre usuarios. El coste real de servirle: compute, storage, transferencia, licencias, soporte. Sin ese número no puedes hablar de pricing, margen ni escalabilidad.

Ejemplo: si tu infraestructura cuesta 50k €/mes y tienes 10.000 usuarios activos, el titular es “5€ por usuario”. Pero si el 20% genera el 80% del tráfico, ese promedio oculta que algunos cuestan 0,50€ y otros 30€.

¿Qué pricing tienes para esos últimos?

𝗖𝗼𝘀𝘁𝗲 𝗽𝗼𝗿 𝘁𝗿𝗮𝗻𝘀𝗮𝗰𝗰𝗶ó𝗻. Clave en fintech, ecommerce o cualquier negocio donde “transacción” sea concreta. Si no sabes cuánto cuesta procesar un pago, generar un informe o ejecutar una búsqueda, no sabes si tu crecimiento es sano o una bomba de costes.

He visto equipos diseñar arquitecturas elegantes y caras para un volumen razonable, sin modelar qué pasaba si ese volumen se multiplicaba por diez. Cuando llegó el éxito, llegó también una factura de AWS que casi los mata.

𝗖𝗼𝘀𝘁𝗲 𝗽𝗼𝗿 𝗳𝗲𝗮𝘁𝘂𝗿𝗲. La más incómoda. Cada feature tiene un coste: infraestructura, complejidad, deuda técnica, mantenimiento. ¿Sabes cuánto cuesta mantener cada pieza? ¿O solo sigues añadiendo?

Y entonces llega la pregunta del board: ¿Qué pasa si mañana duplicamos clientes?

No quieren una respuesta técnica. Quieren una económica. Saber si el modelo aguanta, si los costes escalan lineal o exponencialmente y qué cuellos exigirán inversión antes de crecer.

Si respondes “nuestra arquitectura escala horizontalmente”, estás contestando a la pregunta equivocada. Si respondes “duplicar clientes nos costaría X más, con este margen de error, y hay dos piezas a optimizar”, estás actuando como un director técnico de verdad.

Eso separa gestionar infraestructura de dirigir tecnología como negocio.

¿𝗗ó𝗻𝗱𝗲 𝗲𝗺𝗽𝗲𝘇𝗮𝗿?

No necesitas un modelo perfecto, sino una estimación razonada. Identifica los servicios clave en coste, estima cómo varían con el volumen y construye una hoja con los drivers principales.

No es vistoso. Pero cambia cómo te percibe el negocio. Porque cuando llegue la pregunta incómoda, mejor haberla anticipado que quedarse callado.