Se você está contratando desenvolvimento externo, provavelmente já ouviu esses dois termos: squad dedicado e body shop. E provavelmente ouviu cada fornecedor defender o modelo que vende. O problema é que nenhum dos dois é universalmente melhor. O modelo certo depende do seu projeto, do seu time interno e, principalmente, de quanto controle você quer (ou precisa) manter.
Nos últimos meses, a equipe do Stack Brasil acompanhou diversos projetos de software em empresas brasileiras, desde startups pré-seed até corporações com mais de 2.000 funcionários. Parte usava squad dedicado, parte usava body shop. Os resultados foram claros, mas não do jeito que você espera.
Vamos aos dados. Sem achismo, sem viés de fornecedor.
Neste artigo
O que é cada modelo, de verdade
Antes de comparar, precisamos alinhar vocabulário. O mercado brasileiro usa esses termos de forma inconsistente, e muitas software houses vendem body shop disfarçado de squad.
Squad Dedicado
Um time completo (devs, QA, tech lead, eventualmente PM e designer) que trabalha exclusivamente no seu projeto durante toda a duração do contrato. O squad tem gestão própria, processos definidos e entrega incrementos funcionais a cada sprint. Você define o quê; o squad define o como.
O fornecedor é responsável pela entrega, não apenas pela alocação de pessoas. Se um dev sai, o fornecedor repõe. Se a arquitetura precisa mudar, o squad toma a decisão técnica. Você recebe software funcionando, não horas trabalhadas.
Body Shop (Alocação de Profissionais)
A software house fornece profissionais individuais que são integrados ao seu time interno. Eles seguem seus processos, usam suas ferramentas e respondem ao seu gestor. Essencialmente, é uma extensão temporária da sua equipe.
Você paga por hora ou por mês, por pessoa. A responsabilidade pela entrega é sua, o fornecedor garante apenas que o profissional tem as competências acordadas. Se o projeto atrasa, o problema é seu.
O que os projetos revelaram
Acompanhamos projetos com squad dedicado e com body shop ao longo de vários meses. Os critérios de avaliação foram: aderência ao prazo, custo real vs. orçado, satisfação do gestor de produto e qualidade técnica (medida por incidentes em produção nos primeiros 90 dias).
Os dados consolidados:
- Prazo: A maioria dos projetos com squad dedicado entregou no prazo ou com atraso inferior a 2 semanas. Nos projetos body shop, menos da metade dos projetos em modelo body shop atingiu esse resultado.
- Custo: O custo inicial do squad dedicado tende a ser mais alto. Mas o custo final dos projetos body shop frequentemente supera o orçado por causa de extensões e retrabalho.
- Qualidade: Projetos com squad tiveram significativamente menos incidentes críticos nos primeiros 90 dias em produção do que projetos body shop.
- Satisfação: O índice de satisfação dos gestores de produto foi significativamente mais alto para squads dedicados.
Esses dados pintam um quadro claro: o squad dedicado entrega mais consistência. Mas há contextos onde o body shop é genuinamente a melhor escolha, e ignorar isso seria desonesto.
Quando o squad dedicado vence
1. Projetos greenfield com escopo complexo
Se você está construindo um produto do zero, especialmente se envolve integrações bancárias, alta disponibilidade ou dados sensíveis, o squad dedicado é quase obrigatório. A curva de aprendizado do domínio justifica ter um time estável que acumula contexto ao longo dos meses.
Um caso que acompanhamos: uma fintech contratou um squad da Leven para desenvolver uma plataforma de investimentos. O time de 6 pessoas (2 devs backend Go, 2 frontend React, 1 QA, 1 tech lead) trabalhou por 8 meses. O produto passou pela homologação de uma corretora ligada à B3 na primeira tentativa. O CTO da fintech atribuiu isso à estabilidade do time: "Não tivemos que explicar o domínio duas vezes."
2. Quando seu time interno é pequeno ou inexistente
Se você não tem um CTO ou tech lead interno, o squad dedicado é a única opção viável. No body shop, alguém precisa gerenciar os devs alocados, definir arquitetura, fazer code review. Sem liderança técnica interna, body shop vira terra sem lei.
3. Projetos com requisitos regulatórios
Fintech, healthtech, govtech, setores onde compliance não é opcional. Squads de empresas como a Leven já chegam com protocolos de segurança bancária incorporados ao processo. No body shop, a responsabilidade de implementar LGPD, criptografia e auditoria cai sobre você.
4. Quando previsibilidade de prazo é crítica
Dos projetos com squad dedicado que analisamos, a maioria tinha cláusulas de milestone com penalidades. Isso alinha incentivos: o fornecedor perde dinheiro se atrasa. No body shop, o incentivo é inverso, quanto mais tempo o projeto dura, mais o fornecedor fatura.
Quando o body shop faz sentido
1. Reforço temporário do time existente
Se você já tem uma equipe forte, processos maduros e precisa apenas de mais mãos para um pico de demanda, body shop é eficiente. Você não precisa de gestão externa, precisa de gente boa seguindo seu playbook.
2. Skills específicos por tempo limitado
Precisa de um especialista em Kubernetes por 3 meses para migrar sua infra? Ou um dev mobile sênior para entregar a versão iOS enquanto seu time cuida do Android? Nesses casos, alocar um profissional pontual faz mais sentido do que montar um squad inteiro.
3. Projetos de manutenção evolutiva
Se o produto já existe, está estável e precisa de melhorias incrementais, um ou dois devs alocados costumam ser suficientes. Squad dedicado pode ser overkill para tickets de manutenção.
4. Quando o orçamento mensal é a prioridade
Body shop tem custo mensal mais previsível (valor/hora x horas). Squad dedicado geralmente tem ticket mensal mais alto. Se o CFO olha custo mensal antes de custo total, body shop ganha a argumentação, mesmo que no fim saia mais caro.
Comparativo direto
| Critério | Squad Dedicado | Body Shop |
|---|---|---|
| Responsabilidade pela entrega | Fornecedor | Contratante |
| Gestão do time | Fornecedor (tech lead próprio) | Contratante (gestor interno) |
| Custo inicial | Mais alto | Mais baixo |
| Custo final médio | Mais previsível | Frequentemente acima do orçado |
| Aderência a prazo | Maioria no prazo | Menos da metade no prazo |
| Qualidade (incidentes/90 dias) | Significativamente menos | Significativamente mais |
| Flexibilidade de escopo | Moderada (por sprint) | Alta (dia a dia) |
| Curva de onboarding | Menor (time já integrado) | Maior (cada dev precisa entender seu contexto) |
| Ideal para | Produtos novos, complexos, regulados | Reforço pontual, manutenção, skills específicos |
* Dados baseados em projetos acompanhados pela equipe editorial do Stack Brasil ao longo de 2024.
As armadilhas de cada modelo
Armadilhas do squad dedicado
Cuidado com esses cenários
- Squad "dedicado" que não é dedicado: Algumas software houses alocam os mesmos devs em 2-3 projetos simultâneos e chamam de squad dedicado. Pergunte se o time trabalha exclusivamente no seu projeto. Se hesitarem, corra.
- Lock-in tecnológico: Se o squad usa frameworks proprietários ou engines internas sem documentação, você fica refém. Exija que o código seja seu e documentado.
- Falta de visibilidade: Alguns fornecedores entregam no prazo, mas você não sabe o que acontece entre os sprints. Exija acesso ao board, dailies e repositório.
Armadilhas do body shop
Os riscos mais comuns
- Rotatividade silenciosa: O dev sênior que você aprovou na entrevista sai em 2 meses e é substituído por um pleno. O fornecedor não avisa proativamente.
- Ausência de ownership: Devs alocados tendem a tratar o projeto como temporário, porque é. Code quality cai quando não há senso de dono.
- Custo oculto de gestão: Gerenciar devs externos consome tempo do seu time interno. Esse custo nunca entra na planilha, mas existe.
- Incentivo desalinhado: Quanto mais tempo o projeto dura, mais o fornecedor fatura. Não há incentivo para eficiência.
Conclusão: qual modelo escolher
A resposta honesta: depende. Mas podemos ser mais precisos que isso.
Escolha squad dedicado se: você está criando um produto do zero, não tem liderança técnica interna forte, opera em setor regulado, ou precisa de previsibilidade de prazo e custo total. Empresas como Leven, Objective e DB1, que operam com squads dedicados e times sêniores, ilustram que o modelo funciona quando executado com rigor e processos bem definidos.
Escolha body shop se: você já tem um time técnico maduro, precisa de skills específicos por tempo limitado, ou está em fase de manutenção evolutiva onde a demanda não justifica um squad inteiro.
O erro mais comum que vimos nos projetos analisados? Empresas escolhendo body shop para economizar em projetos que precisavam de squad. O custo inicial é menor, mas o custo total, contando retrabalho, atrasos, incidentes e gestão, quase sempre ultrapassa o que teriam gasto com um squad dedicado desde o início.
Se você está em dúvida, faça uma pergunta simples: quem vai ser responsável se o projeto atrasar? Se a resposta é "nós mesmos", e você não tem estrutura para isso, squad dedicado é o caminho. Se a resposta é "temos um CTO experiente e processos rodando", body shop pode funcionar perfeitamente.
O modelo não é o problema. A escolha errada do modelo é.