Equity por desenvolvimento: quando aceitar engenharia em troca de participação

O modelo pode ser racional no pré-seed, quando a empresa tem uma tese promissora, pouco caixa e um caminho razoavelmente definido para validar o produto. Ainda assim, a falta de recursos não basta. O parceiro precisa trazer senioridade, capacidade de decisão e compromisso com o resultado, não apenas alocar desenvolvedores.

Um bom caso é o de uma startup B2B que já entrevistou compradores, tem acesso a usuários-piloto e precisa de um MVP focado para testar uma hipótese comercial em oito a doze semanas. O equity pode financiar a construção inicial, desde que os entregáveis sejam pequenos, verificáveis e ligados a métricas de validação, como ativação, uso recorrente ou aceite de um piloto pago.

Outro cenário possível envolve tecnologia difícil de contratar internamente, como visão computacional, integração IoT, experiências AR/VR ou arquitetura de dados para IA. O parceiro técnico assume parte do risco de execução e, em troca, participa do potencial de valorização. A contribuição, porém, precisa ser estratégica e não equivalente a uma fábrica de código.

O modelo perde força quando a startup já captou recursos, recebeu FAPESC, FINEP ou BNDES, tem receita previsível ou está em estágio Seed avançado. Nesses casos, o caixa existe para comprar capacidade de forma transparente, enquanto a participação deveria ser reservada a cofundadores, executivos-chave ou parceiros que tragam ativos difíceis de substituir.

Também é um sinal de alerta quando o fornecedor pede participação antes de fazer discovery, auditoria técnica ou estimativa de esforço. A OrbeSoft recomenda entender o problema, o mercado e a arquitetura antes de propor uma equipe. Vender equity sem diagnóstico é assumir um compromisso societário com uma solução ainda desconhecida.

Uma comparação útil começa pelo valor econômico do trabalho. Estime horas, perfis, duração, gestão, infraestrutura, suporte e contingência. Depois calcule o custo societário: percentual concedido, valuation de referência, diluição esperada em duas rodadas e valor potencial em um evento de liquidez.

Exemplo hipotético: uma startup avaliada internamente em R$ 8 milhões oferece 4% por um desenvolvimento estimado em R$ 320 mil. Na fotografia inicial, os números parecem equivalentes. Se a empresa captar R$ 4 milhões por 20% e depois vender participação com nova diluição, os 4% originais podem representar menos da metade da participação econômica inicial, mas ainda terão custado o mesmo trabalho e poderão carregar direitos contratuais.

Inclua o custo do atraso. Se o lançamento demora quatro meses a mais, a startup pode perder uma janela comercial, um cliente âncora ou uma rodada. Também inclua o custo da dívida técnica: código sem testes, ambiente inseguro, dependência de uma pessoa e arquitetura difícil de auditar podem consumir o orçamento da próxima captação.

Na squad alocada, você paga pela capacidade e preserva a estrutura societária, mas assume maior responsabilidade por priorização e gestão de produto. No projeto fechado, ganha previsibilidade de escopo e preço, porém precisa controlar mudanças e validar se o fornecedor não está apenas entregando funcionalidades sem resolver a hipótese central.

Para organizar a análise, use cinco eixos com notas de 1 a 5: preservação de caixa, velocidade, controle sobre IP, flexibilidade de escopo e risco de dependência. Dê peso maior ao que limita sua próxima rodada. Uma planilha simples evita que o percentual de equity seja comparado apenas ao preço nominal da proposta.

O calculador de TCO para alocação de equipe pode ser adaptado para acrescentar diluição, custo de atraso e contingência técnica. Para startups com recursos públicos, compare também regras de prestação de contas e elegibilidade antes de classificar o desenvolvimento como economia de caixa.

A primeira proteção é definir exatamente o instrumento de participação. Equity pode envolver quotas, ações, opção de compra, contrato conversível ou outro arranjo. A escolha afeta governança, tributação, direitos de voto e percepção dos investidores, portanto deve ser estruturada com assessoria jurídica especializada em startups.

O acordo deve separar propriedade preexistente de criação específica. Bibliotecas, componentes, métodos, modelos genéricos e ferramentas do fornecedor podem permanecer com ele, mas o código, design, documentação, configurações e artefatos criados para o produto precisam ter licença ou cessão suficiente para operação, evolução, auditoria e venda da empresa.

Inclua vesting para o fornecedor. Em vez de entregar toda a participação no primeiro dia, ela é adquirida conforme o parceiro permanece e cumpre marcos. Um período de carência inicial, chamado cliff, pode evitar que uma saída prematura gere participação desproporcional ao trabalho realizado.

Defina milestones com critérios de aceite, prazo, dependências e responsável pela validação. “MVP pronto” precisa significar algo concreto: fluxos principais implementados, testes mínimos executados, ambiente publicado, monitoramento configurado, documentação entregue e usuários capazes de completar a tarefa prioritária.

A cláusula de saída deve prever rescisão por descumprimento, abandono, violação de confidencialidade ou falha grave de segurança. Ela também deve estabelecer o que acontece com a participação não adquirida, os valores eventualmente devidos e a obrigação de cooperação na transição.

Proteja o acesso operacional. A startup deve ser titular ou administradora das contas de nuvem, domínios, repositórios, ferramentas de análise, certificados e canais de publicação. O checklist de cláusulas técnicas para proteger produto e propriedade intelectual amplia essa revisão.

No Brasil, direitos autorais sobre software e contratos de exploração devem ser avaliados à luz da Lei de Software, disponível no Planalto. Já a estrutura de enquadramento e princípios aplicáveis a startups pode ser consultada no Marco Legal das Startups, Lei Complementar nº 182. Essas referências não substituem aconselhamento jurídico.

O primeiro erro é negociar percentual antes de definir valor e risco. O segundo é tratar vesting como detalhe jurídico, quando ele é o mecanismo que alinha permanência, entrega e participação. O terceiro é aceitar uma cláusula de IP genérica, sem distinguir código criado para a startup de componentes reutilizáveis do fornecedor.

Outro problema recorrente é ignorar o cenário de insucesso. Pergunte o que acontece se a hipótese comercial for invalidada, se o produto pivotar, se a rodada atrasar ou se a startup precisar trocar de equipe. Um acordo robusto permite parar com perdas limitadas, preservar os ativos e continuar aprendendo.

A recomendação prática é usar um modelo híbrido quando houver dúvida. Pague um diagnóstico ou uma primeira fase curta em dinheiro, defina o escopo real e só depois avalie participação por uma etapa de construção estratégica. Essa sequência reduz assimetria de informação para ambos os lados.

Como regra de decisão, aceite equity por desenvolvimento somente quando três condições forem verdadeiras: o caixa é realmente restrito, a hipótese a financiar está suficientemente clara e o parceiro assume risco técnico relevante com capacidade comprovada. Se qualquer uma delas faltar, compare uma squad alocada ou um projeto end-to-end com garantias, transferência de conhecimento e saída contratual.

O objetivo não é preservar cada ponto percentual a qualquer custo. Também não é acelerar a qualquer preço. É escolher a estrutura que aumenta a probabilidade de validar, lançar e escalar o produto sem comprometer propriedade, governança e capacidade de captar.