Tu app hecha con IA va bien con pocos usuarios y se cae con tráfico real: qué mirar

Montaste tu app con Lovable, Bolt, v0 o Cursor. La probaste tú, la probaron cuatro amigos, todo iba fino. Llegó el día bueno —una campaña, una mención, el lanzamiento de verdad— y entre 50 y 300 personas la usaron a la vez. Y ahí empezó a ir lenta, o a tardar cada vez más, o directamente se cayó. Lo raro es que nadie tocó nada: la app es la misma que ayer.

No es mala suerte ni un fallo puntual del servidor. Es que hay un tramo entero de "cómo se comporta la app con datos y gente de verdad" que ni tú ni el editor probasteis nunca, porque no hacía falta hasta ese momento. Vamos a ver qué suele romperse, cómo distinguir el síntoma de la causa, y qué se puede comprobar antes de que pase.

¿Por qué funciona con pocos usuarios y se cae con tráfico real?

Piensa en una carretera de un solo carril. Con cinco coches va perfecta, nadie nota nada raro. Con quinientos, el mismo carril que antes sobraba se convierte en un atasco: no es que la carretera se haya roto, es que nunca estuvo pensada para ese volumen y el problema solo aparece cuando el tráfico llega.

Con una app pasa lo mismo con tres cosas que casi nunca se prueban antes del lanzamiento:

• Cuántos datos hay. Una consulta a la base de datos que tarda 10 milisegundos con 50 registros puede tardar 3 segundos con 50.000, si nadie le puso un índice (una especie de índice de libro que le dice a la base de datos dónde buscar sin repasar cada página).
• Cuánta gente a la vez. Una app que responde bien a una persona puede no responder igual a 200 personas pidiéndole cosas en el mismo segundo, sobre todo si cada petición dispara varias llamadas por debajo sin que se vea desde fuera.
• Los límites de lo que hay detrás. Tu app no vive sola: habla con una pasarela de pago, un servicio de correo, quizá una IA. Todos esos servicios tienen un límite de cuántas peticiones aceptan por minuto, y una demo con dos personas nunca lo toca. Un lanzamiento sí.

Ninguna de las tres se ve en el editor, porque el editor trabaja con datos de ejemplo y contigo solo. Por eso la app "funcionaba" hasta el día que de verdad importaba.

Qué síntoma indica qué problema

Esta tabla empareja lo que ves con lo que suele estar pasando por debajo:

Si quieres saber antes de publicitar tu app qué de esta tabla te tocaría a ti, lo miramos sin compromiso y te decimos qué hay, qué aguanta y qué no: el diagnóstico dice qué toca antes de dar ningún número.

Las dos causas que más se repiten

De los cuatro síntomas de arriba, dos aparecen con mucha más frecuencia que los otros.

La primera es la consulta sin índice, y suele venir acompañada de su prima: la app que, para pintar una lista de 50 elementos, hace 50 consultas por separado (una por cada elemento) en vez de una sola que traiga los 50 de golpe. Con pocos elementos no se nota nada; con cientos, cada pantalla se convierte en cientos de idas y venidas a la base de datos, y ahí es donde la lentitud se vuelve visible para el usuario.

La segunda es la falta de paginación: pantallas que cargan absolutamente todo lo que hay (todos los pedidos, todos los clientes, todo el historial) en vez de traer los primeros 20 y el resto según se necesite. Con 30 registros de prueba es indistinguible de traer solo 20. Con 5.000 registros reales, esa misma pantalla puede tardar minutos en cargar, o directamente colgarse.

Las dos comparten algo importante: no son errores de programación en el sentido de "código roto". Son decisiones que funcionan perfectamente con poco volumen y dejan de funcionar con mucho, y solo se detectan probando con datos parecidos a los reales, no con los tres de ejemplo que trae el editor por defecto.

Un caso con números

Pongamos un caso tipo, inventado para que se entienda. Un restaurante monta con Lovable una app de reservas online. En las pruebas, cinco personas del equipo hacen una reserva cada una: todo perfecto, la pantalla responde al instante.

El restaurante hace una promoción en redes y en dos horas le llegan 300 reservas. La pantalla de "ver reservas del día", que en las pruebas cargaba 5 registros en un parpadeo, ahora tiene que traer 300 y los trae todos de golpe, sin paginar: la carga pasa de menos de medio segundo a 8-9 segundos, y en el momento de más gente algunas peticiones directamente se agotan y fallan. A la vez, cada reserva dispara por debajo tres consultas separadas para comprobar disponibilidad, mesa y horario, así que 300 reservas simultáneas son 900 consultas en vez de una manejable.

El diagnóstico encuentra exactamente eso: falta un índice en la tabla de reservas (arreglo de una tarde) y la pantalla de listado no pagina (medio día de trabajo). Ninguna de las dos cosas obliga a tocar el resto de la app. Son cifras de ejemplo para ilustrar la lógica, no una tarifa: lo que no cambia es que el problema estaba localizado en dos puntos concretos, no repartido por toda la aplicación.

¿Se puede comprobar esto antes de lanzar?

En buena parte, sí, y es mucho más barato hacerlo antes que después del susto. Antes de una campaña o un lanzamiento importante, tiene sentido pedir (o hacer, si tienes cómo) dos cosas:

• Meter datos de volumen parecido al real en un entorno de pruebas, no los tres registros de ejemplo del editor. Si tu negocio va a manejar miles de pedidos, prueba con miles, no con diez.
• Simular varias personas usando la app a la vez, no una sola persona probando con calma. La mayoría de estos problemas solo aparecen cuando hay concurrencia, es decir, gente pidiendo cosas al mismo tiempo.

Esto no hace falta hacerlo cada semana, pero sí antes de cualquier momento en el que esperes un pico: un lanzamiento, una campaña de publicidad, una mención en prensa. Es la diferencia entre descubrir el problema en una prueba controlada o descubrirlo con clientes de verdad mirando la pantalla girando.

¿Y si ya se ha caído?

Si ya te ha pasado, lo primero es no entrar en pánico ni asumir que hay que rehacer la app entera: casi nunca es así. Lo que hace falta es un diagnóstico que diga exactamente qué consulta, qué pantalla o qué límite externo fue el que no aguantó, y arreglar eso en concreto. Es el mismo enfoque que cuando una app va bien en la demo y se rompe al publicarla: el síntoma se ve entero, la causa está en un punto muy concreto.

Si tienes una app hecha con IA que se ha quedado lenta o se ha caído con tráfico real, mándanos el enlace o el repositorio y te decimos qué aguanta, qué no y qué costaría dejarlo resuelto, con cifra cerrada. Si prefieres escribir directamente: contact@easybyte.es.