Uma empresa pode contratar a melhor software house do mercado e ainda fracassar por não ter dono para o produto. Pode montar um time interno caro e mantê-lo ocupado com uma tese não validada. Também pode chamar uma relação de co-building quando, na prática, apenas terceirizou desenvolvimento. O modelo de construção importa, mas só depois de definir qual responsabilidade precisa ser assumida.
Quatro modelos, quatro compras diferentes
- Time próprio: a empresa contrata e desenvolve capacidade permanente, gestão, cultura e conhecimento interno.
- Software house ou projeto: um fornecedor responde por um escopo, prazo, entregáveis e critérios de aceite contratáveis.
- Squad parceira: a empresa adiciona capacidade multidisciplinar por uma cadência, normalmente sob direção de produto existente.
- Co-building: especialista de domínio e parceiro de produto e tecnologia compartilham construção, aprendizagem e decisões conforme fronteiras definidas.
Advisory e liderança fracionada são dimensões adicionais. Advisor ajuda a direção a pensar e desafiar uma decisão; CTO/CPO as a Service assume um mandato recorrente de liderança. Eles podem orientar um time interno ou fornecedores, mas não devem ser vendidos como sinônimo automático de execução.
Compare o sistema, não a diária
- Propriedade: quem decide roadmap, arquitetura, dados, risco e qualidade?
- Velocidade: quanto tempo leva para formar a capacidade e obter a primeira evidência útil?
- Custo total: contratação, coordenação, infraestrutura, rotatividade, retrabalho, suporte e transição.
- Aprendizagem: em qual organização o conhecimento de usuário, produto e tecnologia se acumula?
- IP e portabilidade: quem controla repositórios, documentação, licenças, dados e dependências?
- Continuidade: quem opera, responde por incidentes e evolui a solução depois da entrega?
- Elasticidade: o modelo consegue crescer, reduzir ou mudar composição sem destruir contexto?
- Saída: a empresa consegue trocar parceiro, internalizar ou encerrar sem perder o ativo?
O estágio altera a melhor resposta
- Tese inicial: pequeno núcleo interno com acesso ao domínio, advisory ou co-building pode aprender antes de ampliar estrutura.
- Escopo claro e finito: software house ou projeto tende a funcionar quando interfaces e aceite podem ser definidos.
- Prioridade clara, capacidade insuficiente: squad parceira complementa o time sem inventar uma nova direção.
- Produto central e em crescimento: liderança e time próprios ganham importância para preservar aprendizagem e resposta contínua.
- Transição ou recuperação: liderança fracionada pode estabilizar direção, fornecedores e prioridades enquanto a estrutura definitiva é preparada.
- Commodity ou capacidade não diferenciadora: comprar uma plataforma ou serviço pode ser melhor do que qualquer modelo de desenvolvimento.
Quanto mais central o produto, maior a capacidade que precisa ficar dentro
Isso não significa escrever internamente cada linha de código. Significa manter dentro da empresa entendimento do usuário, propriedade da decisão, arquitetura suficiente para avaliar consequências, acesso aos dados e capacidade de operar fornecedores. Terceirizar componentes pode ser eficiente; terceirizar a compreensão do próprio ativo cria dependência.
Quando não contratar a Tech Human
- Quando o produto já é central, a demanda é permanente e a empresa está pronta para formar liderança e time próprios.
- Quando existe um escopo simples, fechado e bem especificado que um fornecedor especializado pode entregar melhor.
- Quando uma plataforma madura atende ao requisito sem diferenciação relevante.
- Quando a empresa não dará acesso a usuários, dados, decisores ou responsáveis operacionais necessários.
- Quando o objetivo é apenas obter uma validação decorativa para uma decisão já irreversível.
- Quando preço é o único critério e não há espaço para governança, evidência, segurança ou transferência de conhecimento.
O desenho híbrido costuma refletir melhor a realidade
Uma empresa pode manter product owner, especialistas de domínio e arquitetura internamente; usar co-building no discovery; contratar plataformas para componentes comuns; trazer uma squad para o primeiro ciclo; e internalizar capacidades críticas conforme o produto amadurece. O importante é planejar a transferência desde o início, não tratá-la como emergência no fim do contrato.
Perguntas que melhoram qualquer proposta
- Qual problema este modelo assume e qual responsabilidade permanece conosco?
- Que evidência será produzida nos primeiros 30, 60 e 90 dias?
- Quem pode mudar prioridade, arquitetura e critério de aceite?
- Como custo, dependências e qualidade serão observados além de horas e entregas?
- Onde ficam código, dados, documentação, decisões e credenciais?
- Como especialistas internos participam e absorvem conhecimento?
- O que acontece se reduzirmos escopo, trocarmos fornecedor ou internalizarmos a frente?
- Qual sinal mostrará que escolhemos o modelo errado?
A decisão mais madura não é terceirizar ou internalizar por princípio. É colocar cada responsabilidade onde ela pode ser exercida com contexto, incentivo e continuidade. O modelo pode mudar à medida que o produto sai de tese, ganha uso e se torna crítico. O contrato deve permitir essa evolução em vez de transformar a primeira escolha em dependência permanente.