Contrato de desenvolvimento de aplicativo: checklist para o cliente

O que precisa estar claro

Uma proposta incompleta em algum desses pontos não significa, por si só, que o fornecedor seja inadequado. Significa que existe uma suposição a resolver antes de ela virar custo ou disputa.

Anexe um escopo que possa ser testado

O corpo do contrato não precisa repetir cada tela. Ele pode apontar para um documento de requisitos do aplicativo e uma especificação técnica, desde que o anexo tenha data, versão e ordem de prioridade.

Descreva comportamentos, não apenas nomes de funções. “Módulo de agendamento” pode significar um formulário simples ou um sistema com agenda de profissionais, sinal, cancelamento, fuso horário, lembretes e reembolso. Registre perfis, jornada principal, regras comerciais, integrações e estados importantes.

Liste também o que fica fora. Migração, site, produção de textos, tablets, idiomas adicionais ou suporte contínuo não deveriam permanecer implícitos. Esclareça as condições assumidas para APIs, conteúdo, dados e disponibilidade das contas do cliente.

Trate a mudança como parte normal do projeto

É improvável prever tudo antes de começar. O contrato não precisa proibir mudanças; precisa impedir que elas se tornem invisíveis.

Uma solicitação de mudança deve registrar o resultado desejado, a parte afetada, o impacto em preço e prazo e o que será retirado ou adiado. Também precisa indicar quem pode aprovar. Mensagens isoladas de vários participantes não deveriam ampliar silenciosamente uma versão já contratada.

Em um trabalho iterativo, a lista de prioridades pode mudar enquanto orçamento ou capacidade da equipe continuam controlados. Ainda assim, as partes precisam de uma regra para trocar prioridades e reconhecer quando uma ideia exige nova estimativa.

Ligue pagamento a resultados observáveis

Um pagamento inicial pode reservar a equipe e cobrir a preparação. As parcelas seguintes ficam mais claras quando correspondem a resultados: interface aprovada, jornada central funcionando em teste, versão candidata ou entrega do pacote final.

Evite marcos como “servidor 80% concluído”. O cliente não consegue conferir esse percentual, e ele não prova que o produto funciona. Um marco verificável poderia dizer que a pessoa cria uma conta, escolhe um serviço, realiza um pagamento de teste e que a administração visualiza e estorna a transação.

Defina o que acontece quando existem falhas. Separe erros bloqueadores de ajustes menores, estabeleça o período de análise e identifique a versão avaliada. O efeito de silêncio, uso em produção ou atraso na resposta deve ser discutido de acordo com o contrato e a lei aplicável.

Escreva critérios de aceite antes do desenvolvimento

Aceite não é a afirmação genérica de que o aplicativo “funciona”. Para cada entrega, registre ambiente, versão, fluxo esperado, dados de teste e resultado.

Critérios bons descrevem situações observáveis: o pagamento aprovado cria um pedido uma única vez; o cancelamento dentro da regra devolve o valor correto; um usuário comum não acessa dados administrativos. Critérios ruins repetem o nome da função.

Combine quem realiza os testes, quantos dias terá para responder, onde as falhas serão registradas e como ocorre uma nova avaliação. O roteiro de testes antes do lançamento ajuda a transformar riscos em cenários concretos.

Defina os direitos de cada parte do produto

“Aplicativo” reúne ativos diferentes: código do aplicativo e do servidor, configuração de infraestrutura, banco de dados, arquivos editáveis de design, ilustrações, documentação, conteúdo e materiais das lojas.

O contrato deve explicar se o cliente recebe propriedade, licença exclusiva ou direito limitado sobre cada categoria, quando isso ocorre e o que poderá fazer depois. Para trocar de fornecedor, operar em outro mercado ou vender a empresa, pode ser necessário modificar, sublicenciar ou transferir determinados ativos.

Separe o trabalho criado para o projeto das ferramentas e bibliotecas que o fornecedor já possuía. Liste também software livre, fontes, imagens, serviços e componentes de terceiros. Ninguém consegue ceder ao cliente um direito maior do que aquele que possui.

A legislação brasileira sobre software contém regras próprias, e o resultado concreto depende do contrato e dos fatos. Por isso, não confie apenas em uma frase como “todos os direitos são do cliente”: identifique ativos, direitos, território, prazo e momento da transferência com orientação jurídica.

Código-fonte precisa significar um projeto utilizável

“Entrega do código-fonte” pode resultar em um arquivo compactado sem histórico, instruções ou configuração. Nomeie os repositórios, permissões, dependências, testes, ambientes, forma de gerar uma versão e documentação mínima.

