Dá para montar um CRM (sistema que organiza contatos e vendas) completo sem contratar desenvolvedor, partindo de código-fonte pronto e ajustando com IA — o gasto real vira infraestrutura, não mão de obra. Hoje isso custa R$43,99 por mês de aluguel do computador onde ele roda, dividido com outros dois sistemas. O resto do custo foi tempo, não dinheiro.
Não teve orçamento de agência nem fatura de freelancer. O sistema roda em produção há semanas, atendendo leads de verdade. Lead é a pessoa que deixou o contato e pode virar cliente. E o que ele custou de fato só ficou claro depois de rodar por um tempo, não no dia em que “ficou pronto”.
O que significa construir sem contratar desenvolvedor?
Significa partir de um código-fonte que já existe e ajustar, corrigir e estender esse código com IA. Nesse caso, a base foi um template (um modelo pronto) de CRM já usado por outra operação. A ferramenta foi o Claude Code, uma IA que escreve e roda o código. Não se abriu vaga nem se contratou por job.
O ponto não é “a IA escreveu tudo do zero sozinha”. É que não existiu curva de aprendizado de linguagem nem reunião de escopo com terceiro. O pedido virava código no mesmo dia, testado na hora.
Quanto custa de infraestrutura, de verdade?
O único custo recorrente e mensurável é o servidor (o computador ligado 24 horas onde o sistema fica no ar). No caso, um VPS (servidor virtual privado: um pedaço de um computador grande, alugado só para você) de nível básico.
O plano KVM 2 na Hostinger custa hoje R$43,99 por mês na tabela oficial, com preço promocional aplicado. Esse valor não é exclusivo do CRM. No mesmo servidor rodam mais dois processos além dele, dividindo o custo sem dividir a fatura.
| Item | Custo |
|---|---|
| Servidor (VPS, plano básico) | R$43,99/mês (tabela atual) |
| Mão de obra de desenvolvedor | R$0 — nenhuma contratação |
| Licença de banco de dados | R$0 — SQLite (banco de dados que cabe num arquivo só), sem custo de licença |
| Tempo de configuração inicial | 1 sessão de trabalho, num único dia |
O que quebrou no meio do caminho?
Duas coisas quebraram de verdade, e nenhuma delas era o código do CRM em si.
A primeira foi uma peça pronta de que o sistema depende. A biblioteca que lê e grava o banco de dados local (better-sqlite3) não tinha versão pré-compilada (já montada, pronta para usar) para a versão mais nova do Node.js (o motor que faz o sistema funcionar). Então tentou se montar na hora. Isso exige um compilador C++ que não estava instalado.
O conserto foi trocar para a versão mais recente da mesma biblioteca. Ela já vem pré-compilada e não depende de compilador nenhum. Fica o aviso: se um dia o Node.js for trocado de versão, o mesmo tropeço pode voltar.
A segunda foi mais séria. O código baixado para editar localmente não era um repositório Git de verdade (o histórico organizado de todas as versões do código). Era só um arquivo compactado.
E o servidor de produção tinha etiquetas de cliente, como “cliente ativo” ou “cancelado”, que não existiam em nenhuma cópia fora dele. Subir o código local por cima do servidor, sem checar isso antes, teria apagado essas etiquetas sem deixar rastro.
Por que não dá para confiar em produção sem repositório de código organizado?
Porque ninguém sabe ao certo o que existe só lá. Essa foi a lição que ficou. Antes de qualquer envio de código para um servidor em produção, o primeiro passo virou olhar o que já existe lá. Histórico de versão, configuração, dado que não está em lugar nenhum fora daquele servidor. E nunca sobrescrever sem comparar.
Um exemplo menor do mesmo tipo de problema: seis de sete formulários de captura de lead estavam configurados sem etiqueta de entrada. Isso só apareceu quando alguém contou manualmente — apenas dois de sete leads estavam etiquetados na tela. Não era bug de código, era configuração vazia que ninguém tinha ido conferir.
Como subir uma mudança sem apagar o que já está no ar?
O roteiro de atualização que ficou documentado tem uma ordem fixa. Nenhum passo pula o anterior:
- Olhar antes de tocar. No servidor, conferir o histórico e o que mudou lá desde a última versão. Alguém pode ter ajustado algo à mão.
- Fazer cópia de segurança do banco de dados. Se der errado, há para onde voltar.
- Trazer a versão nova do código, só depois de comparar com o que está lá.
- Aplicar os ajustes na estrutura do banco, quando a versão nova pedir.
- Reiniciar o sistema e conferir que ele voltou.
Uma regra vale em todos os passos: o arquivo com as senhas do sistema nunca sobe junto. O servidor tem o dele. Cada instalação, inclusive a do computador de quem edita, tem suas próprias chaves e seu próprio banco.
Vale mais montar do zero ou partir de um template pronto?
Partir de um código já existente encurtou o tempo de semanas para um único dia de configuração inicial. Mas trouxe justamente esse tipo de risco: peça escondida de que o sistema depende, dado de produção que a cópia local não tem e comportamento que só o servidor real conhece.
Como esse caminho se compara a montar do zero ou comprar um sistema pronto está detalhado em comprar um sistema pronto ou construir o meu com IA.
Quando vale esse caminho — e para quem ele não serve?
Ele se aplica bem nos seguintes casos:
- Negócio que já tem um CRM de código aberto ou um template para partir, em vez de começar do zero.
- Quem aceita pagar em tempo o que deixaria de pagar em mensalidade ou em desenvolvedor.
- Quem pode dividir um servidor com outros sistemas, como aconteceu aqui com mais dois processos.
Ele não serve bem para quem precisa de alguém de plantão quando o sistema cai. Aqui, a manutenção é de quem construiu. Também não serve para quem vai mexer em produção sem cópia de segurança e sem olhar o histórico antes. Foi exatamente esse atalho que quase apagou as etiquetas dos clientes.
Como resolver isso com IA, passo a passo?
1. O que construir. Uma skill no Claude (um conjunto de instruções salvas que a IA segue sempre do mesmo jeito) chamada “atualizar CRM com segurança”. Ela transforma o roteiro de cinco passos deste artigo em regra fixa. Antes de qualquer envio, ela lista o que existe só no servidor, faz a cópia do banco e só então sobe a versão nova. Quem roda é o Claude Code, a mesma ferramenta usada para ajustar o CRM.
2. O pedido pronto para copiar. O pedido que recomendamos colar no Claude Code:
“Crie uma skill chamada ‘atualizar CRM com segurança’. Toda vez que eu pedir para subir uma mudança no servidor, siga esta ordem e não pule nenhum passo: 1) entre no servidor e me mostre o que mudou lá desde a última versão, incluindo etiquetas, formulários e configurações que não existem na minha cópia local; 2) faça uma cópia de segurança do banco de dados e me diga onde ela ficou; 3) compare o código novo com o que está no servidor e me mostre as diferenças antes de enviar; 4) aplique os ajustes na estrutura do banco só se a versão nova pedir; 5) reinicie o sistema e confira que ele voltou. Nunca envie o arquivo de senhas. Se encontrar algo que só existe no servidor, pare e me pergunte. Explique cada passo como se eu nunca tivesse programado.”
Como conferir se a skill acertou antes de mexer no servidor real?
3. O teste das etiquetas. Use os dois tropeços deste artigo como prova. Primeiro: numa cópia de teste do servidor, crie uma etiqueta de cliente que não existe na cópia local, do mesmo jeito que “cliente ativo” só existia lá. A skill certa para no passo 1 e mostra essa etiqueta antes de enviar qualquer coisa. Segundo: peça para ela contar os formulários de captura sem etiqueta de entrada. No caso deste artigo, a resposta certa era seis de sete. Se ela subir o código sem avisar da etiqueta, está reprovada.
Quanto custa e quanto tempo leva para montar essa skill?
4. Custo e tempo. O servidor continua sendo o custo do artigo: R$43,99 por mês no plano KVM 2 da Hostinger, dividido com outros dois sistemas.
Para usar o Claude Code, a página oficial de preços do Claude, vista do Brasil em 02/10/2026, mostra o plano Pro a R$ 110 no mensal ou R$ 92 por mês no anual (R$ 1.100 de uma vez). O plano Free é R$ 0, mas não inclui o Claude Code. A página avisa que os preços não incluem impostos aplicáveis.
O tempo de referência é o do próprio caso: a configuração inicial do CRM coube em uma sessão de trabalho, num único dia. O tempo para escrever e testar a skill depende do seu sistema; não medimos esse número à parte.
O que a gente faria no seu lugar?
Nós partiríamos de um template pronto, e não do zero. O motivo é o próprio número do caso: a configuração inicial coube em um dia, e o custo fixo ficou em R$43,99 por mês, dividido com outros dois sistemas.
Mas trataríamos o servidor de produção como a única fonte de verdade desde o primeiro dia. Antes de qualquer envio, olharíamos o histórico e faríamos cópia do banco. E deixaríamos essa ordem gravada na skill “atualizar CRM com segurança”, para a IA cumprir sozinha toda vez, sem depender da memória de ninguém.
O que não faríamos: subir uma cópia local por cima da produção só porque “no meu computador funciona”. As etiquetas de cliente que só existiam no servidor mostram o preço desse atalho.
Em resumo
Construir um CRM sem contratar desenvolvedor custou, na prática, R$43,99 por mês de servidor compartilhado e uma sessão de configuração. Mas o risco real não estava no código novo. Estava no que já existia em produção e não tinha cópia em lugar nenhum.
Quem for pelo mesmo caminho ganha tempo, mas precisa tratar o servidor de produção como fonte de verdade, nunca a cópia local. Mais sobre o custo de manter esse tipo de sistema rodando com IA está em quanto custa usar o Claude Code no Brasil, em real, por mês.
Este artigo faz parte do pilar Casos reais — quanto custou, quanto tempo levou e o que quebrou.
Deixe um comentário