Guia do fundador para ler uma proposta de desenvolvimento

Uma proposta de desenvolvimento transforma o seu briefing em compromissos: o que vai ser construído, até quando, por quanto e o que acontece quando algo muda.

A regra prática é simples: se um detalhe não está escrito, considere que não está incluído.

Um bom escopo descreve o que o usuário consegue fazer, não só o nome das telas. “O usuário pode se cadastrar com e-mail ou Google e redefinir a senha” dá para conferir. “Módulo de autenticação” não.

Procure perfis de usuário, fluxos principais e ferramentas administrativas listados separadamente. Painéis administrativos são fáceis de esquecer no briefing e caros de acrescentar depois.

Uma proposta clara lista o que não está incluído — por exemplo, redação de textos, traduções, publicação nas lojas de aplicativos, assinaturas de serviços de terceiros ou hospedagem depois do lançamento.

Se não houver seção de exclusões, peça uma. Tudo o que parecia incluído e não estava vai voltar depois como pedido de mudança.

Você não precisa ser engenheiro, mas depois de ler deve conseguir responder a estas perguntas:

Com o que o produto vai ser construído — e por que essa stack para o seu produto, especificamente?

Quem fica com o código e as contas: hospedagem, domínio, lojas de aplicativos, métricas?

Onde ele vai ser hospedado e quanto isso deve custar por mês depois do lançamento?

O código vai estar documentado o bastante para outro desenvolvedor assumir?

Uma boa agência explica as escolhas em linguagem simples. “É o que sempre usamos” não é motivo.

Uma única data de entrega diz muito pouco. Procure etapas que tenham algo para ver em cada uma: telas aprovadas, uma versão funcionando num link de teste, uma versão pronta para lançar.

Pergunte com que frequência você vai ver o progresso. Acompanhamento semanal é uma base sensata; uma única demo no fim é um risco.

Veja se a proposta fala de testes, desempenho e acessibilidade — ou só de funcionalidades.

Procure detalhes: quais navegadores e dispositivos são suportados, que desempenho o produto deve atingir e quem testa antes do lançamento.

Confirme exatamente o que o preço cobre e como os pagamentos são divididos. Entrada mais pagamentos vinculados a etapas é o padrão; 100% adiantado, não.

Encontre o processo de mudança. Ele deve explicar como novos pedidos são orçados e aprovados antes de alguém começar a trabalhar neles.

Muitas propostas param no dia do lançamento. Pergunte o que vem depois: existe um período de garantia para bugs, quanto tempo ele dura e como o trabalho contínuo é cobrado?

Um lançamento sem plano de correções e atualizações é onde muitos produtos param em silêncio.

O que exatamente está excluído?

Quem vai trabalhar no projeto no dia a dia?

O que acontece se precisarmos mudar o escopo?

Com quem ficam o código e todas as contas no final?

Que suporte está incluído depois do lançamento?