Contrato de desenvolvimento de software: o que um fundador não-técnico está de fato comprando ao assinar

A primeira vez que uma fundadora com quem trabalhamos nos mostrou o contrato que a advogada dela tinha redigido, o documento tinha trinta e oito páginas. Abria com doze páginas de definições, percorria cláusulas de indenização copiadas de um acordo de licenciamento de SaaS de 2012, e terminava com foro arbitral em Delaware. Ela não tinha nenhum engenheiro no time. Estava comprando um build sob medida de seis meses de um estúdio de quatro pessoas em São Paulo. A advogada tinha dito que o documento era “padrão”. Quando perguntamos o que aconteceria se o estúdio perdesse um milestone, ela teve que folhear três seções para achar a resposta, e a resposta estava errada.

Esse contrato é o artefato mais comum que vemos em negócios de software sob medida em estágio inicial. Parece responsável. Não é. Um contrato de desenvolvimento de software para um fundador não-técnico comprando a primeira versão de um produto de um estúdio pequeno não é um documento de quarenta páginas. É um documento de quatro a seis páginas que faz cinco coisas bem feitas. O resto é teatro.

Este é o guia, do lado do fundador, sobre quais são essas cinco coisas, as três armadilhas que se escondem dentro dos templates padrão, as cinco perguntas para fazer antes de assinar, e os três casos estreitos em que a versão de quarenta páginas é mesmo o instrumento certo.

O que um contrato de desenvolvimento de software de fato é

Um contrato de desenvolvimento de software é um acordo escrito entre um cliente e um desenvolvedor ou estúdio de desenvolvimento que define o que será construído, como será pago, quem é dono, e o que acontece quando algo dá errado. Não é um brief, não é um statement of work isolado, e não é um NDA, ainda que normalmente faça referência aos três.

Para um fundador não-técnico comprando software sob medida, o contrato é o documento que sobrevive à conversa. Toda promessa feita no Zoom, toda mensagem de Slack falando “a gente provavelmente consegue incluir isso”, toda oferta de “depois a gente vê” vive fora do contrato. O contrato é o que sobra quando alguém está insatisfeito. É nisso que ele precisa ser bom.

Os templates padrão disponíveis online não foram escritos para um fundador nessa situação. Notar para quem eles foram escritos é o primeiro movimento que te protege.

Por que os templates padrão falham com fundadores não-técnicos

A maioria dos templates vem de um de dois mundos. O primeiro é a compra corporativa (PandaDoc, ktslaw, os filings da SEC, os guias de escritórios jurídicos). Esses assumem que o comprador é um departamento de TI de uma Fortune 500 com jurídico interno, e o vendedor é um fornecedor com time de vendas. As cláusulas são longas porque os valores são grandes. A maioria delas é inadequada para um build de seis meses com um estúdio pequeno. Tornam o documento hostil, atrasam a negociação por semanas, e sinalizam que você não entende o trabalho que está prestes a comprar.

O segundo é o lado freelancer: boilerplate da Justia, contratos em markdown no GitHub, geradores de template free. São finos demais. Assumem que o trabalho é um logo de um mês, deixam o IP ambíguo, não tratam de aceite, e não têm mecanismo para o que acontece se o build extrapolar.

Não existe um terceiro mundo de templates escritos para o fundador de uma empresa em estágio inicial comprando um build sob medida de seis meses de um estúdio de quatro a oito pessoas. Então o fundador paga cinco mil dólares para um advogado adaptar o template corporativo, assina a versão fina e torce, ou assina a versão do estúdio porque foi ele quem sugeriu.

A correção não é um template melhor. A correção é saber quais cinco cláusulas de fato funcionam em qualquer versão do documento, e insistir que essas cinco estejam certas.

As cinco cláusulas que decidem se você vai conseguir dormir à noite

Esse é o coração do documento. O resto é acabamento. Se essas cinco cláusulas estão corretas, o contrato funciona. Se qualquer uma delas está errada, nenhuma outra cláusula te salva.

Referência de escopo, não o escopo inteiro

Contratos ruins colocam o escopo inteiro do projeto dentro do corpo do contrato, congelado no momento da assinatura. Esse é o erro mais caro do documento. Na terceira semana de qualquer build sob medida, o escopo mudou: uma sessão de discovery trouxe algo à tona, uma entrevista com cliente mexeu nas prioridades, uma restrição técnica obrigou um workaround. Agora seu contrato não corresponde mais ao que está sendo construído, e toda mudança exige um aditivo.