O cliente pode ter acesso ao repositório durante o desenvolvimento, de acordo com o modelo comercial. Isso reduz o risco de descobrir apenas no encerramento que algo importante ficou fora. Uma transferência de repositório também exige revisar titularidade da organização, pacotes, páginas, integrações e cobrança.

Um desenvolvedor que não participou do projeto deveria conseguir gerar uma versão de teste usando o material entregue. A lista de documentação e transição detalha essa conferência.

Mantenha contas importantes sob controle da empresa

App Store Connect, Google Play Console, domínio, nuvem, pagamento e outros serviços essenciais deveriam, em geral, ser criados com a identidade empresarial do cliente. A equipe recebe as funções necessárias para trabalhar.

Apple e Google permitem transferir aplicativos entre contas quando os requisitos são atendidos, mas nem todo histórico, configuração ou serviço associado se comporta da mesma forma. Definir o titular antes do primeiro lançamento costuma ser mais simples.

Registre também quem paga as assinaturas, recebe alertas e pode alterar a produção. Um cartão pessoal vencido ou um e-mail de ex-funcionário não deveria interromper um produto entregue corretamente.

Liste terceiros, licenças e custos recorrentes

Peça um inventário das dependências importantes, respectivas licenças e assinaturas. Um produto pequeno pode usar uma lista simples; ambientes mais exigentes podem precisar de uma relação formal dos componentes de software.

O contrato pode dizer quem aprova um fornecedor e o que acontece se houver aumento de preço, mudança de licença ou encerramento do serviço. Código aberto não significa ausência de obrigações.

O objetivo não é exigir propriedade sobre um serviço externo. É assegurar que o uso seja permitido, que a conta correta esteja no controle e que riscos relevantes tenham uma alternativa.

Detalhe segurança e tratamento de dados

“Seguro e em conformidade com a LGPD” é amplo demais. Autenticação, permissões, criptografia, registros, cópias de segurança, vulnerabilidades e comunicação de incidentes precisam estar ligados a responsabilidades e ao escopo real.

Quando o fornecedor trata dados pessoais em nome do cliente, o contrato deve refletir os papéis, instruções, medidas de segurança, subcontratados, devolução e eliminação. O conteúdo exato depende do produto e da relação entre as partes.

Defina quais ambientes podem receber dados reais, quem acessa produção, como acessos são registrados e o que acontece no encerramento. Dados de teste anonimizados reduzem exposição desnecessária.

Separe correção, evolução e manutenção

Falha é um comportamento diferente do requisito aceito. Evolução é uma alteração do comportamento. Manutenção inclui compatibilidade com novas versões, atualização de componentes, observação e melhorias contínuas.

Estabeleça período de correção, gravidades, canal e limites. “Suporte gratuito para sempre” é impreciso, mas chamar toda falha de nova solicitação também é.

Depois do lançamento, um acordo separado pode definir capacidade e tempo de resposta. O guia sobre custo de manutenção de aplicativo mostra o trabalho que continua após a publicação.

Planeje a saída antes de precisar dela

Uma colaboração pode terminar por decisão estratégica, financeira ou operacional. O contrato deve tratar o que já foi concluído, o que está em andamento, valores devidos, licenças, dados, informações confidenciais e capacidade reservada.

Vale manter um pacote mínimo de transição em cada grande marco pago: código atualizado, arquivos editáveis, documentação, ambientes, dependências e problemas conhecidos. Apoio adicional pode ter duração e valor definidos.

O cliente precisa conseguir retirar acessos sem interromper a produção. O fornecedor precisa conseguir comprovar a devolução ou eliminação de dados conforme o combinado.

Sinais de alerta

Observe com cuidado frases vagas como “o cliente é dono do aplicativo”, aceite automático sem critérios, código entregue apenas após uma condição final indefinida, contas pessoais, ausência de processo para mudanças ou componentes externos não declarados.

Confira ainda a ordem de prioridade entre proposta, escopo e contrato. Uma lista detalhada perde valor quando outro documento diz que ela é apenas ilustrativa.

Como a Appfyl prepara o projeto

Antes da revisão jurídica, a Appfyl organiza a primeira versão por perfis, jornadas, operações do painel administrativo, integrações e dependências do cliente. Assim, o anexo técnico parte de fatos verificáveis.

Também registramos contas empresariais, demonstrações de cada marco e itens da entrega desde o início. O aceite se apoia em jornadas completas, e não em percentuais abstratos.

As perguntas para uma empresa de desenvolvimento ajudam a comparar propostas. O questionário de estimativa da Appfyl organiza as funções antes de fechar preço, prazo e contrato.

Veja como a Appfyl transforma escopo em produtos lançados. Ver cases da Appfyl.

Perguntas frequentes