Quanto tempo leva construir um SaaS com IA

A régua real por tipo de projeto, de duas horas a sessenta dias, e os quatro itens que atrasam projeto tocado por agente.

Quanto tempo leva construir um SaaS com IA
Neste artigo
  1. Qual é a régua real de prazo por tipo de projeto?
  2. Por que a especificação decide o prazo inteiro?
  3. O que realmente atrasa um projeto tocado por agente?
  4. Dá para acelerar rodando dois agentes ao mesmo tempo?
  5. Como estimar um projeto que você ainda não entendeu?
  6. Esses prazos valem para quem está começando agora?

Um SaaS simples com cadastro, painel e uma integração sai em cerca de dois dias de trabalho real, quando a especificação existe antes do código. Um sistema grande e de verdade complexo leva de um a dois meses, e noventa por cento dos projetos ficam abaixo de trinta dias. O que decide esses números não é a velocidade do agente de código, é quanto tempo você gasta decidindo o que construir.

Abaixo está a régua que eu uso hoje, medida nos meus próprios projetos entregues, e o motivo de ela não bater com estimativa de time tradicional. Estimativa clássica embute reunião, alinhamento, espera por gente ocupada e repasse de contexto entre pessoas. Quando uma pessoa orquestra dois agentes, quase toda essa camada desaparece e sobra o tempo de pensar e o tempo de validar.

Qual é a régua real de prazo por tipo de projeto?

A régua abaixo assume um desenvolvedor experiente orquestrando dois agentes em paralelo, com especificação escrita e gates automáticos rodando. Ela não vale para quem está aprendendo a ferramenta durante o projeto, porque aí o tempo de aprendizado domina tudo. Também não vale para projeto com dependência externa mal resolvida, onde o prazo é ditado por terceiros. Dentro dessas condições, os números se repetem com bastante consistência.

Tipo de projeto Prazo real Onde o tempo realmente vai
Aplicação simples com painel e webhook 2 a 8 horas Quase tudo em especificar e revisar
SaaS de primeira versão com pagamento 3 a 10 dias Integração de cobrança e isolamento de dado
Sistema com integração a ERP de terceiro 15 a 45 dias Depende do outro lado, não de você
Plataforma grande e realmente complexa 30 a 60 dias Arquitetura, migração e teste de carga
Fonte: prazos dos meus próprios projetos entregues, apurado em setembro de 2026.

Essa régua incomoda quem estima em semana de time humano, e ela continua honesta para quem trabalha sozinho orquestrando agentes. A diferença não vem de digitar mais rápido, vem de eliminar a espera entre pessoas. Um time de quatro gasta uma parte grande do prazo em coordenação, alinhamento e repasse de contexto. Uma pessoa com dois agentes não tem essa camada, e o custo disso é não ter redundância nenhuma.

Por que a especificação decide o prazo inteiro?

Um agente de código escreve rápido exatamente o que você pediu, inclusive quando o que você pediu está errado. O custo desse erro não aparece na hora da entrega, aparece quando o recurso já está integrado a outros três. Desfazer uma decisão errada exige mexer em tudo que foi construído em cima dela. Por isso cada hora gasta escrevendo o critério de aceite economiza várias horas de reconstrução depois.

Na prática isso é o inverso do que a intuição sugere, porque escrever documento parece atrasar o começo do trabalho. O que acontece é que o começo fica mais lento e o fim fica muito mais rápido, com menos idas e vindas. Projeto que começa a codar na primeira hora costuma terminar depois de projeto que começa a codar no segundo dia. Eu detalhei esse fluxo em spec driven development com Claude Code e Codex.

O que realmente atrasa um projeto tocado por agente?

A lista de causas de atraso é curta e quase nunca tem a ver com o modelo estar lento ou com limite de uso. São sempre os mesmos quatro itens, e três deles são organizacionais e não técnicos. Reconhecer isso muda onde você investe atenção durante o projeto. Otimizar a ferramenta enquanto o gargalo é uma credencial pendente não adianta nada.

Decisão pendente do outro lado: esperar acesso, credencial ou resposta de quem controla o sistema de destino é a causa de atraso mais comum que eu vejo. Esse tipo de espera não aparece em cronograma e consome semanas inteiras. A defesa é resolver todo acesso na primeira semana, antes de precisar dele.

Escopo que muda no meio: trocar a regra depois que o código existe custa mais do que trocar antes, e essa diferença cresce a cada dia de projeto. Pedido pequeno somado a pedido pequeno vira um mês a mais sem ninguém ter percebido a soma. Registrar cada mudança com o impacto de prazo é o que mantém a conversa honesta.

Falta de gate automático: sem teste e sem verificação rodando a cada passo, o erro só aparece em produção, e consertar ali custa o dobro. Gate é o que permite aceitar trabalho de agente sem ler cada linha. Montei a lista do que cobrir primeiro em testes em projeto tocado por agente.

Revisar tudo na mão: ler cada linha do que o agente escreveu anula completamente o ganho de velocidade e ainda cansa quem revisa. A saída é revisar por prova e por amostragem dirigida ao que é arriscado. Código de autenticação e de cobrança merece leitura integral, e tela de listagem não merece.

Dá para acelerar rodando dois agentes ao mesmo tempo?

Dá, e o ganho é real quando as tarefas são de fato independentes uma da outra. Dois agentes na mesma pasta mexendo nos mesmos arquivos produzem conflito e retrabalho, não velocidade. O que funciona é separar as raias antes de começar, com cada agente numa cópia isolada do repositório. Cada um trabalha na sua frente e a junção acontece no fim, com revisão.

O arranjo técnico que sustenta isso usa cópias de trabalho separadas do mesmo repositório, sem duplicar o histórico. Assim cada agente enxerga o projeto inteiro e escreve só na própria área. Descrevi a configuração completa em Git e worktrees com Claude Code e Codex. O limite prático fica em duas ou três frentes, porque a partir daí a atenção de quem coordena vira o gargalo.

Como estimar um projeto que você ainda não entendeu?

A resposta honesta é que não dá para estimar, e fingir que dá é a origem de quase todo projeto que estoura prazo. O caminho útil é cobrar uma sondagem curta e paga antes de comprometer o prazo do todo. Um a dois dias investigando a parte mais arriscada devolvem uma estimativa que vale alguma coisa. Sem isso, qualquer número dito na primeira conversa é chute com aparência de compromisso.

A parte mais arriscada quase sempre é a integração com sistema que você não controla. Testar uma chamada real contra o ambiente do cliente na primeira semana revela em horas o que o cronograma esconderia por um mês. O custo dessa sondagem é sempre menor que o custo de um projeto que estoura. Cliente sério entende esse argumento quando ele vem com o número da sondagem na frente.

Esses prazos valem para quem está começando agora?

Não valem, e é importante dizer isso com clareza para ninguém se frustrar comparando. A régua acima pressupõe alguém que já sabe arquitetar sistema, avaliar risco e ler resultado de teste. Quem está aprendendo essas coisas durante o projeto vai levar várias vezes mais tempo, e isso é normal. O agente acelera quem já sabe julgar, e não substitui o julgamento de quem ainda não sabe.

Para quem está no começo, o caminho mais rápido é reduzir o escopo até caber em um fim de semana e terminar de verdade. Projeto pequeno concluído ensina mais que projeto grande abandonado no meio. Depois de três ou quatro ciclos completos, a régua de prazo começa a se aproximar da que está na tabela. A documentação oficial do Claude Code cobre bem o funcionamento das ferramentas por baixo, e o guia completo de Claude Code em português é por onde eu mando quem está começando.

WA in X