Um contrato fit para fundador trata contrato e escopo como dois documentos. O contrato nomeia a referência de escopo: “O Desenvolvedor entregará o trabalho descrito no Escopo de Trabalho anexado como Exhibit A, que pode ser revisado por acordo escrito entre as partes sem necessidade de aditivo a este Contrato”. O escopo vive como documento separado, pode ser revisado por escrito conforme o trabalho avança, e é governado pelo contrato acima dele. O escopo muda; a governança não.

Pagamento atrelado ao aceite, não ao calendário

A maioria dos templates usa uma de duas estruturas: preço fechado pago em parcelas mensais iguais, ou T&M faturado semanalmente sem cap. Os dois falham de modo previsível. Preço fechado com pagamento por calendário premia o estúdio por enviar nota no prazo, não por entregar software funcionando. No mês quatro você pagou 67% do projeto por 30% do produto pronto. T&M sem cap remove qualquer previsibilidade de custo, e já vimos fundadores encerrarem um build em três vezes o orçamento original porque nenhuma cláusula obrigou o estúdio a parar e explicar por quê.

A estrutura que recomendamos para quase todo build sob medida em estágio inicial está no nosso comparativo de fixed price vs time and materials para software sob medida: T&M faturado semanalmente com cap por sprint e gates de milestone que liberam o orçamento do próximo sprint. O contrato impõe isso amarrando cada pagamento a um evento de aceite, não a uma data. Cap do Sprint Um, liberado no aceite do entregável do Sprint Um pelos critérios do Exhibit A. Cap do Sprint Dois, liberado no aceite do Sprint Dois. E assim por diante.

O evento de aceite é a peça que sustenta a estrutura. O contrato precisa definir o que é aceite, quem tem o direito de aceitar (você, não eles), e quantos dias você tem para aceitar ou rejeitar. Se aceite não está definido, pagamento não é exigível, e o estúdio pode argumentar que o tempo de calendário é o gatilho.

Cessão de IP com grace anterior ao pagamento final

Quase todo template padrão cede a propriedade intelectual ao cliente “no pagamento final”. Até a última nota ser paga, o estúdio é dono do código que esteve escrevendo para o seu negócio. Se um dispute abrir no mês cinco de um build de seis meses, o estúdio é legalmente o titular do IP e pode se recusar a entregar o repositório até que o dispute se resolva. Já vimos isso acontecer duas vezes. Nos dois casos a fundadora pagou tudo para recuperar o código, e depois processou por danos.

A correção é uma cláusula de IP em duas partes. Primeiro, o IP é cedido ao cliente de forma incremental no pagamento de cada nota, não no pagamento final. Todo código que você já pagou já é seu. Segundo, o contrato concede ao cliente uma licença perpétua, irrevogável e gratuita para usar qualquer código entregue até a data, mesmo durante um dispute. O estúdio está protegido porque continua sendo pago pelo trabalho aceito. Você está protegido porque nenhum dispute consegue te trancar do lado de fora de código que existe.

Source code escrow não substitui essa cláusula. Escrow é um instrumento mediado por terceiro, desenhado para software licenciado de enterprise onde o fornecedor pode quebrar. Para um build sob medida com um estúdio pequeno, a defesa certa é acesso ao repositório e cessão incremental de IP.

Acesso ao repositório no dia um

Uma cláusula que não aparece na maioria dos templates e deveria: o estúdio garante ao cliente acesso de leitura ao repositório de código-fonte no dia um do engajamento. O repositório pode ficar no GitHub ou GitLab do estúdio por conveniência, mas o cliente tem acesso de leitura desde o início e a opção de fazer fork ou migrar a qualquer momento, sem consentimento ou taxa.

Isso não tem a ver com desconfiança. Tem a ver com garantir que no dia trinta e um, no dia noventa e um ou no dia cento e oitenta e um, o produto do trabalho é observável. Você consegue ver os commits. Se um desenvolvedor do estúdio sai e o estúdio alega que o build precisa de mais três semanas “por causa da transição”, você consegue julgar por conta própria. Se o estúdio para de entregar discretamente, você tem algo para passar para o próximo time. O custo para o estúdio é aproximadamente zero. O valor para o fundador é aproximadamente o valor do codebase inteiro.

Saída que não leva 90 dias

