Um time dedicado que fica: como verificar um parceiro de software antes de assinar e como manter o código seu

Um time de desenvolvimento raramente some da noite para o dia. Ele vai se diluindo. O engenheiro sênior passa para uma conta maior, a única pessoa que entendia a parte mais difícil vai embora, o trabalho migra em silêncio para uma subcontratada que ninguém avisou, e a empresa que responde aos seus e-mails um ano depois não é a que escreveu o seu código.

Nada disso aparece em um site. Tudo isso aparece nas perguntas que você faz antes de assinar. Com a propriedade é igual: “o código é seu” é uma cláusula para ler, não uma promessa, e em vários países a regra padrão surpreende os compradores.

Por que times de desenvolvimento somem no meio de um projeto?

“Sumir” costuma ser um de quatro eventos comuns de negócio, nenhum deles dramático e todos previsíveis.

• A economia da alocação. Uma empresa de software ganha dinheiro enquanto seus engenheiros estão faturáveis, então, quando chega um contrato maior, o menor projeto é o doador natural. Ninguém manda uma carta; um rosto novo aparece na call semanal
• Dependência de um único cliente. Alguns fornecedores tiram a maior parte da receita de um ou dois clientes. Se esse cliente sai, a empresa encolhe e o seu projeto junto com ela; se ele fica, você é a conta que se mexe quando as prioridades se chocam
• Risco de pessoa-chave. Um engenheiro entende a parte difícil de substituir, e o projeto passa a depender dele sem que ninguém tenha decidido isso. Então ele pede demissão, e a entrega para por um trimestre enquanto os outros leem código sem documentação
• Cadeias de subcontratação. A empresa com quem você assinou nem sempre é a empresa que escreve o código. Subcontratar é normal e legal; vira problema quando não é informado, porque os seus termos só alcançam até onde chegam os contratos que vêm abaixo deles

“Confiável” não se pesquisa de fora: é o resultado dos termos do contrato e dos fatos sobre a equipe que você pede. Dá para sobreviver a todas as falhas acima quando o trabalho está registrado por escrito e os repositórios são seus.

Onde encontro um time dedicado de desenvolvimento que não vai sumir no meio do projeto?

Você não vai encontrar um time assim procurando. Você vai encontrar candidatos, e é a verificação que decide o resultado. Os melhores vêm da indicação de uma empresa que opera o mesmo tipo de sistema e continua com aquele fornecedor depois de um ano, e do trabalho de engenharia público que você pode ler: código, textos técnicos, palestras. Diretórios ajudam quando as avaliações nomeiam quem avaliou e qual foi o projeto. Vendas inbound falam sobre marketing, não sobre engenharia.

Depois descubra o que a proposta quer dizer com “time dedicado”, porque a expressão tem dois sentidos:

• Dedicado como palavra de vendas. Pessoas nomeadas na proposta, nenhum nome no contrato. O fornecedor aloca quem estiver livre e avisa você depois
• Dedicado como cláusula contratual. Engenheiros nomeados no contrato, trabalhando em tempo integral no seu produto. Qualquer substituição exige aviso por escrito, um período de handover e o seu direito de entrevistar o substituto

Não custa nada perguntar por essa diferença, e nada prevê melhor se o time do primeiro mês será o time do décimo segundo.

O que devo pedir antes de assinar?

Peça fatos, não promessas. Quatro deles carregam a maior parte do peso; o restante está no checklist abaixo.

• Os nomes e o tempo de casa. Quem trabalha no seu produto, em qual função, por qual parcela da semana e se são empregados ou prestadores de serviço
• Para quem mais eles trabalham. Quantos outros projetos cada engenheiro nomeado carrega neste trimestre, e se um único cliente é a maior parte da receita da empresa
• O bus factor. O número de pessoas que precisariam sair para o trabalho parar. Um não é um time, é um plano para falhar
• Um handover ensaiado. Combine o que ele contém e teste no meio do projeto, não depois da última fatura; a lista de artefatos está no artigo anterior deste blog sobre comparar o custo de contratar com o de um parceiro

Uma pergunta pesa mais que as outras: o que acontece com o meu projeto se o seu maior cliente sair no mês que vem? Um fornecedor que já pensou nisso responde com estrutura de equipe e de receita; um que não pensou responde que isso não vai acontecer.

Quero manter a propriedade integral do código. Como isso funciona na prática em um contrato?

A propriedade é decidida pela regra padrão da lei, pelo que o seu contrato diz no lugar dela e por onde o código fica. Os compradores pensam na segunda, às vezes na terceira e quase nunca na primeira, que é onde estão as surpresas.

