Saltar al contenido
← Volver al blog
appsdesarrollo de software

¿Cuánto cuesta arreglar una app hecha con IA?

Qué define el precio de arreglar una app de Lovable, Bolt, v0, Replit o Cursor, los tres tamaños de arreglo, cómo se cobra y cómo pagar menos horas de trabajo.

Por Equipo Devonauts7 min de lectura
Read in English →
Manos hacen cuentas con una calculadora junto a una laptop y un cuaderno

Lo que cuesta arreglar una app hecha con Lovable, Bolt, v0, Replit o Cursor depende mucho más del problema que de la herramienta. Una configuración que falta puede resolverse en una hora; una app sin un modelo de permisos real puede llevar semanas. La única forma de tener un número honesto es un diagnóstico corto primero y un precio cerrado después.

En esta guía te explicamos qué mueve el precio, los tres tamaños de arreglo que más vemos, cómo se comparan las formas de cobro y qué puedes hacer tú antes de pedir ayuda para pagar menos horas.

¿Qué es lo que realmente define el precio?

Hay cinco factores que pesan más que todo lo demás.

  1. El tipo de problema. Una URL de redirección mal puesta y una base de datos sin permisos bien definidos se ven igual ("no puedo iniciar sesión"), pero una es un ajuste y la otra es un rediseño.
  2. Cuánta parte de la app toca. Un error en una pantalla sale más barato que un error en el modelo de datos del que dependen todas las pantallas.
  3. Si la persona que te ayuda puede ver todo. Si el código está en GitHub y la puedes invitar al backend, empieza a trabajar enseguida. Si el código vive solo dentro de una herramienta a la que no tiene acceso, primero hay que resolver eso.
  4. Si hay usuarios reales o dinero de por medio. Los arreglos que tocan pagos, datos personales o permisos necesitan más pruebas, porque un error ahí te cuesta clientes.
  5. Qué tan enredado está el código. Muchas rondas de "arréglalo" suelen dejar funciones duplicadas, código muerto y funciones a medio terminar. Desenredar eso también es parte del trabajo.

Fíjate en lo que no está en la lista: la herramienta. Lovable, Bolt, v0, Replit y Cursor terminan generando código normal (casi siempre React o Next.js en el frente, muchas veces con Supabase u otro backend parecido detrás). Alguien que conoce esas tecnologías puede trabajar sobre cualquiera de ellas.

¿Cuáles son los tres tamaños de arreglo?

Casi todos los pedidos caen en uno de estos tres grupos. Son tipos de trabajo, no una lista de precios: el mismo síntoma puede pertenecer a grupos distintos.

Pequeño: un ajuste o una pieza que falta

Ejemplos típicos:

  • El inicio de sesión funciona en la vista previa pero falla en tu dominio, porque las URL de redirección siguen apuntando a la dirección vieja.
  • Una tabla devuelve una lista vacía porque tiene Row Level Security activado y ninguna política permite leerla.
  • Se cambió una variable de entorno en el panel, pero nadie volvió a desplegar la app.
  • Un webhook de Stripe falla porque el secreto de firma es el del modo de prueba.

Una vez encontrados, estos se resuelven rápido. La mayor parte del tiempo se va en encontrarlos.

Mediano: una función que se rompe una y otra vez

Ejemplos típicos:

  • Los clientes pagan pero no reciben acceso, y nadie sabe en qué paso se pierde.
  • El registro, la recuperación de contraseña y la confirmación por correo funcionan para unos usuarios y para otros no.
  • Cada vez que le pides a la IA un cambio en una parte, se rompe otra.
  • La app se volvió lenta cuando empezó a tener datos reales.

Llevan más tiempo porque el arreglo tiene que aguantar el siguiente prompt, y eso casi siempre implica ordenar también el código alrededor del error.

Grande: hay que trabajar la base

Ejemplos típicos:

  • Cualquier usuario con sesión iniciada puede ver o editar los datos de otros, y hay que rediseñar los permisos tabla por tabla.
  • No hay separación entre pruebas y producción, y los datos reales conviven con los experimentos.
  • Quieres sacar la app del hosting o la base de datos de la herramienta y pasarla a cuentas tuyas.
  • El código está tan enredado que cualquier cosa nueva rompe otra.

Aquí es donde mucha gente pregunta si conviene empezar de cero. Rehacer todo casi nunca es la primera respuesta: tiras lo que funciona junto con lo que no, y una app rehecha con el mismo método puede terminar con los mismos problemas. Un buen diagnóstico te dice qué partes vale la pena conservar.

¿Cómo se comparan las formas de cobro?

Lo más común es encontrar una de estas cuatro.