A última cláusula que sustenta o contrato é a de rescisão. Quase todo template usa um aviso prévio de 60 ou 90 dias para rescisão sem causa. É razoável para uma relação enterprise com um master agreement de cinco anos. É hostil para um build de seis meses.

Uma cláusula de rescisão fit para fundador faz três coisas. Permite que qualquer parte rescinda com 14 dias de aviso por escrito, sem causa, depois de um cliff designado (em geral depois do aceite do Sprint Dois, para que nenhuma parte saia fora no primeiro mês). Define rescisão por causa (falha em entregar um sprint aceito, quebra de confidencialidade, apropriação indevida de IP) com 7 dias de direito de cura. E especifica o que acontece na rescisão: todo IP já cedido fica com o cliente, o estúdio é pago pelo trabalho aceito até a data da rescisão, sem kill fee, com obrigação de handover de 5 dias úteis e um entregável definido.

O formato dessa cláusula desloca o poder da presunção de que a relação vai continuar para a realidade de que qualquer build sob medida pode terminar antes por bons motivos.

Três armadilhas dos templates padrão

As cinco cláusulas também permitem identificar as três formas mais comuns de templates padrão falharem discretamente.

A primeira armadilha é T&M sem cap. Templates de T&M padrão contêm linguagem do tipo “O Desenvolvedor faturará pelas tarifas horárias acordadas pelo tempo despendido no Projeto”. Sem restrição de custo total. Toda cláusula de T&M precisa estar pareada com um cap por sprint ou por fase que o estúdio não pode ultrapassar sem sua aprovação escrita. Se o cap for atingido e o sprint não foi entregue, é uma conversa, não uma nota fiscal default.

A segunda armadilha é entrega definida por data em vez de por aceite. Templates do mundo enterprise dizem “O Software será entregue em ou antes de 31 de dezembro”. Isso é satisfeito no momento em que o estúdio coloca um release tagueado no repositório, independentemente de funcionar. Substitua toda entrega baseada em data por “O Software será considerado entregue quando aceito pelo Cliente conforme os critérios do Exhibit A”. Calendário é um alvo. Aceite é o gatilho.

A terceira armadilha é IP que é cedido “no pagamento final” sem grace. A maior parte dos fundadores passa o olho na cláusula de IP e assume que “a gente recebe o código quando paga por ele” é suficiente. “No pagamento final” está fazendo o mesmo trabalho de um refém. Qualquer versão da cláusula de IP que não ceda os direitos de forma incremental, nota paga por nota paga, está criando um. Leia a cláusula com atenção, ou peça para alguém ler por você.

Cinco perguntas para fazer ao contrato antes de assinar

Com o documento na sua frente, a forma mais rápida de avaliá-lo é fazer essas cinco perguntas em voz alta.

Primeira: se eu assinar isto e o estúdio perder o aceite do Sprint Dois, o que acontece especificamente? O contrato deve responder em uma ou duas frases. Se exige folhear três seções, ele é longo demais e vago demais.

Segunda: se um dispute abrir no mês quatro de um build de seis meses, quem é dono do código escrito até lá? A resposta deve ser “o cliente é dono de tudo o que foi pago”. Se for “o estúdio, até o pagamento final”, a cláusula de IP está errada.

Terceira: posso ver o repositório hoje? Se a resposta é “depois que a gente montar o scaffolding inicial mês que vem”, a cláusula de acesso ao repositório está errada.

Quarta: se eu quiser sair depois do Sprint Três, quanto custa, quanto tempo leva, e com o que eu saio? A resposta deve ser 14 dias, sem kill fee, todo trabalho aceito, handover de 5 dias. Se for 60 a 90 dias mais taxa de rescisão, a cláusula de saída está errada.

Quinta: qual documento prevalece se o Exhibit A e o contrato conflitarem? A resposta deve ser que o Exhibit A é a fonte operacional da verdade e o contrato é a governança acima dele. Se o contrato sobrepõe o Exhibit A, a cláusula de referência de escopo está errada.

Um contrato que dá respostas limpas e rápidas para essas cinco perguntas vai funcionar. Um contrato que não dá precisa de edição antes da assinatura, independentemente de quantas páginas de definições estejam na frente.

Quando a versão de 40 páginas é mesmo o instrumento certo

Existem três situações em que um contrato mais grosso e mais formal é o instrumento correto.