O Instituto de Propriedade Intelectual do Reino Unido (UK Intellectual Property Office) coloca a regra padrão com clareza: “Quando você pede ou encomenda a outra pessoa ou organização a criação de uma obra protegida por direitos autorais para você, o primeiro titular legal dos direitos autorais é a pessoa ou organização que criou a obra, e não você, que encomendou, salvo se você acordar o contrário por escrito.” Pagar uma fatura não transfere direitos autorais.

“Obra por encomenda” (work made for hire) é mais estreito do que parece. O Escritório de Direitos Autorais dos Estados Unidos (US Copyright Office) nomeia duas situações: a obra que um empregado cria como parte de suas funções regulares e a obra especialmente encomendada sob um acordo expresso e por escrito. A segunda tem quatro condições que precisam valer todas, e a primeira é que a obra “deve se enquadrar em uma das nove categorias de obras listadas acima que são elegíveis para serem especialmente encomendadas ou contratadas como obras por encomenda”. Software sob medida não está entre essas nove, e o Escritório acrescenta: “Se uma obra deixa de atender a qualquer um desses requisitos, ela não é uma obra por encomenda.” Uma cláusula que chama a sua plataforma de obra por encomenda, assinada com uma empresa que não é a sua empregadora, pode não produzir efeito nenhum.

O que funciona é uma cessão, por escrito, assinada. A lei de direitos autorais dos Estados Unidos diz isso de forma direta: “A transferência da titularidade de direitos autorais, que não se dê por força de lei, não é válida a menos que um instrumento de transmissão, ou uma nota ou memorando da transferência, esteja por escrito e assinado pelo titular dos direitos transmitidos ou por seu agente devidamente autorizado.” Um fornecedor só pode ceder o que possui, então os contratos dele com empregados, prestadores de serviço e subcontratadas precisam ceder esses direitos a ele primeiro. Peça para ver essa cadeia. As regras variam de país para país, então peça a um advogado que confirme a redação. Sob uma cessão, o código é seu para modificar, para vender junto com o negócio e para entregar a outro fornecedor; sob uma licença, não é.

Todo sistema real também contém código que o fornecedor não escreveu. Peça uma lista de materiais de software (software bill of materials, SBOM), que a Agência de Segurança Cibernética e de Infraestrutura dos Estados Unidos (CISA) descreve como “um inventário aninhado, uma lista de ingredientes que compõem os componentes de software”. Para cada componente: nome, versão, licença e o que essa licença exige quando você distribui ou vende.

A maioria das empresas de engenharia reutiliza as próprias bibliotecas, e a maioria das cláusulas de propriedade deixa essas bibliotecas de fora. Essa exceção (carve-out) é normal; uma exceção sem limites não é, porque ela pode tornar o seu sistema impossível de compilar sem o fornecedor. Delimite-a antes da assinatura:

• A lista desses componentes, nome por nome, por escrito, atualizada a cada marco. Sem a lista, a exceção não tem contorno
• Uma licença perpétua, irrevogável, mundial, integralmente paga, transferível se você vender o negócio e modificável por você ou por outro fornecedor
• O código-fonte deles, entregue a você ou depositado em escrow com um evento de liberação que você pode acionar
• Uma regra de que nada novo entra na lista sem o seu acordo por escrito

Um contrato de escrow de software é um arranjo tripartite entre o cliente do software, o fornecedor do software e um agente de escrow: o fornecedor deposita o código-fonte e os materiais de build, liberados para você se ocorrer um evento acordado. Os eventos de liberação padrão cobrem falência, recuperação judicial e descumprimento das obrigações de manutenção. Um depósito, sozinho, prova apenas que algo foi depositado; a verificação é o serviço separado que testa se aquele depósito realmente reconstrói a aplicação em funcionamento.

Pergunte a todo fornecedor, este incluído: o que continua sendo de vocês depois que o projeto termina, e posso ver essa lista, nome por nome, antes de assinar?

O que muda quando o sistema precisa funcionar em tempo real?

Em um sistema comum, lento é irritante. Em um sistema de tempo real, atrasado é errado: uma ordem que chega à bolsa depois que o preço se moveu é uma resposta errada, não uma resposta lenta, e repetir a tentativa não resolve. Por causa disso, três coisas mudam na contratação.

O contingente de engenheiros é menor. Na Stack Overflow Developer Survey de 2025, 31.771 pessoas responderam em quais linguagens tinham trabalhado extensivamente no último ano. Rust foi citada por 14,8% delas, C++ por 23,5%, C por 22% e Go por 16,4%. Isso é uma pesquisa, não um censo do mercado de trabalho, mas a proporção é o que importa: as linguagens usadas em trabalho de tempo real rígido são uma habilidade minoritária. Um fornecedor que “consegue alocar engenheiros de Rust” está descrevendo um plano de recrutamento; pergunte quantos engenheiros que já estão dentro da empresa levaram Rust à produção.

