# 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. URL: https://www.mfactor.dev/mrecovery Site: MFactor — https://www.mfactor.dev 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 - WhatsApp: https://wa.me/5519997789831 (+55 (19) 99778-9831) - E-mail: alexandre.martins@mfactor.dev - Localização: Leme, SP — Brasil