Cuánto cuesta rescatar (arreglar) una app hecha con IA

Tu app de Lovable, Bolt o v0 tiene un problema: no publica bien, algo se rompe al primer uso real, o te has enterado de que los datos podrían estar a la vista de cualquiera. Sabes que hay que arreglarlo. Lo que no sabes es cuánto va a costar, y esa incertidumbre pesa tanto como el problema en sí: ¿son 300 € de una tarde, o 5.000 € porque hay que tirarlo todo y empezar de nuevo?

No es una pregunta rara. Es la primera que hace todo el mundo que llega con una app a medio construir y no sabe si lo que tiene por dentro es sólido o un castillo de naipes. Vamos a ver de qué depende el precio, qué rangos son razonables y por qué nadie serio te lo dice sin mirar antes el proyecto.

¿Por qué el precio varía tanto entre una app y otra?

Dos apps hechas con la misma herramienta, sobre el mismo tipo de proyecto, pueden necesitar arreglos que no se parecen en nada. Una tienda online montada con Bolt puede tener un solo fallo: la clave de conexión no se copió a producción, quince minutos de arreglo. Otra tienda, construida el mismo mes con la misma herramienta, puede tener ese mismo fallo más las políticas de acceso a datos desactivadas más un formulario que duplica pedidos cuando dos personas compran a la vez.

Por fuera, ambas apps "no funcionan en producción". Por dentro son proyectos completamente distintos. Eso es lo que hace imposible dar un precio de catálogo: la etiqueta "rescate de app hecha con IA" cubre desde una tarde de trabajo hasta varias semanas, y solo se sabe cuál es mirando el proyecto en concreto.

Esta tabla ayuda a situarte según el tipo de problema que tengas:

Son rangos para hacerte una idea, no una tarifa cerrada: tu proyecto puede caer fuera en cualquier dirección, y lo normal es que un rescate combine más de una fila de esta tabla a la vez.

Si quieres saber primero si tu caso es de la fila uno o de la fila tres, antes incluso de hablar de precio, manda el enlace de tu proyecto y lo miramos sin compromiso: el diagnóstico dice qué de esta tabla te toca antes de dar ningún número.

¿Qué hace que un rescate salga más caro de lo esperado?

Casi nunca es que el presupuesto suba a mitad de camino. Es que el problema real resulta ser más grande que el síntoma que lo hizo visible. La pantalla en blanco que viste tú puede ser la punta de tres problemas distintos debajo, como pasa con una app que va bien en la demo y se rompe al publicarla: arreglas la clave que faltaba, y debajo aparece que la app seguía apuntando a la base de datos de pruebas, y debajo de eso, que nadie probó qué pasa con el volumen real de datos.

Cada capa que aparece no es un intento de cobrarte más: es información nueva sobre el estado real del proyecto, y por eso el diagnóstico previo importa tanto como el arreglo en sí. Un diagnóstico serio no se limita a mirar el síntoma que trajiste, revisa también lo que no se ve a simple vista —como si los datos de tu app están de verdad protegidos— para que el precio que te den incluya todo lo que hay que tocar, no solo lo primero que saltó.

La otra causa habitual de sorpresas es al revés: querer aprovechar el rescate para añadir algo nuevo ("ya que estamos, metemos también..."). Eso no es rescatar, es un encargo nuevo encima del arreglo, y conviene tratarlo como una fase aparte con su propio número, no colarlo dentro del presupuesto del arreglo.

Un caso con números

Pongamos un caso tipo, inventado para que se entienda. Una academia monta con Bolt una app de matrículas, la publica y funciona: los profesores entran, ven las listas, cobran. Un día alguien les avisa de que quizá los datos de los alumnos no están tan protegidos como piensan.

El diagnóstico encuentra dos cosas. Primero, un problema de configuración menor: la app seguía enviando el correo de confirmación desde la cuenta de pruebas del desarrollador, no desde la de la academia (arreglo de una tarde, unos 400 €). Segundo, el problema de verdad: las políticas de acceso a la tabla de alumnos estaban desactivadas, así que cualquiera con la clave pública de la app podía leer los 300 registros completos —nombre, teléfono, qué habían pagado. Cerrar eso bien, con sus políticas probadas una por una, sale por unos 900 €.

Total: alrededor de 1.300 €, resuelto en unos días. La academia había pedido antes un presupuesto de "rehacer la app entera con otro proveedor" y le habían dicho 6.000 €, porque ese proveedor no había mirado qué estaba roto de verdad, solo había asumido que si algo falla, se empieza de cero. Son cifras de ejemplo para ilustrar la lógica, no una tarifa: lo que no cambia es que el precio lo pone lo que hay que arreglar, no la sensación de que "algo va mal" con la app entera.

¿Rescatar o rehacer desde cero?

La mayoría de las veces, rescatar. Rehacer desde cero solo compensa cuando el diagnóstico deja claro que la base es tan frágil que cada cambio rompe algo distinto, no antes de mirarlo. Incluso en ese caso, "rehacer" casi nunca significa la aplicación entera: significa la pieza concreta que se ha vuelto imposible de tocar sin que todo lo demás se caiga.

Una forma rápida de orientarte antes del diagnóstico:

• Si el síntoma es "no publica" o "un aviso de error" → probablemente configuración, la parte más barata de arreglar.
• Si el síntoma es "no sé si mis datos están seguros" → seguridad, coste medio, y conviene mirarlo aunque no haya ningún error visible.
• Si el síntoma es "cada cambio que pido rompe otra cosa" → base frágil, y ahí es donde de verdad compensa que alguien mire el conjunto antes de seguir añadiendo capas encima.

Cuándo pedir el número real

Cualquier rango de los de arriba sirve para hacerte una idea, no para presupuestar tu proyecto: eso solo sale de ver el proyecto en concreto. Si tienes una app hecha con IA que no llega a producción o no sabes si está protegida de verdad, mándanos el enlace y te decimos qué hay, qué falta y cuánto cuesta dejarlo andando, con cifra cerrada. Si prefieres escribir directamente: contact@easybyte.es.