Fixed price vs time and materials: qual contrato realmente funciona para software sob medida

O framework do fundador não-técnico para escolher a estrutura de contrato certa com um parceiro de software, e as cláusulas que tornam o time and materials de fato responsável.

A primeira vez que um fundador nos encaminha duas minutas de contrato e pergunta qual assinar, já sabemos como a conversa vai terminar. Uma minuta é fixed price: um número fechado, uma lista de funcionalidades, uma data de entrega. A outra é time and materials: uma taxa por hora ou por semana, uma estimativa flexível, um pedido de confiança. Disseram ao fundador que fixed price é mais seguro porque limita a fatura, e ele quer que a gente confirme.

Na maior parte das vezes dizemos o oposto. Para software sob medida em estágio inicial, time and materials com estrutura de milestones gates é o default mais saudável. Fixed price ganha em um conjunto restrito de casos que normalmente não se aplicam, e mesmo quando ganha, você precisa pagar a mais para tornar o contrato honesto. O contrato que você assina para software sob medida não é um instrumento financeiro. É o sistema operacional do relacionamento que você está prestes a construir.

Esse é o framework que apresentamos aos fundadores antes de qualquer assinatura.

O que cada contrato é, em uma frase

Fixed price quer dizer que você e o fornecedor concordam num valor total fechado para um escopo definido, pago contra milestones. O fornecedor assume o risco de entrega. Se subestimou, problema dele.

Time and materials, abreviado como T&M, significa que você paga pelo tempo que o time efetivamente gasta, em geral faturado por semana ou por sprint, com taxas combinadas. O fornecedor manda uma fatura pelas horas trabalhadas. Você assume o risco de orçamento. Se a obra durar mais que o esperado, a conta continua correndo.

Essa é a descrição de manual. É também onde a maioria dos artigos sobre o assunto para, e é por isso que fundadores assinam o contrato errado. As duas estruturas parecem simétricas no papel. Na prática elas criam incentivos completamente diferentes, e esses incentivos moldam o produto que você acaba recebendo.

As quatro condições que tornam fixed price honesto

Fixed price não é uma estrutura ruim. É uma estrutura que exige condições que a maioria dos projetos de software em estágio inicial não consegue atender. Quando estes quatro pontos são verdadeiros, fixed price pode ser a escolha correta.

O escopo é genuinamente conhecido. Não é “sabemos que queremos um marketplace”. Conhecido significa: as telas estão desenhadas, as integrações estão listadas, os edge cases estão documentados, o modelo de dados está fechado, a taxa em que o cliente muda de ideia está perto de zero. Se você não consegue entregar uma pasta a um estranho e ter dele uma estimativa parecida com a do seu fornecedor, o escopo não está fechado.

O trabalho é uma commodity. Um site WordPress para uma página institucional, um ajuste de tema Shopify, um app mobile de formato conhecido para um negócio de formato conhecido. Coisas que já foram construídas milhares de vezes, em que o fornecedor tem repertório real. Quanto mais longe você está de uma commodity, mais margem de risco o fornecedor precisa embutir no número fechado para absorver os desconhecidos. Essa margem é o preço que você paga pela transferência de risco.

Você não vai mudar de ideia. Se a única pessoa que pode alterar o escopo é você, e você consegue prometer credivelmente que não vai alterar, fixed price segue limpo. No momento em que você muda escopo, fixed price vira uma sequência de change orders, cada um negociado sob assimetria de informação. No terceiro change order, o contrato parou de funcionar.

O fornecedor já construiu exatamente isso recentemente. Não “algo parecido”. Isso. Um time que entregou o mesmo formato de produto para dois clientes anteriores consegue cotar fixed price honestamente, porque a estimativa está ancorada em dois orçamentos passados que se confirmaram. Um time novo no domínio está chutando, e o chute vem carregado de margem de risco.

Se você não consegue defender os quatro pontos para um colega, fixed price é a estrutura errada para o seu projeto. O número no contrato é ficção.

As quatro maneiras pelas quais fixed price quebra na prática

Fundadores que assinam contratos fixed price em software sob medida real quase sempre acabam em um destes modos de falha.

O fornecedor inflou o número, e você pagou caro por um risco que nunca se materializou. Um bom fornecedor sabe que “construir um SaaS de gestão de propriedade” carrega desconhecidos desconhecidos. Ele cota o número que permite dormir tranquilo. Se tudo correr bem, você acabou de pagar um prêmio de 30% a 60% pelo privilégio da certeza. Esse dinheiro teria rendido mais em um projeto T&M que terminasse no mesmo lugar.

