Escalar un SaaS tras el lanzamiento sin romper el producto

Todos celebran el lanzamiento. Casi nadie le advierte de la parte que viene después: ese año extraño y de nervios a flor de piel en el que el producto que le consiguió sus primeros cien clientes empieza a doblarse bajo el peso de los siguientes mil. No ocurre nada dramático. Las cosas simplemente se vuelven más lentas, más inestables, más difíciles de cambiar. Un martes cualquiera se da cuenta de que una función que antes llevaba un día ahora lleva una semana, y nadie sabe muy bien por qué. Ahí, y no en el lanzamiento, es donde la mayoría de los productos SaaS se ganan o se pierden en silencio.

Nos hemos sentado con muchos fundadores justo en este punto. No están fracasando, y eso es lo desconcertante. Los ingresos suben, el equipo crece, las demos van bien. Pero por debajo, el producto cruje. Los tickets de soporte suben más rápido que los usuarios. Los despliegues que antes eran aburridos ahora llegan con la respiración contenida. La base de código que hace un año parecía ingeniosa ahora parece un campo de minas donde cada cambio amenaza con activar algo más. No hicieron nada mal. Simplemente superaron lo que construyeron, y nadie les dijo que se suponía que eso iba a pasar.

Así que esta es la guía que desearíamos que más fundadores tuvieran antes de que aparecieran las grietas. No va de hiperescala, Kubernetes ni de lo que hizo algún unicornio con cincuenta millones de usuarios. Va del medio aburrido y decisivo: pasar de funciona para unos pocos a funciona para muchos, sin reescribirlo todo, sin asustar a sus clientes ni quemar a su equipo. El objetivo no es una arquitectura perfecta. Es un producto que sigue creciendo en lugar de uno que empieza a romperse en silencio.

Qué se rompe de verdad cuando un SaaS crece

Esta es la parte que más sorprende a los fundadores: los problemas de escalado casi nunca llegan como esa caída dramática para la que uno se prepara. El servidor no se incendia. En su lugar, el producto desarrolla una especie de febrícula constante. Páginas que cargaban al instante empiezan a tardar tres segundos. Un informe que iba bien para los primeros clientes da timeout con el grande que acaba de firmar. El mismo error reaparece una y otra vez porque dos partes del código dependen secretamente la una de la otra de un modo que nadie documentó.

Lo que de verdad se rompe rara vez son sus servidores: son sus supuestos. Al principio construyó para la forma de sus primeros usuarios: unas pocas cuentas, datos pequeños, flujos simples, todos más o menos iguales. El crecimiento no añade solo más de lo mismo. Añade variedad. Un cliente con diez veces los datos. Un equipo que usa una función de un modo que nunca imaginó. Un pico a las nueve de la mañana del lunes, cuando todos inician sesión a la vez. Cada uno viola en silencio un supuesto que se horneó en su código hace un año, cuando violarlo era impensable.

Los cuatro lugares donde tiende a aparecer primero son predecibles. La base de datos es casi siempre el canario: consultas que eran instantáneas en tablas pequeñas se arrastran a medida que crecen los datos. El endpoint lento: una o dos páginas que hacen demasiado trabajo por petición, bien hasta que el tráfico se acumula. El despliegue frágil, donde lanzar cualquier cosa se ha vuelto aterrador porque el código está demasiado enredado para razonar sobre él. Y la carga de soporte, que no es infraestructura en absoluto, pero es la señal temprana más fiel de que el producto ya no encaja con cómo la gente lo usa de verdad.

La trampa de resolver problemas que aún no tiene

Antes de hablar de arreglar cosas, una advertencia que ha salvado más productos que cualquier optimización. La mayor amenaza para un SaaS en crecimiento no es ignorar la escala: es perseguirla demasiado pronto. En cuanto un fundador siente la primera ralentización, el instinto es echar mano de la arquitectura que leyó en un famoso blog de ingeniería. Microservicios. Una cola de mensajes. Un montaje multirregión. Fragmentar la base de datos antes de que tenga un millón de filas.

Así es como se pasa seis meses y una fortuna construyendo infraestructura para una escala que no ha alcanzado, mientras el producto real se detiene. Peor aún, ahora ha hecho más difícil cada cambio futuro, porque un sistema distribuido es muchísimo más complejo de construir y depurar que el sencillo que tenía. Cambió un problema que aún no tenía por uno garantizado que tiene hoy: no se lanza nada.

La disciplina aquí es la misma que crea buenos productos en primer lugar: resuelva el problema que tiene delante, no el que le halaga imaginar. Un monolito aburrido y bien entendido que puede cambiar deprisa escalará mejor que un sistema distribuido de moda que le da miedo tocar. La complejidad es un coste que paga cada día, no una compra única.

