Consertamos sites, apps e sistemas feitos com IA que não funcionam

Ficou pronto rápido e começou a falhar quando entrou usuário de verdade. A gente abre o código, acha o que está errado e deixa funcionando, com banco e infraestrutura revisados.

Diagnóstico e correção de sites, aplicativos e sistemas feitos com ferramentas de IA ou vibe coding que dão erro, não aguentam mais usuários ou que ninguém consegue manter, com revisão de banco de dados, infraestrutura, testes e documentação.

O que entregamos

  • Diagnóstico do código
  • Banco & Infra
  • Correção em produção
  • Testes & Documentação

Público atendido: Empresas e fundadores com software feito com IA que falha em produção

Por que o MRecovery

  • Diagnóstico antes do orçamento — Você recebe um relatório do que está quebrado, por que quebra e quanto custa corrigir. Só depois decide.
  • Sem recomeçar do zero — Aproveitamos o que funciona. Reescrever é a última opção, e quando acontece é em uma parte só.
  • Código que outra pessoa entende — Entregamos repositório organizado, testes e documentação. O sistema deixa de depender de quem fez.

O que é o MRecovery

MRecovery é a frente da MFactor que recupera software feito com inteligência artificial. Lovable, Bolt, v0, Cursor, um freelancer colando código do ChatGPT: o caminho não importa. O que chega aqui é um sistema que foi prometido, que até funcionou na demonstração e que não aguentou o uso.

A IA escreve código rápido, e isso é bom. O problema é que ela escreve o que foi pedido, não o que o sistema precisa. Ela não sabe que a tabela de pedidos vai ter 200 mil linhas em um ano, que o CPF precisa de validação, que a senha não pode ir para o banco em texto puro, que o plano grátis da hospedagem não aguenta a Black Friday. Quem sabe disso é engenheiro. Quando não tem engenheiro no projeto, ninguém toma essas decisões, e a conta chega quando o sistema já tem gente dependendo dele.

O resultado tem cara conhecida. Funciona com dez usuários e cai com cem. Uma tela demora oito segundos porque consulta o banco uma vez por linha. Mistura o dado de um cliente com o de outro. O site saiu igual a outros mil, porque a IA desenha o que é mais comum. E tem o SaaS que fatura, com cliente pagando todo mês, e que não consegue crescer porque cada funcionalidade nova quebra duas antigas.

Sinais de que o sistema precisa de recuperação

  • O erro volta de outro jeito — Você pede para a IA corrigir, ela mexe em outra parte, e o problema reaparece numa tela diferente. Sem teste, cada correção é uma aposta.
  • Cai quando entra gente — Rodou bem na demonstração. Com cinquenta pessoas ao mesmo tempo, trava, demora ou derruba o servidor.
  • Dado que some ou se mistura — Um cliente vê o pedido do outro. Um cadastro desaparece. Não tem log para saber quando aconteceu nem por quê.
  • Site igual a todos os outros — O layout é o que a ferramenta entrega para qualquer um. Ninguém reconhece a sua marca nele, e o Google também não.
  • Fatura, mas não cresce — Tem cliente pagando todo mês, mas qualquer mudança no código vira um susto. O time tem medo de mexer.
  • Ninguém sabe o que tem lá dentro — Quem fez saiu, ou foi a IA. Não existe documentação, teste nem repositório organizado para alguém assumir.

O que a recuperação inclui

  • Diagnóstico — lemos o código, o banco e a infraestrutura e dizemos o que está errado, em ordem de risco.
  • Correção — erros, consultas lentas e falhas de segurança, começando pelo que derruba o sistema.
  • Banco de dados — estrutura, índices, migrações e backup. É onde os sistemas feitos com IA costumam estar mais frágeis.
  • Infraestrutura — hospedagem, variáveis de ambiente, logs, monitoramento e custo. O sistema sai do plano grátis em que já não cabe.
  • Testes e versionamento — o mínimo para a próxima mudança não quebrar a anterior.
  • Documentação — o que o sistema faz e como rodar, para não depender de quem fez nem de quem consertou.

Como funciona

  • 1. Acesso e leitura — Você dá acesso ao código, ao banco e à hospedagem. A gente lê tudo antes de opinar e não altera nada nessa fase.
  • 2. Relatório de diagnóstico — O que está quebrado, por que quebra e o que acontece se ficar como está, em ordem de risco. Cada item com o custo da correção.
  • 3. Estabilização — Primeiro o que derruba o sistema ou vaza dado. Backup do banco antes de qualquer mudança em produção.
  • 4. Banco e infraestrutura — Índices, consultas, migrações e backup. Hospedagem dimensionada para o uso real, com logs e monitoramento.
  • 5. Testes e repositório — O código vai para um repositório organizado, com testes nas partes críticas e revisão a cada mudança.
  • 6. Entrega e continuidade — Documentação do que foi feito e de como rodar. Depois você escolhe: seguir com o seu time ou com a MFactor cuidando da operação.

Para quem é

Se o sistema não tem salvação, a gente diz. Às vezes a resposta certa é reconstruir uma parte com o MLabs e aproveitar o resto. Mas isso vem depois do diagnóstico, não antes.

  • Donos de negócio — que contrataram um sistema, pagaram e receberam algo que não faz o combinado.
  • Fundadores de SaaS — com produto no ar e clientes pagando, que não conseguem lançar nada novo sem quebrar o que existe.
  • Empresas — que montaram uma ferramenta interna com IA e hoje dependem dela mais do que ela aguenta.
  • Agências e freelancers — que entregaram um projeto feito com IA e precisam de engenharia para honrar a entrega.

Perguntas frequentes

O sistema foi feito no Lovable, no Bolt ou no Cursor. Vocês conseguem mexer?

Sim. Essas ferramentas geram código comum, em geral React, Node e Supabase ou Firebase. O que muda é que ele vem sem a estrutura que um time de engenharia colocaria: sem testes, sem separação de ambientes e com o banco aberto demais. A gente leva o código para um repositório e trabalha nele como em qualquer projeto.

Preciso reconstruir tudo do zero?

Na maioria dos casos, não. O diagnóstico separa o que funciona do que precisa ser refeito, e reescrever é a última opção. Quando uma parte não tem salvação, a gente reconstrói só ela, com o MLabs, e integra ao resto.

Quanto custa recuperar um sistema?

Depende do estado em que ele está, e por isso a gente só fecha preço depois do diagnóstico. O diagnóstico tem escopo fechado, e o relatório fica com você mesmo que decida não seguir com a correção.

O sistema está no ar com clientes. Vocês precisam tirar o sistema do ar para consertar?

Não. Trabalhamos num ambiente de homologação separado da produção, e as mudanças entram em janelas combinadas, com backup antes. O sistema continua atendendo durante a recuperação.

E se eu não tiver acesso ao código?

Acontece quando o projeto foi feito por terceiros. A gente orienta como pedir o repositório e as credenciais, e o que fazer se eles não vierem. Com acesso ao banco e à hospedagem já dá para começar o diagnóstico.

Depois de recuperado, quem cuida do sistema?

Você escolhe. Entregamos o repositório, a documentação e o ambiente para o seu time assumir, ou a MFactor segue cuidando da operação pelo MHost, com monitoramento e suporte.

Vocês atendem empresas de Leme e do interior de SP?

Sim. A MFactor fica em Leme e atende empresas de Pirassununga, Araras, Rio Claro, Limeira, Piracicaba, Campinas e de todo o Brasil. O trabalho é remoto, com acesso ao código e à hospedagem, e a reunião pode ser presencial quando a empresa é da região.

Contato