Arreglamos sitios, apps y sistemas hechos con IA que no funcionan

Quedó listo rápido y empezó a fallar cuando llegaron usuarios de verdad. Abrimos el código, encontramos lo que está mal y lo dejamos funcionando, con la base de datos y la infraestructura revisadas.

Diagnóstico y corrección de sitios, aplicaciones y sistemas hechos con herramientas de IA o vibe coding que dan errores, no aguantan más usuarios o que nadie logra mantener, con revisión de base de datos, infraestructura, pruebas y documentación.

Lo que entregamos

  • Diagnóstico del código
  • Base de datos & Infra
  • Corrección en producción
  • Pruebas & Documentación

Para quién es: Empresas y fundadores con software hecho con IA que falla en producción

Por qué MRecovery

  • Diagnóstico antes del presupuesto: Recibes un informe de lo que está roto, por qué se rompe y cuánto cuesta corregirlo. Solo después decides.
  • Sin empezar de cero: Aprovechamos lo que funciona. Reescribir es la última opción, y cuando hace falta, es solo una parte.
  • Código que otra persona entiende: Entregamos un repositorio ordenado, pruebas y documentación. El sistema deja de depender de quien lo hizo.

Qué es MRecovery

MRecovery es el área de MFactor que rescata software hecho con inteligencia artificial. Lovable, Bolt, v0, Cursor, un freelancer pegando código de ChatGPT: da igual cómo se hizo. Lo que nos llega es un sistema que alguien prometió, que hasta funcionó en la demostración y que no aguantó el uso.

La IA escribe código rápido, y eso es bueno. El problema es que escribe lo que se le pidió, no lo que el sistema necesita. No sabe que la tabla de pedidos va a tener 200.000 filas en un año, que el número de identificación fiscal necesita validación, que la contraseña no puede ir a la base de datos en texto plano ni que el plan gratuito del hosting no aguanta el Black Friday. Eso lo sabe un ingeniero. Cuando no hay un ingeniero en el proyecto, nadie toma esas decisiones, y la cuenta llega cuando el sistema ya tiene gente que depende de él.

Los síntomas se repiten. Funciona con diez usuarios y se cae con cien. Una pantalla tarda ocho segundos porque consulta la base de datos una vez por fila. Mezcla los datos de un cliente con los de otro. El sitio salió igual a otros mil, porque la IA diseña lo más común. Y está el SaaS que factura, con clientes pagando todos los meses, y que no puede crecer porque cada funcionalidad nueva rompe dos viejas.

Señales de que el sistema necesita recuperación

  • El error vuelve de otra forma: Le pides a la IA que lo corrija, toca otra parte y el problema vuelve a aparecer en una pantalla distinta. Sin pruebas, cada corrección es una apuesta.
  • Se cae cuando llega gente: Funcionó bien en la demostración. Con cincuenta personas al mismo tiempo, se congela, se pone lento o hace caer el servidor.
  • Datos que se pierden o se mezclan: Un cliente ve el pedido de otro. Un registro desaparece. No hay logs para saber cuándo pasó ni por qué.
  • Un sitio igual a todos los demás: El diseño es el que la herramienta le entrega a cualquiera. Nadie reconoce tu marca ahí, y Google tampoco.
  • Factura, pero no crece: Hay clientes pagando todos los meses, pero cualquier cambio en el código es un susto. El equipo tiene miedo de tocarlo.
  • Nadie sabe qué hay adentro: Quien lo hizo ya no está, o fue la IA. No hay documentación, pruebas ni un repositorio ordenado para que alguien se haga cargo.

Qué incluye la recuperación

  • Diagnóstico: leemos el código, la base de datos y la infraestructura y te decimos qué está mal, en orden de riesgo.
  • Corrección: errores, consultas lentas y fallas de seguridad, empezando por lo que hace caer el sistema.
  • Base de datos: estructura, índices, migraciones y backup. Es donde los sistemas hechos con IA suelen ser más frágiles.
  • Infraestructura: hosting, variables de entorno, logs, monitoreo y costo. El sistema sale del plan gratuito en el que ya no cabe.
  • Pruebas y control de versiones: lo mínimo para que el próximo cambio no rompa el anterior.
  • Documentación: qué hace el sistema y cómo ponerlo en marcha, para no depender de quien lo hizo ni de quien lo arregló.