O fornecedor subestimou, e agora está perdendo dinheiro com você. Fixed price não alinha incentivo de ninguém quando o projeto entra no vermelho. O único caminho do fornecedor de volta à margem é cortar caminho: pular testes, copiar código de um cliente anterior, entregar algo do qual não se orgulha, colocar um dev júnior em um problema sênior. Você não tem visibilidade de nada disso até o produto quebrar em produção seis meses depois.

O escopo cresce e a relação desmorona. Software de verdade vai se descobrindo enquanto é construído. Um fundador vê o segundo protótipo e percebe que o PRD que ele escreveu no começo estava errado. Sob fixed price, cada nova percepção vira uma negociação de contrato. O fornecedor vira clipboard. Vocês começam a se odiar antes do MVP subir.

O fornecedor desaparece a 80% do projeto. Esse é o pior modo de falha e o mais comum. Fixed price faz com que a maior parte do caixa esteja concentrada nos últimos milestones. Quando o fornecedor já recebeu o grosso da parte fácil e o que sobra é a parte difícil e ambígua, ir embora é racional para ele. Já vimos isso acontecer em três software houses diferentes com três fundadores diferentes. O padrão é idêntico: um kickoff ótimo, demos semanais bonitas e um declínio silencioso de atenção a partir do quarto mês.

Já escrevemos sobre como avaliar a software house que vai assinar esse contrato antes de qualquer estrutura contratual importar. Um parceiro ruim vai falhar com você nas duas estruturas. A estrutura de contrato faz a falha acontecer mais rápido ou mais devagar. Ela não muda o teto.

Por que T&M é o default para software sob medida

Time and materials é injustamente mal-falado porque soa como cheque em branco. Em uma estrutura saudável, é o oposto.

T&M alinha os incentivos onde precisam estar alinhados. O fornecedor é pago para entregar software funcionando a cada sprint. Você é pago em forma de software funcionando a cada sprint. Ninguém está em posição de perder dinheiro com você, então ninguém está em posição de cortar caminho com você. Quando o escopo muda, a conversa é “isso vai adicionar duas semanas” e não “isso aciona um aditivo contratual que vai levar três semanas para ser negociado”. Decisões saem mais rápido. O produto fica melhor.

T&M também expõe a verdade do trabalho a você. Você vê as horas, a velocidade, os trade-offs. Dentro de um projeto fixed price, o fornecedor tem incentivo para mantê-lo fora da realidade de engenharia, porque toda conversa sobre realidade vira renegociação. Dentro de um projeto T&M, o fornecedor tem incentivo para trazer você para dentro da realidade de engenharia, porque é assim que você fica confiante de que a fatura é justa.

Existe um custo real. T&M significa que você carrega o risco orçamentário, e o orçamento pode estourar. A maneira de neutralizar esse risco não é fixed price. É uma estrutura de T&M com responsabilidade embutida.

A estrutura de contrato T&M que não te sangra

A maioria dos contratos T&M é frouxa demais. O fornecedor manda fatura toda semana, o fundador paga, e três meses depois ninguém tem uma visão limpa do que de fato foi entregue. Usamos uma estrutura mais disciplinada com todo fundador com quem trabalhamos. São cinco cláusulas, todas negociáveis, nenhuma exótica.

Teto por sprint. Defina um número máximo de horas por semana ou por sprint. O fornecedor não pode faturar acima do teto sem acordo escrito, e excessos não acumulam. Esse é um teto suave que mantém o time focado em entregar a coisa mais valiosa em cada ciclo, em vez de moer horas no ticket que estiver aberto.

Demo ou não fatura. Toda sprint termina com uma demo do que foi construído, funcionando. Se a demo não acontece, aquela sprint não é faturável. A cláusula soa agressiva na negociação. Na prática é o que todo fornecedor honesto já faz, e a formalidade protege você no um em cada cinco engajamentos onde o time começa a pular demos por volta do terceiro mês.

Direito de pausar a qualquer milestone. Você pode encerrar o projeto ao final de qualquer sprint sem multa, sem fee de encerramento, sem clawback. Você deve pelas horas já trabalhadas. Ponto. Essa é a cláusula mais importante do contrato. Ela transforma a relação em uma sequência de pequenas apostas, cada uma revalidada pelo que a sprint anterior efetivamente entregou.

Código no seu repositório desde o dia um. A base de código vive na sua organização do GitHub ou GitLab, não na do fornecedor. Cada commit empurrado pelo time é seu imediatamente, não no final do projeto. Já entramos em situações demais onde um fundador descobriu, durante um divórcio com fornecedor, que não era dono do código que fazia a empresa rodar. Essa cláusula torna o divórcio mecanicamente possível.