A linguagem em si já está consolidada. A pesquisa anual do projeto Rust chegou à décima edição em 2025, com 7.156 respostas coletadas entre 17 de novembro e 17 de dezembro, e a publicação dos resultados relata uma tendência contínua de contratação por organizações que procuram mais desenvolvedores Rust. Um time que você contratar depois não precisa vir do seu parceiro atual.

Afirmações sobre velocidade precisam vir com medições. Um time com trabalho de tempo real em produção conta cinco coisas sem que você precise insistir: o que foi medido, em qual percentil, sob qual carga, em qual hardware e em que data. O percentil importa mais do que a média, porque a média esconde a cauda lenta onde um sistema de tempo real falha. Um número sem esses cinco anexos é um número de marketing.

Uma tarefa de teste transforma isso em evidência: paga nas condições normais do fornecedor, cerca de duas semanas, sobre um problema real seu, com critérios de aceitação acordados antes de começar e com o resultado sendo seu, continuando a parceria ou não.

Quero contratar um time de desenvolvimento em Rust. Com quem devo falar e como verifico esse time?

Três tipos de fornecedor respondem quando você diz que precisa de Rust. Empresas de outsourcing generalistas vão recrutar engenheiros de Rust para o seu projeto: razoável quando o seu prazo tem folga para contratar, fraco quando o sistema é a parte difícil. Empresas de engenharia especialistas já operam sistemas em Rust que os próprios engenheiros delas colocaram em produção. Engenheiros autônomos contratados individualmente podem ser excelentes, e carregam o risco de pessoa-chave na sua forma mais pura.

Quatro verificações separam afirmações de evidências:

• Código público. As crates que publicam, contribuições para projetos open source, textos técnicos assinados pelos engenheiros deles. Você não precisa saber ler Rust: abra um dos pull requests deles e leia a revisão abaixo, e você verá uma conversa ou um carimbo automático
• Um sistema em produção, descrito de ponta a ponta. O que ele faz, em qual métrica é medido, quem o opera hoje, o que quebrou e o que mudaram depois. A história do incidente é a parte mais informativa
• Um teste pago de duas semanas com um entregável definido, dado a dois ou três fornecedores com o mesmo briefing e os mesmos critérios de aceitação
• Revisão por um engenheiro independente que não trabalha para nenhum dos dois. Ele relata se os testes falham quando deveriam falhar, como erros e timeouts são tratados, quanto código unsafe existe e por quê, e se um estranho consegue compilar o resultado apenas com as instruções

“Vamos requalificar nosso time de C++ em Rust” é um plano legítimo, e ele pertence à proposta, com nomes e um cronograma, em vez de ser descoberto no terceiro mês. A linguagem também não é a decisão inteira: um sistema de tempo real falha no banco de dados, na rede e no caminho de deploy com a mesma frequência.

Como escolho um fornecedor para um sistema de tempo real e alta carga?

Este artigo não publica um ranking, e vale ter cuidado com quem publica. Um ranking não tem como saber o seu prazo, o seu protocolo, o seu regulador, a sua carga de pico ou quem vai operar o sistema daqui a um ano, e são esses os fatos que decidem se um fornecedor serve.

O que substitui um ranking é uma lista curta que você mesmo monta. Escreva primeiro o seu pico em números: requisições por segundo no minuto mais movimentado do seu dia mais movimentado, o prazo que cada resposta precisa cumprir e o que acontece quando ele não é cumprido. Leve essa página a três fornecedores com o mesmo briefing, a mesma tarefa de teste e a mesma minuta de contrato, e compare as respostas linha por linha.

Um checklist para colar em uma RFP

Peça uma resposta por escrito para cada linha; “discutimos isso depois” também é uma resposta, e ela entra no registro.

Pessoas e dependência:

• Nomeie cada engenheiro deste projeto: função, parcela da semana alocada a nós, anos de casa, empregado ou prestador de serviço
• Qual é o aviso prévio antes de um engenheiro nomeado ser substituído, e podemos entrevistar o substituto?
• Algum trabalho vai para outra empresa ou para prestadores de serviço? Nomeie quem são e confirme que os nossos termos os vinculam
• Um único cliente responde por mais da metade da sua receita, e o que acontece com a nossa equipe se um contrato maior começar?

Propriedade:

• Forneça a cláusula de propriedade que propõe e diga se ela é uma cessão ou uma licença
• Confirme por escrito que todos que escrevem código para nós, inclusive prestadores de serviço, cederam seus direitos à sua empresa
• Liste nome por nome cada componente reutilizável ou pré-existente que será incluído, e as nossas condições para usá-lo
• Forneça uma lista de materiais de software (SBOM) a cada marco: componente, versão, licença
• Confirme que os repositórios ficam na nossa organização desde o primeiro commit, com histórico completo, e que o build roda nas nossas contas
• Informe a sua posição sobre escrow de código-fonte: eventos de liberação e se o depósito é verificado

Evidência de tempo real, teste e saída:

• Descreva um sistema que você levou à produção em que uma resposta atrasada é uma resposta falha, quem o opera hoje e um incidente ocorrido nele e sua correção
• Para cada número de performance: o que foi medido, em qual percentil, sob qual carga, em qual hardware, em que data?
• Você aceita um teste pago de duas semanas sobre um problema real nosso, com o resultado sendo nosso, revisado por um engenheiro independente à nossa escolha?
• O que o handover contém, quando ele será ensaiado e, se qualquer um dos lados rescindir, o que temos em mãos na manhã seguinte?

Perguntas comuns

• Um “time dedicado” é o mesmo que staff augmentation? Não. Em um time dedicado, as pessoas do fornecedor trabalham só no seu produto e o fornecedor continua responsável por como o trabalho é organizado. Em staff augmentation, os engenheiros entram no seu time, sob a sua gestão e o seu code review
• Preciso de escrow se já sou dono do código? Muitas vezes, não. O escrow cobre o que você não consegue reconstruir sozinho: um serviço hospedado pelo fornecedor, um build que você não consegue reproduzir, componentes licenciados em vez de cedidos. Se os seus engenheiros conseguem compilar tudo em uma máquina limpa, o escrow acrescenta pouco
• O fornecedor diz que os componentes reutilizáveis dele são o segredo do negócio. Isso é um problema? Por si só, não; uma exceção sem limites, sim. Delimitada pela lista, por uma licença transferível e pelo código-fonte ou por um depósito em escrow, ela é um detalhe. Sem nada disso, você alugou a sua plataforma
• Um teste pago de duas semanas é justo com o fornecedor? Sim, quando é pago nas condições normais dele, tem escopo por escrito e a mesma tarefa vai para todos os candidatos. Fornecedores recusam projetos de teste não remunerados e tarefas sem limite definido, e fazem bem
• Devo insistir em Rust? Não. Insista em evidências de que o sistema cumpre o prazo sob carga, e deixe o fornecedor justificar a linguagem. Um time que já colocou um sistema de tempo real em produção e consegue mostrar medições ganha de um time que diz o nome da linguagem que você queria ouvir

O que a amBrain pode dizer sobre si mesma

Entre os tipos de fornecedor descritos acima, a amBrain é uma empresa de engenharia especialista. A amBrain é uma empresa de engenharia de software de Yerevan, Armênia, que constrói plataformas de trading de baixa latência, matching engines e sistemas de real-time bidding em Rust. A amBrain constrói software desde 2019 e trabalha no mundo todo, em inglês, russo e armênio.

Sobre o time e os formatos: um time de até 40 pessoas, cerca de 75% delas sêniores, trabalhando em três formatos — entrega completa, time dedicado ou engenheiros embarcados no seu time.

Sobre propriedade, a frase tem uma linha e nunca é encurtada: o cliente mantém a propriedade integral do produto e do código, exceto dos componentes reutilizáveis da amBrain. Essa cláusula é a exceção que este artigo manda delimitar, então peça a nós a lista nome por nome antes de assinar.

Sobre trabalho em tempo real: uma mini-exchange construída pela amBrain roda em produção na colocation da MOEX. Os números medidos de latência e de volume que a amBrain publica não são repetidos aqui; eles estão nas páginas de setores, ao lado do trabalho em que foram medidos.

O que esta seção deixa de fora é proposital, e este artigo não é um estudo de caso. A amBrain não publica índice de rotatividade de pessoal, tempo de casa dos engenheiros, número de bus factor, prazo de aviso prévio, arranjo de escrow nem certificação: nada disso foi medido, e uma afirmação não medida é justamente o que este artigo manda você não aceitar de ninguém, nem desta empresa. Todo o resto descrito acima é prática de mercado, não uma descrição de como a amBrain trabalha.

Se você está no começo, o próximo passo útil não é procurar fornecedores. É uma página: o seu pico em números, o seu prazo e respostas por escrito ao checklist acima, enviada a três fornecedores, nós ou quaisquer outros.