Mida antes de cambiar nada

Casi todos los fundadores que conocemos en esta etapa están convencidos de saber dónde está el problema. Se equivocan la mitad de las veces, no por descuido, sino porque la intuición es un pésimo perfilador. La parte del código que parece lenta a menudo está bien; el verdadero culpable es alguna consulta silenciosa que se ejecuta cuarenta veces en una página en la que nadie pensó. No se puede arreglar lo que no se ha medido, y adivinar aquí es como los equipos pasan semanas optimizando lo equivocado.

No necesita una pila sofisticada de observabilidad para empezar. Necesita tres números aburridos delante, todo el tiempo. Qué endpoints son más lentos, y cuán lentos bajo tráfico real. Qué consultas de base de datos consumen más tiempo total: no la consulta individual más lenta, sino aquella cuyo tiempo se suma a través de miles de llamadas. Y dónde ocurren de verdad los errores, con suficiente contexto para reproducirlos. Con esos tres, la niebla suele despejarse en un día.

1. 1
   Active la monitorización básica

   Tiempos de respuesta por endpoint, tasas de error y registro de consultas lentas en la base de datos. Las herramientas alojadas lo hacen en una tarde. No puede mejorar un número que no ve.
2. 2
   Encuentre los tres principales reales

   Ordene por tiempo total consumido, no por intuición. Tres infractores casi siempre concentran la mayor parte del dolor. Apúntelos: esa es su hoja de ruta real.
3. 3
   Arregle uno, vuelva a medir

   Cambie una sola cosa, luego revise de nuevo los números. Confirme que ayudó antes de seguir. Dos cambios a la vez y nunca sabrá cuál importó.
4. 4
   Pare cuando sea suficientemente bueno

   Defina 'suficientemente rápido' antes de empezar; por ejemplo, cada página por debajo de un segundo con la carga actual. Más allá de eso, optimizar es un sumidero de tiempo, no una victoria.

Ese último paso importa más de lo que parece. El trabajo de rendimiento es genuinamente adictivo; siempre hay otro milisegundo que recortar. Pero sus clientes no notan la diferencia entre 200 ms y 120 ms, y las horas que pasa persiguiéndola son horas que no dedica a la función que de verdad haría crecer el negocio. Mida, arregle los tres principales, declare la victoria y siga adelante.

La base de datos es casi siempre el primer muro

Si tuviéramos que apostar dinero a dónde un SaaS en crecimiento topa con su primer techo real, apostaríamos a la base de datos cada vez. Es la parte del sistema donde las pequeñas decisiones tempranas se acumulan con más dureza. Una consulta sin índice se ejecuta en un parpadeo sobre mil filas y se atasca sobre un millón. El código no cambió. Los datos sí, y los datos solo crecen.

La buena noticia es que la base de datos es también donde viven las correcciones más baratas y de mayor impacto. La clásica es el índice ausente: una sola línea que convierte una consulta de varios segundos en una instantánea, porque la base de datos deja de escanear cada fila para encontrar las pocas que necesita. Justo detrás está el problema de consultas N+1: una página que, en lugar de hacer una pregunta, le hace en silencio a la base de datos la misma pequeña pregunta cientos de veces en un bucle. Ambos son comunes, ambos son invisibles hasta que mira, y ambos suelen arreglarse en un día una vez que los ha encontrado.

Hay una secuencia en la que apoyarse aquí, y conviene seguirla en orden en lugar de saltar al final. Arregle primero las consultas: índices, N+1, el informe lento. Luego añada caché para los datos que se leen constantemente pero cambian poco. Solo después tiene sentido hablar de réplicas de lectura, instancias más grandes o separar los datos. La mayoría de los productos SaaS nunca necesitan los pasos posteriores. Solo necesitaban los primeros bien hechos.

Escalar el producto significa escalar cómo lo cambia

Este es el giro que pilla desprevenidos a los fundadores: pasado cierto punto, escalar deja de tratar de que el producto soporte más usuarios y empieza a tratar de que su equipo soporte más cambio. Cuando eran usted y un desarrollador, todos tenían el sistema entero en la cabeza. Podía cambiar cualquier cosa porque sabía qué tocaría. Con cinco o diez personas, ese modelo mental se hace añicos, y el código que daba por hecho que todos lo sabían todo se convierte en un lastre.