ModeloCómo funcionaSirve paraOjo con
Por horaPagas el tiempo trabajadoInvestigaciones abiertasNo hay techo si no lo acuerdan
Precio cerrado por arregloUn precio por un resultado acordadoProblemas claros y bien descritosEl alcance tiene que quedar por escrito
Auditoría y luego precio cerradoUna revisión pagada y después precios por arregloCuando no sabes qué está malQue la auditoría incluya un informe escrito
Plan mensualHoras o ayuda continua cada mesApps con usuarios reales que siguen cambiandoQué pasa con las horas que no usas

Cobrar por hora sin un tope es la opción más riesgosa cuando el problema no está claro, porque la investigación puede alargarse mucho. Si eliges esa modalidad, acuerden un máximo antes de empezar y pide un aviso cuando se haya usado la mitad.

¿Por qué varían tanto los presupuestos para la misma app?

Dos personas pueden mirar la misma app y darte números muy distintos. Las razones más comunes:

  • Una revisó el código y la otra solo vio capturas de pantalla.
  • Una cotizó un parche para el síntoma y la otra un arreglo para la causa.
  • Una incluyó pruebas, despliegue y una explicación de lo que cambió; la otra no.
  • Una piensa reescribir la app en la tecnología que prefiere.

Cuando compares presupuestos, pregunta qué entregará exactamente cada persona, cómo lo va a probar y si recibirás un resumen escrito de los cambios. Un número más bajo que deja la causa intacta suele salir más caro después.

¿Cómo puedes pagar menos?

Casi todo el tiempo que se cobra se va en entender el problema. Buena parte de eso lo puedes adelantar tú.

  1. Describe el problema en cuatro líneas: qué haces, qué esperas, qué pasa en cambio y dónde pasa (vista previa, sitio publicado, celular, computadora).
  2. Junta la evidencia: el primer error rojo de la consola del navegador, el código de estado en la pestaña Network y la hora en que ocurrió. Nuestra guía sobre qué hacer si tu app de Lovable o Bolt dejó de funcionar lo explica paso a paso.
  3. Conecta el proyecto a GitHub para que el código se pueda revisar sin compartir pantalla.
  4. Crea una cuenta de prueba con datos falsos para quien te ayude, así nunca necesita tu usuario personal.
  5. No sigas pidiéndole cambios a la IA durante el arreglo. Dos personas (o una persona y una IA) cambiando el mismo código a la vez generan conflictos que luego pagas por desenredar.
  6. Ordena las prioridades. Di qué es urgente, qué puede esperar y qué no se puede tocar.

Algo más: nunca mandes contraseñas ni claves secretas para ahorrar tiempo. Invita a la persona a GitHub, a tu backend y a tu hosting con su propia cuenta, y quítale el acceso cuando termine. Lo explicamos con detalle en cómo contratar a un desarrollador para arreglar tu app.

¿Cuánto cobra Devonauts?

Publicamos nuestros precios para que puedas compararlos con cualquier otra oferta:

  • Chequeo gratis. Pegas la URL de tu app y recibes un informe automático de lo que se ve desde afuera.
  • Auditoría de rescate, $299 en un solo pago. Un ingeniero senior revisa el código y recibes un informe escrito en 2 días hábiles. Si no encuentra ningún problema de severidad media o alta, te devolvemos el total. Si empiezas un plan dentro de 30 días, los $299 se descuentan de tu primer mes.
  • Care, $249 al mes, y Care Plus, $749 al mes, para apps que necesitan arreglos continuos y alguien pendiente de ellas.
  • Dev Subscription, $2,900 al mes, cuando necesitas un desarrollador construyendo contigo de forma continua.

Los arreglos que salen de la auditoría tienen un precio cerrado que apruebas antes de que se toque nada. Una persona te responde en un día hábil como máximo. Todos los detalles están en nuestra página de precios.

Respuestas rápidas

¿Sale más barato rehacer la app desde cero? Normalmente no. La mayoría de las apps hechas con IA tienen muchas partes que funcionan. Arreglar la base y conservar el resto suele ser más rápido y más barato.

¿Puedo seguir usando Lovable, Bolt o Cursor después? Sí. La idea es que sigas construyendo con tu herramienta, sobre una base que no se caiga con el siguiente prompt.

¿La herramienta que usé cambia el precio? Muy poco. Lo que pesa es el problema, el tamaño de la app y cuánto acceso tiene quien te ayuda.

¿Y si la auditoría no encuentra nada grave? Con nuestra Auditoría de rescate, si no hay ningún problema de severidad media o alta, te devolvemos los $299.

¿No sabes qué necesita tu app?

Empieza por el chequeo gratis para ver lo que se nota desde afuera, y luego mira cómo funciona nuestro rescate de apps hechas con IA. Si usaste una herramienta en particular, tenemos páginas para Lovable, Bolt, Cursor, Replit y v0. O cuéntanos qué está fallando y te respondemos con una primera lectura y un precio antes de empezar.

¿Tu app sigue trabada?

Pasa el chequeo gratis con la URL de tu app, o pide la Auditoría de rescate de $299: un ingeniero senior revisa el código y te envía un informe escrito en 2 días hábiles.