Cómo funciona

  • 1. Acceso y lectura: Nos das acceso al código, a la base de datos y al hosting. Leemos todo antes de opinar y no cambiamos nada en esta etapa.
  • 2. Informe de diagnóstico: Qué está roto, por qué se rompe y qué pasa si lo dejas como está, en orden de riesgo. Cada punto con lo que cuesta corregirlo.
  • 3. Estabilización: Primero lo que hace caer el sistema o filtra datos. Backup de la base de datos antes de cualquier cambio en producción.
  • 4. Base de datos e infraestructura: Índices, consultas, migraciones y backup. Hosting dimensionado para el uso real, con logs y monitoreo.
  • 5. Pruebas y repositorio: El código pasa a un repositorio ordenado, con pruebas en las partes críticas y revisión en cada cambio.
  • 6. Entrega y continuidad: Documentación de lo que se hizo y de cómo ponerlo en marcha. Después eliges: seguir con tu equipo o con MFactor a cargo de la operación.

Para quién es

Si el sistema no tiene salvación, te lo decimos. A veces la respuesta correcta es reconstruir una parte con MLabs y aprovechar el resto. Pero eso viene después del diagnóstico, no antes.

  • Dueños de negocio: que contrataron un sistema, pagaron y recibieron algo que no hace lo acordado.
  • Fundadores de SaaS: con el producto en línea y clientes pagando, que no pueden lanzar nada nuevo sin romper lo que ya existe.
  • Empresas: que armaron una herramienta interna con IA y hoy dependen de ella más de lo que aguanta.
  • Agencias y freelancers: que entregaron un proyecto hecho con IA y necesitan ingeniería para responder por lo que entregaron.

Preguntas frecuentes

El sistema se hizo en Lovable, Bolt o Cursor. ¿Pueden trabajar en él?

Sí. Esas herramientas generan código común, por lo general React, Node y Supabase o Firebase. Lo que cambia es que viene sin la estructura que pondría un equipo de ingeniería: sin pruebas, sin separación de entornos y con la base de datos demasiado abierta. Llevamos el código a un repositorio y trabajamos en él como en cualquier proyecto.

¿Tengo que reconstruir todo desde cero?

En la mayoría de los casos, no. El diagnóstico separa lo que funciona de lo que hay que rehacer, y reescribir es la última opción. Cuando una parte no tiene arreglo, reconstruimos solo esa parte, con MLabs, y la integramos al resto.

¿Cuánto cuesta rescatar un sistema?

Depende del estado en que esté, y por eso solo definimos el precio después del diagnóstico. El diagnóstico tiene un alcance cerrado, y el informe queda contigo aunque decidas no seguir con la corrección.

El sistema está en línea y tiene clientes. ¿Tienen que sacarlo de línea para arreglarlo?

No. Trabajamos en un entorno de pruebas (staging) separado de producción, y los cambios entran en ventanas acordadas, con backup antes. El sistema sigue funcionando durante el rescate.

¿Y si no tengo acceso al código?

Pasa cuando el proyecto lo hizo un tercero. Te explicamos cómo pedir el repositorio y las credenciales, y qué hacer si no llegan. Con acceso a la base de datos y al hosting ya se puede empezar el diagnóstico.

Una vez rescatado, ¿quién se encarga del sistema?

Tú eliges. Entregamos el repositorio, la documentación y el entorno para que tu equipo se haga cargo, o MFactor sigue operándolo con MHost, con monitoreo y soporte.

¿Atienden a empresas de Leme y del interior de São Paulo?

Sí. MFactor está en Leme y atiende a empresas de Pirassununga, Araras, Rio Claro, Limeira, Piracicaba, Campinas y de todo Brasil. El trabajo es remoto, con acceso al código y al hosting, y la reunión puede ser presencial cuando la empresa es de la región.

Contacto