Quase toda primeira conversa chega na mesma pergunta, e ela costuma vir antes mesmo de você me explicar o que precisa: "tá, mas isso leva quanto tempo?". É justa. Você tem uma operação rodando, uma equipe esperando, talvez um cliente seu dependendo disso. Você não quer um romance sobre metodologia, quer uma data. O problema é que, se eu te der uma data ali na hora, sem ter visto o tamanho real do que você tem na cabeça, eu estaria te enrolando com confiança — e é exatamente esse tipo de coisa que faz qualquer dono de empresa desconfiar de desenvolvedor.
Por que você não consegue um prazo exato logo de cara?
Porque "um sistema" pode ser quinze coisas muito diferentes. Quando alguém me diz "quero um sistema pra controlar meus pedidos", dentro dessa frase cabe tanto uma tela simples que substitui uma planilha quanto um bicho com login de vários usuários, controle de estoque, emissão de nota, integração com o site, relatório pro contador e aviso no WhatsApp quando o pedido sai. Os dois são "um sistema pra controlar pedidos". Um leva dias, o outro leva meses. A frase é idêntica; o trabalho não tem nada a ver.
O prazo não sai do meu chute, sai do escopo. E o escopo só fica claro depois de uma conversa em que eu pergunto coisas chatas: quem vai usar isso, quantas pessoas ao mesmo tempo, o que precisa conversar com o que você já tem, o que acontece quando dá errado. Antes disso, qualquer número que eu falar é firula pra parecer rápido. Prefiro perder a graça de responder na hora e te dar um prazo em que eu mesmo acredito. Se você ainda está na dúvida sobre o que está pedindo de verdade, vale entender primeiro o que é um sistema sob medida — porque metade da indefinição de prazo vem de indefinição do que é o sistema.
O que faz o cronograma esticar?
Tem quatro coisas que mexem no relógio mais do que qualquer outra, e nenhuma delas é "o desenvolvedor digita devagar".
O tamanho do escopo. Óbvio, mas vale dizer: cada tela nova, cada regra nova ("ah, mas se o cliente for atacadista o desconto é diferente"), cada exceção do seu negócio é mais trabalho. Negócio real é cheio de exceção, e tudo bem — só precisa entrar na conta antes, não no meio.
As integrações. Fazer o sistema funcionar sozinho é uma coisa. Fazer ele conversar com o seu sistema de nota fiscal, com o gateway de pagamento, com a API dos Correios, com aquele ERP antigo que ninguém sabe quem configurou — é outra. Integração depende de documentação dos outros, de credenciais que às vezes demoram pra liberar, de comportamentos que só aparecem quando você testa de verdade. É a parte que mais surpreende prazo, sempre.
A dependência de terceiros. Se o seu sistema precisa de um acesso que está com seu contador, de uma senha que está com a empresa que fez seu site antigo, ou da aprovação de um sócio que viaja muito, o cronograma deixa de ser só meu. Eu posso estar com a minha parte pronta e parado, esperando uma chave de API que o fornecedor leva dez dias pra mandar.
As idas e vindas de aprovação. Eu te entrego uma tela, você olha, pede ajuste, eu ajusto, você olha de novo. Esse ciclo é saudável — é assim que sai uma coisa boa, em vez de uma coisa que eu achei bonita e você odiou. Mas cada volta tem um tempo. Se as aprovações são rápidas, o projeto voa. Se cada feedback demora uma semana, o projeto demora junto.
Dá pra ter alguma noção de faixa, mesmo sem o escopo fechado?
Dá, desde que a gente trate como faixa e não como promessa. Uma automação pontual — pegar uma tarefa repetitiva que hoje te consome horas e fazer ela rodar sozinha, ou uma telinha que resolve um problema específico — normalmente vive na casa de dias a poucas semanas. É o tipo de coisa em que o valor aparece quase imediato.
Um sistema completo, com vários usuários, várias telas, integrações e regras de negócio de verdade, vive na casa de semanas a meses, dependendo de quão grande é. Não tem mágica que comprima isso sem cortar escopo — e cortar escopo às vezes é a decisão certa, mas é uma decisão consciente, não um truque.
O que eu sempre faço, independente do tamanho, é fechar orçamento e prazo antes de começar. Você sabe o que vai pagar e até quando recebe antes de eu escrever a primeira linha. Se no meio do caminho você pedir algo novo que não estava combinado, eu te falo na hora o impacto em prazo e custo, e você decide. Sem aquela conta que cresce no escuro e aparece no fim.
Por que entregar por etapas é melhor, mesmo quando não encurta o total?
Essa é a parte que mais muda a sua experiência. Tem dois jeitos de tocar um projeto. No primeiro, eu sumo por três meses e volto com o sistema inteiro pronto. No segundo, a gente recorta o problema e eu te entrego primeiro o pedaço que mais dói, já funcionando, e vou somando o resto em cima.
O segundo é quase sempre melhor pra você, por três motivos. Você começa a usar e a tirar valor antes — se o que mais te consome hoje é fechar o caixa no fim do dia, eu entrego isso primeiro e você já economiza tempo enquanto o resto está sendo feito. Você vê o sistema crescer e corrige o rumo cedo, quando ajustar ainda é barato, em vez de descobrir no fim que a gente entendeu coisas diferentes. E você não passa três meses pagando sem ver nada de pé — o que dá um medo justo em qualquer pessoa.
Esse é o espírito do MVP, sem a palavra bonita: a primeira versão não tem tudo, tem o suficiente pra resolver o problema central e já entrar em uso. O resto vem por cima, priorizado pelo que te dá mais retorno. É, aliás, o melhor momento pra trocar uma planilha que já não dá conta — vale ver quando trocar a planilha por um sistema antes de decidir o tamanho do primeiro passo.
O que atrasa o projeto e não é culpa do desenvolvedor?
Aqui eu vou contra mim mesmo, porque é honesto e porque te poupa frustração depois. Boa parte dos atrasos que eu já vi não veio do código. Veio de três coisas do lado do cliente.
Decisão que não vem. Em todo projeto chega um momento em que eu preciso de uma resposta sua pra seguir: "vai ser desse jeito ou daquele?". Quando essa resposta trava — porque depende de um sócio, porque ninguém quer bater o martelo, porque mudou de ideia três vezes — eu fico parado. E parado de verdade: não tem como adiantar outra coisa que dependa daquela escolha.
Acesso que não chega. Eu preciso da senha do servidor, do acesso ao sistema antigo, da credencial da API de pagamento, dos dados reais pra testar. Quando isso fica "depois eu te mando" por duas semanas, o projeto fica nessas duas semanas também. Não tem jeito de eu integrar com um sistema que eu não consigo acessar.
Feedback que demora. Eu entrego uma etapa pra você testar e validar. Se você está atolado e leva dez dias pra olhar, são dez dias que entram no cronograma — não porque eu não estava trabalhando, mas porque não dá pra construir o segundo andar antes de você aprovar o primeiro.
Não falo isso pra empurrar a culpa. Falo porque o prazo é uma parceria. Se você consegue garantir decisões ágeis, acessos liberados logo no começo e um tempo reservado na sua semana pra olhar as entregas, o projeto encurta de verdade. Eu inclusive já combino isso no início: deixo claro em que momentos vou precisar de você, pra não te pegar de surpresa no meio.
Quando o melhor prazo é "não faça agora"?
Tem hora que a resposta certa é não começar. Se você ainda não sabe direito qual problema quer resolver, e o "sistema" é mais uma vontade vaga de "se organizar melhor", o prazo vai estourar garantido — não porque o trabalho é grande, mas porque o alvo vai mudar a cada semana. Nesse caso eu prefiro te dizer pra amadurecer a ideia, ou começar com uma automação pequena e barata pra você sentir como é, do que te vender um projeto grande que vai sangrar prazo enquanto você descobre o que queria. Também não vale fazer sob medida o que um sistema pronto de prateleira já resolve bem — se existe uma ferramenta consolidada que faz a maior parte do que você precisa, o caminho mais curto é assinar ela, não me contratar pra reinventá-la.
Se você está nesse ponto de querer uma noção honesta de prazo pro seu caso específico, é exatamente pra isso que serve o diagnóstico gratuito: a gente conversa sobre o que você precisa, eu te digo com franqueza a faixa de tempo, o que vai pesar no seu cronograma e se vale fazer agora ou esperar. Sem compromisso e sem orçamento que cresce no escuro. Você pode ver como eu trabalho com sistema sob medida e me chamar pra conversar — saio dessa conversa te dando um prazo em que eu mesmo confio, ou te dizendo, de boa, que não é a hora.