Projetos com escopo fixo podem vincular pagamentos a entregáveis definidos e evidências de aceite. Trabalhos por tempo e materiais ou em regime de contratação recorrente podem usar faturamento por calendário, com registros de horas aprovados e controles orçamentários. Escolha o modelo de acordo com o escopo e documente alterações, atrasos e aceite antes do início do trabalho.
Quando os pagamentos por calendário precisam de controles adicionais
Considere uma proposta ilustrativa de "30% na assinatura, 30% na sexta semana, 40% na décima segunda semana". Se os pagamentos dependerem apenas de datas, um projeto com escopo fixo atrasado ainda poderá gerar a fatura. Acrescente entregáveis acordados, evidências de aceite e um procedimento para atrasos e alterações; este é um exemplo, não um padrão de pagamento do setor.
Defina um ponto de revisão antes de cada pagamento. Para marcos de escopo fixo, revise o entregável acordado; para trabalhos baseados em tempo, revise o trabalho autorizado, os registros de horas e o orçamento. O modelo de faturamento, por si só, não comprova o progresso.
Uma estrutura que funciona para projetos pequenos
Esta é uma alocação ilustrativa para um projeto com escopo fixo, não os preços da Manboo nem um cronograma de pagamentos universal. As cinco parcelas totalizam 100%; o contrato deve definir os entregáveis efetivos e os termos de suporte.
| Etapa | Parcela de exemplo | Liberada quando |
|---|---|---|
| Início do projeto | 25% | Contrato, escopo e preparativos para o início acordados |
| Design aprovado | 15% | Telas definidas e evidências de design aceitas |
| Desenvolvimento principal concluído | 30% | Os principais fluxos de trabalho acordados podem ser demonstrados no ambiente de testes |
| Aceite aprovado | 25% | As condições definidas de UAT e de defeitos foram atendidas |
| Retenção, se acordada | 5% | O período acordado de suporte a defeitos pós-lançamento e as condições de liberação foram concluídas |
Cada etapa tem um gatilho verificável. "Desenvolvimento principal concluído" significa que o cliente pode fazer login e percorrer os principais fluxos de trabalho — não que o desenvolvedor diga que está concluído.
O depósito
Defina qualquer depósito com base na mobilização, na capacidade reservada e no trabalho financiado. Registre os preparativos para o início e os entregáveis que ele financia; não existe um mínimo universal de 25% necessário para programar o desenvolvimento.
Registre o contato responsável, os preparativos acordados para o início e como o depósito será tratado se o projeto for atrasado ou cancelado. Um depósito, por si só, não verifica a capacidade de entrega.
Retenção
Se a retenção for acordada, defina seu valor, a data de liberação e o procedimento para defeitos. Os 5% do exemplo acima são uma alocação hipotética, não uma prática de mercado. Dois termos a estabelecer são:
- Um período definido com datas específicas de início e término ou um gatilho inequívoco, em vez de uma retenção por prazo indefinido.
- Uma condição de liberação definida — o término do período de garantia sem defeitos não resolvidos, em vez da satisfação geral do cliente.
Uma retenção por prazo indefinido não é uma retenção; é um desconto com o qual o desenvolvedor não concordou, e desenvolvedores razoáveis irão recusá-la.
O que registrar junto com o cronograma
- Condições de pagamento — quantos dias após a emissão da fatura.
- O que acontece se um marco atrasar por causa do desenvolvedor e, separadamente, por causa do cliente. Atrasos causados pelo cliente são comuns — feedback não fornecido, conteúdo não enviado — e um cronograma que os ignora é injusto na direção oposta.
- Como as solicitações de alteração serão pagas, pois ficam fora da estrutura de marcos.
- O que acontece em caso de rescisão — o que é devido pelo trabalho realizado e o que será entregue.
Defina o pagamento de rescisão, os entregáveis aceitos e inacabados, a transferência do repositório e da implantação, os direitos de propriedade intelectual e os limites das licenças de terceiros. O contrato deve explicar quem pode usar o trabalho e o que é devido; uma única frase não resolve todas as questões de propriedade ou rescisão.
Sinais de alerta em um cronograma proposto
- 100% antecipado. Ocasionalmente justificável para trabalhos muito pequenos; caso contrário, representa um risco significativo.
- Marcos sem um gatilho verificável — "backend concluído" sem uma definição de concluído.
- Suporte pós-lançamento não definido. Especifique qualquer período acordado de suporte a defeitos, o escopo de manutenção e o processo de escalonamento. O suporte pode ser definido contratualmente mesmo sem retenção; não dependa de uma promessa informal.
- Um pagamento final antes do aceite. Isso inverte a capacidade de negociação exatamente no ponto em que ela importa.
Serviços relacionados da Manboo
- Desenvolvimento de aplicativos Flutter para MVPs de iOS e Android.
- Desenvolvimento de software empresarial para sistemas de CRM, reservas, inventário e fluxos de trabalho.
- Desenvolvimento de painéis administrativos para dashboards operacionais e gestão de back-end.
- Integração de APIs de IA quando seu produto estiver pronto para pesquisa inteligente, chat ou automação.
- Solicite uma revisão de escopo e uma estimativa do projeto quando estiver pronto para planejar a primeira versão.