En corto
- Es para proyectos que ya existen y ya tienen usuarios, no para empezar de cero.
- Empieza siempre por un diagnóstico con alcance cerrado: rendimiento, base de datos, seguridad, accesos, copias, despliegue, dependencias y coste de infraestructura.
- De ahí sale un plan priorizado por daño real, con horas estimadas, y decides tú hasta dónde llegar.
- La ejecución deja entornos separados, despliegue automático, copias que se prueban restaurando, monitorización con avisos y registro de errores.
- El código, las cuentas y la infraestructura quedan a nombre de tu empresa. Sin permanencias y sin nada que dependa del proveedor para seguir funcionando.
- Tras la entrega hay documentación, traspaso y un periodo de acompañamiento para lo que solo sale con uso real.
¿Por qué mi aplicación se cae cuando entran muchos usuarios?
Casi nunca es que te falte servidor. En los proyectos que llegan así el problema está en tres o cuatro sitios concretos, y casi siempre son los mismos. Una consulta sin índice que tarda ocho segundos cuando la tabla crece. Un listado que lanza una consulta por cada fila en vez de una para todas. Un pool de conexiones agotado porque nadie lo configuró. Procesos pesados corriendo en el mismo hilo que atiende a los usuarios. Cero caché en lo que nunca cambia.
Lo malo no es tener esos fallos. Lo malo es no poder verlos. Sin métricas ni registro de errores estás adivinando, y adivinando acabas pagando una máquina más grande para que el mismo cuello de botella tarde un poco más en aparecer. Primero se mide. Después se toca.
Qué reviso en el diagnóstico antes de tocar una línea de código
El diagnóstico es la primera fase y tiene alcance cerrado. Medimos rendimiento real: qué rutas son lentas, cuánto tardan con tus datos y dónde se va el tiempo. Base de datos: consultas caras, índices que faltan, conexiones, tamaño actual y a qué ritmo crece. Seguridad: claves metidas en el repositorio, endpoints sin autenticar, permisos demasiado abiertos, datos personales sin cifrar. Accesos: quién entra a qué, incluidas cuentas de gente que ya no trabaja contigo. Copias, despliegue, dependencias sin soporte y la factura de infraestructura, que muchas veces paga recursos encendidos que nadie usa.
Sale un informe escrito con hallazgos, riesgo y esfuerzo estimado, en castellano y sin jerga. Ese informe es tuyo aunque después no se contrate la corrección.
- Rendimiento: rutas lentas, tiempos reales y dónde se pierde el tiempo
- Base de datos: consultas caras, índices, conexiones y ritmo de crecimiento
- Seguridad y accesos: claves expuestas, permisos y cuentas que sobran
- Copias y despliegue: si existen, si se han restaurado y cómo se sube a producción
- Coste de infraestructura: qué pagas y qué está encendido sin usarse
El plan de estabilización va priorizado por lo que más daño te hace
No te voy a entregar una lista de cuarenta mejoras para que elijas a ciegas. Los hallazgos van en tres bloques.
Primero, lo que puede tumbarte el negocio esta semana: pérdida de datos sin vuelta atrás, un fallo capaz de dejarlo todo caído, datos de clientes accesibles desde fuera. Segundo, lo que ya te cuesta dinero aunque no lo notes: lentitud que hace abandonar, errores intermitentes que nadie reporta, infraestructura sobredimensionada. Tercero, lo que te frena a futuro: no poder desplegar sin miedo, no poder meter a otra persona, no poder probar nada antes de subirlo.
Cada punto lleva horas estimadas. Tú decides hasta dónde llegamos y en qué orden. Se puede hacer solo el bloque uno y parar ahí.
Dejar de desplegar a mano y con miedo: entornos separados y despliegue automático
Si subes a producción arrastrando ficheros o haciendo un git pull por SSH un viernes, el problema no es la herramienta: es que no tienes red de seguridad. Lo que dejo montado son tres entornos separados con la misma configuración, para que lo que funciona en pruebas funcione arriba, y datos de prueba realistas pero sin información real de tus clientes.
El despliegue pasa a ser automático: se sube al repositorio, se ejecutan las comprobaciones y sale a producción sin que nadie toque un servidor. Con vuelta atrás en minutos, no en una tarde, y con control de quién puede desplegar. El objetivo no son las siglas: es que desplegar deje de ser un evento con nervios y pase a ser algo que haces un martes por la mañana.
Una copia de seguridad que nunca has restaurado no es una copia
Es la frase que más repito. Casi todos los proyectos que reviso tienen algo llamado copia de seguridad y casi ninguno la ha probado. Un fichero que nadie ha abierto en dos años no es una garantía, es un consuelo.
Aquí se define cada cuánto se copia, cuánto se guarda, dónde se guarda (fuera de la cuenta y del proveedor donde vive la aplicación) y qué entra, porque la base de datos sola no te sirve si pierdes los ficheros que suben tus usuarios.
Y luego lo que casi nadie hace: se restaura delante de ti, en un entorno limpio y con el cronómetro en marcha. Así sabes cuánto tardarías en volver y cuántos datos perderías en el peor caso. Esas dos cifras van escritas en la documentación.
Monitorización y avisos: enterarte tú antes de que te llame un cliente
Enterarte de que la aplicación está caída porque un cliente te escribe por WhatsApp es la peor forma de gestionar un servicio. Montamos comprobación de disponibilidad desde fuera, registro de errores con traza completa y contexto (qué usuario, qué pantalla, qué datos), métricas de latencia y de carga de base de datos, y avisos al canal que usas de verdad: correo, Telegram o Slack.
Los umbrales se ajustan para que suenen poco y en serio. Un aviso que salta cada día se ignora en dos semanas, y a partir de ahí es peor que no tener nada. Y va con un documento corto: qué significa cada aviso y qué hacer cuando salta, escrito para alguien que no construyó el sistema.
¿Se puede migrar un proyecto a producción sin parar el servicio?
En la mayoría de casos sí, y cuando no se puede te lo decimos antes, con la ventana concreta y la hora que menos te duele. Una migración seria no se improvisa: se ensaya primero sobre una copia completa, hasta que sale limpia dos veces seguidas.
Se bajan los tiempos de DNS con antelación. Los datos se migran con recuento y verificación en los dos lados, no con un parece que están todos. El sistema anterior se mantiene disponible hasta que el nuevo lleva días estable. Y hay plan de vuelta atrás escrito antes de empezar, con el punto exacto en el que se aborta si algo no cuadra.
Si tus usuarios tienen que enterarse, se avisa antes y con un mensaje claro. Lo que no hago es migrar un viernes por la tarde.
El código y la infraestructura quedan a tu nombre, no al mío
Esto no es un favor, es la condición de trabajo. Las cuentas de proveedor (hosting, base de datos, dominio, correo) van a nombre de tu empresa y las pagas directamente, sin reventa de por medio. El repositorio es tuyo y controlas quién entra. Las claves se rotan al terminar y se entregan en un gestor de contraseñas, no por correo.
Entregamos documentación escrita para humanos: cómo está montado, cómo se despliega, cómo se restaura una copia y qué se decidió y por qué. Añadimos una sesión de traspaso grabada y un periodo de acompañamiento tras la entrega, para lo que solo aparece con uso real. Si mañana el proyecto pasa a otro equipo, se lo lleva entero y funcionando.
Preguntas frecuentes
¿Qué es exactamente el escalado y la puesta en producción de una aplicación?+
Es coger un proyecto que ya funciona y ya tiene usuarios y dejarlo en condiciones de aguantar: entornos separados, despliegue automático, copias de seguridad verificadas, monitorización con avisos y registro de errores. No es rehacer la aplicación desde cero. Es estabilizar lo que hay y documentarlo para que cualquiera pueda mantenerlo después.
Mi app se cae con muchos usuarios, ¿basta con contratar un servidor más grande?+
Casi nunca. Un servidor más grande retrasa el problema unas semanas y te sube la factura. Lo habitual es una consulta sin índice, un listado que hace una consulta por fila, un pool de conexiones agotado o procesos pesados corriendo junto a las peticiones. Primero se mide dónde se va el tiempo.
¿Cuánto se tarda en estabilizar un proyecto que ya está en producción?+
Depende del estado real, y por eso el diagnóstico va primero y con alcance cerrado. Cuando salen los hallazgos, cada punto lleva sus horas estimadas y tú eliges hasta dónde llegar. Lo urgente (riesgo de perder datos, caídas totales, datos expuestos) se ataca antes que lo cómodo. Puedes hacer solo ese bloque y parar.
¿Hay que parar el servicio para migrar el proyecto a producción?+
En la mayoría de casos no hace falta cortar el servicio. La migración se ensaya antes sobre una copia completa, se bajan los tiempos de DNS con antelación, los datos se verifican con recuento en los dos lados y el sistema anterior se mantiene unos días. Si hiciera falta una parada, te decimos antes con la ventana concreta.
¿Trabajas con código hecho por otro desarrollador o generado con IA?+
Sí, es lo normal aquí. Llegan proyectos heredados, de un desarrollador que ya no está, o generados rápido con IA que funcionan en la demo y se rompen con uso real. No juzgamos el código: revisamos qué hay, priorizamos lo que rompe y lo arreglamos. Si algo no se puede salvar, te lo decimos claro.
¿Me quedo atado a ti después de la entrega?+
No. Las cuentas de hosting, base de datos y dominio van a nombre de tu empresa y las pagas tú. El repositorio es tuyo, las claves se entregan en un gestor de contraseñas y la documentación explica cómo desplegar y cómo restaurar una copia. Si te llevas el proyecto a otro desarrollador, se lo lleva entero.
Cuéntanos qué se está rompiendo
Escríbenos con dos cosas: qué se rompe y qué pasa cuando se rompe. Con eso ya te decimos si esto se arregla en una semana o si hay algo más gordo debajo. Si tu caso no es para nosotros, también te lo decimos, y te orientamos hacia dónde tirar. Sin reunión de una hora para venderte nada.
Pedir diagnóstico