A primeira é quando o comprador é uma entidade regulada (um banco, uma seguradora, um provedor de saúde, um comprador do setor público) e o contrato precisa incluir termos de compliance não-opcionais: linguagem HIPAA, referências SOC 2, addenda de proteção de dados GDPR ou LGPD, boilerplate de compras públicas. O contrato faz dois trabalhos, governar o build e cumprir obrigações regulatórias. O segundo trabalho é o que o torna longo.

A segunda é quando o engajamento é um master agreement de múltiplos anos sob o qual vários statements of work serão emitidos. Aqui o contrato governa uma relação, não um projeto. A maior parte dos fundadores não-técnicos assinando seu primeiro contrato de software sob medida não está nessa categoria. Está comprando um projeto.

A terceira é quando o próprio build envolve IP licenciado significativo do desenvolvedor (uma plataforma existente, um modelo existente, um framework proprietário) que o contrato precisa licenciar para o cliente em termos específicos. Esse híbrido precisa da estrutura extra. Builds sob medida do zero normalmente não.

Se a sua situação não é uma dessas três, o documento de quarenta páginas não está te ajudando. A versão fit para fundador de quatro a seis páginas, com as cinco cláusulas corretas, te protege melhor do que a de trinta e oito cujos termos o seu advogado também não entende por completo.

Contrato de desenvolvimento de software: FAQ

O que é um contrato de desenvolvimento de software? Um contrato de desenvolvimento de software é um acordo escrito entre cliente e desenvolvedor ou estúdio de desenvolvimento que define o que será construído, como será pago, quem é dono do IP resultante, e o que acontece quando algo não sai como planejado. Para um fundador não-técnico, é o documento que sobrevive à conversa quando a conversa fica difícil.

Quais são as quatro formas de contrato de desenvolvimento de software que vão te oferecer? Templates padrão vêm em aproximadamente quatro formatos. Acordos de projeto a preço fechado (um preço, uma data de entrega, um documento). Acordos de T&M (tarifa horária, faturas semanais, em geral sem cap). Master service agreements com statements of work anexos (relações de prazo mais longo, vários projetos sob um guarda-chuva). E acordos de time dedicado (você paga pela capacidade de um time, não por um entregável). A maioria dos builds sob medida em estágio inicial funciona melhor como um híbrido do segundo com uma estrutura de cap por milestone. Veja nosso comparativo de fixed price vs T&M para saber qual formato cabe na sua situação.

Contrato de desenvolvimento de software vs SOW vs MSA: qual a diferença? O MSA (master service agreement) governa como todo trabalho entre duas partes será conduzido em múltiplos projetos. O SOW (statement of work) é o documento específico do projeto anexado ou referenciado pelo MSA, definindo o que está sendo construído, em que prazo, com que orçamento. “Contrato de desenvolvimento de software” é o termo guarda-chuva, e dependendo do contexto se refere ao MSA, ao SOW ou a um documento combinado de projeto único que faz os dois. Para um build inicial isolado, a versão combinada normalmente é o formato certo, mas ela deve manter separados, dentro da própria estrutura, o escopo (equivalente ao SOW) e a governança (equivalente ao MSA).

Também preciso de um NDA? Em geral sim, mas não como documento separado. Uma cláusula mútua de confidencialidade dentro do contrato é suficiente para quase todo build em estágio inicial. Um NDA isolado é o instrumento certo quando você está trocando informação sensível antes de ter combinado de trabalhar junto: uma conversa de venda, uma avaliação, uma semana de discovery. Uma vez assinado o contrato de desenvolvimento, a cláusula de confidencialidade dentro dele faz o mesmo trabalho.

Eu mesmo posso redigir esse contrato? Você pode redigir a estrutura, as prioridades, as cláusulas que quer incluir, e a linguagem das cinco cláusulas que sustentam o documento. Você não deve assinar o documento final sem que um advogado o revise. Um contrato fit para fundador de quatro a seis páginas leva uma a duas horas de revisão jurídica, não uma semana. Documento mais curto também é documento mais barato de revisar. É mais um motivo pelo qual a versão fit para fundador se paga.

Antes de começar a redigir, garanta que você já fez o trabalho descrito no artigo sobre RFP sobre escrever um partner brief, a avaliação de estúdio do guia de software house, e a decisão de estrutura de pagamento no comparativo de fixed price vs T&M. O contrato é o artefato que captura decisões que você já tomou. Não é onde se toma essas decisões.