Um log de decisões, não um relatório de status. O fornecedor mantém um log curto e escrito das decisões tomadas a cada sprint e dos trade-offs por trás, no seu repositório. Não um update sobre tickets fechados. Um registro de “escolhemos Postgres no lugar de MongoDB porque X”, “adiamos o trabalho multi-tenant por causa de Y”. O log é o que permite a um engenheiro futuro, incluindo aquele que vai substituir esse time, entender por que o sistema é como é. É também o que torna a eventual transição sobrevivível.

Um contrato T&M com essas cinco cláusulas dá a você quase toda a segurança do fixed price, quase nenhum dos seus danos de incentivo, e um nível de visibilidade do trabalho que fixed price ativamente esconde. Chamamos isso de T&M com milestones gates e pedimos a todo fundador que negocie por essa estrutura antes de qualquer trabalho começar.

Quando de fato escolher fixed price (e o que pagar a mais para torná-lo real)

Existe um caso restrito para fixed price mesmo em software sob medida real. Ele se aplica quando você tem um deadline externo duro que o fornecedor não pode perder, o escopo está extraordinariamente bem definido, e o fornecedor já construiu exatamente esse formato de coisa antes. Uma data go-live imposta por regulador, uma integração com cliente flagship com uma data de início contratualmente fixada, um deck de demo para uma reunião de board já agendada.

Nesses casos, fixed price não é sobre economizar dinheiro. É sobre comprar seguro de entrega. Para que esse seguro seja honesto, três coisas precisam ser verdade.

O fornecedor embute um prêmio de risco real, e você aceita. Se a cotação parecer suspeitamente baixa para fixed price, saia. O fornecedor ou não entende o trabalho ou está planejando cortar caminho.

Você pré-negocia o protocolo de mudança de escopo antes de assinar. Não “vamos resolver change orders conforme aparecerem”. Um processo escrito que diz: change order abaixo de X reais é aprovado por e-mail; acima de X aciona uma janela de 48 horas para reprecificação e um re-baseline do cronograma. Isso torna as inevitáveis mudanças de escopo administráveis em vez de relacionalmente fatais.

Você mantém pelo menos 25% do valor do contrato no milestone final, pago apenas contra entrega completa e um teste de aceitação combinado. Essa é a alavanca que evita a saída a 80%. O número que você guarda no fim é o que o fornecedor não pode se dar ao luxo de deixar na mesa.

Se você não consegue garantir os três, o contrato fixed price é teatro. Mude para T&M com milestones gates e pare de negociar contra você mesmo.

FAQ rápido

Qual é a diferença entre fixed price e time and materials em linguagem simples?
Fixed price é um número único para um escopo combinado. Time and materials é o ponteiro rodando sobre o tempo que o time efetivamente gasta. O fornecedor assume o risco de entrega no fixed price. Você assume o risco orçamentário no T&M, e dá para neutralizar a maior parte com as cláusulas certas.

Qual é a diferença entre fixed price e um retainer de fee fixo?
Um retainer é uma fee fixa recorrente para um escopo recorrente, em geral contínuo em vez de atrelado a um entregável específico. Está mais perto de T&M com teto do que de um fixed price formato projeto. Retainers funcionam bem depois que a primeira versão do produto está no ar, quando o time está iterando em vez de construir do zero.

Existe modelo híbrido?
Sim, e às vezes é a resposta certa. O padrão mais útil que vemos é uma fase de discovery curta em fixed price (duas a quatro semanas, com escopo limitado a produzir uma arquitetura escrita e uma especificação de produto assinada) seguida de T&M com milestones gates para a construção. A discovery sai barata, o escopo fica genuinamente conhecido ao final, e você começa o trabalho real com um fornecedor que já provou saber escutar.

Quem decide qual a gente assina?
Você, não o fornecedor. Fornecedores preferem fixed price quando estão tentando travar receita e T&M quando acham que o escopo vai crescer. A estrutura certa é a que se encaixa no projeto, não a que se encaixa no trimestre do fornecedor.

O tipo de contrato deve mudar conforme a empresa cresce?
Provavelmente. Software sob medida em estágio inicial, com produto ainda sendo descoberto, quase sempre quer T&M com milestones gates. Quando o sistema está em produção e o time está iterando sobre um formato conhecido, retainers fixed-price podem funcionar bem. O contrato é uma ferramenta, não uma identidade.

O contrato é a relação. Escolha a estrutura que te deixa construir a coisa que você de fato quer, com as pessoas em quem de fato confia. Depois negocie as cláusulas que tornam qualquer estrutura honesta. O número da página um importa menos do que as cinco linhas da página sete.