Como comparar orçamentos de desenvolvimento: escopo e entrega

Um fornecedor chama o trabalho de “desenvolvimento completo”. Outro cobra separadamente pelo levantamento de requisitos, design, QA e implantação. Mesmo colocando os totais lado a lado, ainda não dá para saber qual proposta custa mais. Primeiro, confirme se todos estão orçando o mesmo resultado.

Normalize o escopo antes de comparar preços

Verifique se cada proposta cobre:

• apenas um aplicativo web, ou também aplicativos nativos iOS e Android
• as telas acordadas, fluxos de usuário e recursos de administração
• arquivos-fonte de design, layouts responsivos e trabalho de acessibilidade
• migração de dados legados e integrações de terceiros
• testes, revisão de segurança e escopo de correção de bugs
• implantação de servidor e suporte para revisão da loja de aplicativos
• correções cobertas pela garantia e manutenção paga após a entrega

Um item ausente pode virar uma cobrança adicional mais tarde. O inverso também acontece: uma proposta pode incluir plataformas ou suporte contínuo de que você não precisa. Em vez de comparar apenas fornecedores e valores totais, monte uma tabela com três colunas: incluído, excluído e pressuposto.

Trate o protótipo como uma ferramenta de conversa, não como uma especificação

Um protótipo feito com Claude Code, Codex, Cursor ou Lovable pode mostrar o fluxo desejado com mais clareza do que um briefing escrito. Mas uma tela funcional não equivale a uma especificação completa, e o código do protótipo não está necessariamente pronto para produção.

Em especial, o Lovable constrói aplicações web. Um PWA ou um wrapper separado pode oferecer uma experiência móvel instalável, mas um protótipo web não deve ser contado como progresso em direção a um aplicativo nativo iOS ou Android sem uma avaliação adicional.

Separe o que o protótipo demonstra do que ainda é desconhecido.

Já demonstrado

• o fluxo de tela e o texto principal
• as principais ações que os usuários precisam tomar
• a direção visual preferida

Ainda precisa ser avaliado

• se o código é reutilizável
• o comportamento em dispositivos móveis e navegadores, incluindo acessibilidade
• a segurança da autenticação, autorização e pagamentos
• arquitetura de testes, implantação e monitoramento
• licenças para bibliotecas e ativos

Assim, o protótipo continua útil sem que seu valor seja superestimado, e você não precisa explicar novamente decisões de produto já tomadas.

Contrate uma avaliação técnica breve antes do desenvolvimento completo

Ninguém pode afirmar com responsabilidade que “80% do código atual pode ser reaproveitado” ou que “tudo precisa ser refeito” sem examinar o repositório. Primeiro, contrate uma avaliação paga e defina claramente o que ela deve entregar.

No mínimo, peça ao revisor para verificar:

1. se o projeto pode ser instalado e executado em um ambiente limpo seguindo o README
2. se as telas e os fluxos principais ainda funcionam
3. se há segredos no código ou nos logs e se existem falhas evidentes de autenticação ou autorização por usuário
4. o que os testes automatizados cobrem e o que ainda exige verificação manual
5. de quais dependências, serviços de hospedagem, contas externas e licenças o aplicativo depende

Peça três alternativas: concluir sobre a base atual, refatorar áreas selecionadas e reconstruir. Cada uma deve informar escopo, risco e cronograma. Um protótipo não garante desconto, mas o código existente também pode ter valor. A avaliação mostra o que realmente pode ser reaproveitado.

O pacote de entrega é mais do que o repositório

Um novo desenvolvedor deve conseguir começar a trabalhar no mesmo dia em que receber o acesso. Prepare:

• um README com os comandos de instalação, execução e build
• os nomes das variáveis de ambiente necessárias e onde obtê-las; envie os valores reais por outro canal seguro
• um inventário de telas e recursos, além dos defeitos conhecidos
• contas e procedimentos de teste
• uma lista das contas de servidor, domínio, pagamentos, analytics e lojas de aplicativos
• o repositório Git e o histórico de commits que registra as decisões importantes

Não exclua arquivos gerados por IA duplicados ou aparentemente não utilizados imediatamente antes da entrega. Preserve primeiro o estado conhecido de funcionamento em uma tag ou branch, depois confirme as exclusões durante a avaliação.

Nunca faça commit de um arquivo .env com valores reais ou chaves de API. Mantenha um .env.example sem valores, apenas com os nomes das variáveis necessárias. Se uma chave já entrou no histórico, primeiro revogue-a ou faça a rotação; depois, avalie a limpeza do histórico do Git.

Coloque o controle operacional no contrato

Uma equipe fica presa a um fornecedor quando a titularidade das contas e os entregáveis não são definidos com clareza. Antes de assinar, peça respostas por escrito para estas perguntas:

• Qual repositório recebe o código-fonte e o histórico completo do Git?
• Quem é o titular legal da conta que possui o domínio, hospedagem, lojas de aplicativos e provedor de pagamento?
• Os arquivos de design editáveis, fontes, imagens e licenças pagas estão incluídos na entrega?
• Quais recursos formam cada marco de aceitação e o que conta como aprovação?
• Quem aprova alterações de escopo, como são registradas e como são cobradas?
• O que é considerado uma correção coberta pela garantia e o que passa a ser manutenção paga?

Sempre que possível, crie as contas principais em nome do cliente e conceda ao fornecedor apenas os acessos necessários. Se um repositório existente no GitHub precisar mudar de proprietário, inclua no plano de entrega o processo de transferência e uma verificação das permissões depois da mudança.

Uma solicitação curta de cotação é suficiente

Temos um protótipo web funcional e um repositório Git.
Objetivo: aplicativo web responsivo com uma área administrativa
Escopo a orçar: avaliação do código, revisão da autenticação e dos pagamentos, implantação e documentação de entrega
Fora do escopo: aplicativos nativos para iOS e Android
Entregáveis: código-fonte e histórico do Git, configuração de implantação, README e resultados dos testes
Comece por uma avaliação paga; depois, orce separadamente as opções de concluir sobre a base atual, refatorar áreas específicas e reconstruir.

Envie o mesmo documento a todos os fornecedores e guarde as perguntas e respostas. A proposta mais fácil de comparar não é necessariamente a mais barata, mas a que deixa claras as exclusões e as condições de entrega. Antes de escolher, considere pedir a um especialista em contratos que revise o cronograma, as condições de pagamento, os termos de propriedade intelectual e as cláusulas de licenciamento.