Esta es la razón real de que los despliegues den miedo. No es que el código empeorara de la noche a la mañana; es que ya nadie puede predecir del todo el radio de impacto de un cambio. La solución no es el heroísmo ni un congelamiento de lanzamientos. Es invertir en el andamiaje poco glamuroso que permite a un equipo mayor moverse sin pisarse: una batería de pruebas automatizadas que detecte la rotura obvia, despliegues que sean rutina en vez de ceremonia, y una forma de apagar un mal lanzamiento en segundos en lugar de correr a apañarlo.

• Una batería de pruebas que cubra el puñado de flujos que serían catastróficos si se rompieran: inicio de sesión, pago, acción principal. No todo; los pocos críticos.
• Despliegues que se ejecuten con un botón, no un ritual, para que lanzar pequeño y a menudo sea seguro en vez de angustioso.
• Una forma rápida de revertir, para que un mal lanzamiento sea un evento de cinco minutos, no un incidente de toda la noche.
• Feature flags, para que pueda lanzar código a unos pocos clientes primero y apagarlo al instante si se porta mal.
• Documentación suficiente para que las vacaciones de una persona no congelen toda un área del producto.

Nada de esto aparece en una demo. Nada de esto añade directamente una función. Y es exactamente el trabajo que separa a un producto que sigue acelerando de uno que se ralentiza con cada nueva contratación. Los equipos que escalan bien son los que tratan su capacidad de cambiar el producto con seguridad como una función en sí misma, porque a escala, eso es precisamente lo que es.

Una breve historia desde el punto de quiebre

Para concretarlo, aquí va un compuesto sacado de trabajo que hemos hecho: detalles difuminados, la forma fiel a la realidad. Un pequeño SaaS para gestionar equipos de servicio de campo había lanzado bien y crecido hasta unos cientos de empresas de pago. Los fundadores estaban encantados y exhaustos a partes iguales. Entonces firmó su mayor cliente hasta la fecha: una firma con más usuarios y más datos históricos que sus diez clientes anteriores juntos.

En una semana, el panel en el que todos vivían se había ralentizado hasta arrastrarse para ese cliente, y, curiosamente, para todos los demás también. Los tickets de soporte se dispararon. Los fundadores supusieron que necesitaban un servidor mucho más grande y se preparaban para una rearquitectura dolorosa y cara. Ese fue el momento en que nos llamaron, y el instinto era comprensible pero equivocado.

No tocamos la arquitectura. Activamos el registro de consultas lentas y observamos durante una tarde. El culpable era casi vergonzosamente pequeño: el panel principal cargaba la lista de trabajos de cada usuario con un patrón N+1 clásico, lanzando una consulta por trabajo. Para un cliente pequeño eso significaba unas pocas docenas de consultas inofensivas. Para el nuevo gigante, significaba miles por carga de página, lo que, sobre infraestructura compartida, arrastraba todo el sistema hacia abajo para todos.

La lección que se llevaron los fundadores no era técnica. Era que el aterrador problema de escalado que habían imaginado, el que necesitaba una reconstrucción y una ronda de financiación, resultó ser, una vez medido, un arreglo de dos días escondido tras un síntoma temible. Habían estado a punto de pasar meses resolviendo el problema equivocado. Esa brecha, entre la crisis imaginada y la medida, es donde se desperdicia la mayor parte del dinero de escalado.

Cuándo de verdad toca reconstruir una pieza

Toda esta cautela ante el escalado prematuro puede leerse como nunca refactorice, nunca reconstruya. No es eso. A veces una parte del producto ha llegado de verdad al final de su vida, y parchearla de nuevo es la opción cara. El truco está en distinguir entre un límite estructural real y los dolores de crecimiento ordinarios que un arreglo medido resolvería.

La señal honesta es esta: reconstruya un componente cuando el coste de cambiarlo se ha vuelto de forma consistente más alto que el coste de reemplazarlo. No cuando es feo: el código feo que es estable y se toca rara vez está bien. Busca una parte del sistema donde cada cambio es lento y arriesgado, donde los mismos errores siguen volviendo, donde los desarrolladores nuevos no pueden trabajar con seguridad y donde ya ha probado los arreglos más baratos y ha topado con un muro. Cuando varias de esas cosas son ciertas a la vez, una reescritura enfocada de esa única pieza es la decisión correcta.

Y cuando reconstruya, reconstruya una pieza, no el producto. La reescritura completa desde cero es el canto de sirena del escalado, lo que parece limpio y acaba hundiendo un año mientras los competidores lanzan. Reemplace el único componente podrido, tras una frontera clara, mientras el resto del producto sigue funcionando y generando ingresos. Quirúrgico, no heroico.

Preguntas frecuentes