Squad dedicado ou fábrica de software: qual modelo entrega melhor

Dois modelos, duas formas de dividir o risco

Você decidiu construir ou evoluir um produto e agora precisa escolher como contratar a entrega. As duas opções mais comuns no mercado brasileiro são o squad dedicado, um time alocado que trabalha com você mês a mês, e a fábrica de software por escopo fechado, um contrato de projeto com preço e prazo acordados na assinatura.

A diferença entre os dois não é de qualidade. É de onde mora o risco e de quem tem o controle. Escolher errado não quebra o projeto de imediato, mas cobra caro seis meses depois, quando o escopo mudou e o contrato não previa isso, ou quando o time alocado ficou grande demais para o trabalho que sobrou. Vou destrinchar os dois modelos pelos critérios que realmente pesam na decisão.

O que cada modelo é na prática

No escopo fechado, você contrata um resultado. O fornecedor levanta requisitos, estima o esforço, fecha um preço e um prazo, e assume a responsabilidade de entregar aquilo. Se a estimativa dele estava errada e o projeto deu mais trabalho, o problema é dele. O risco de execução fica no fornecedor. Em troca, você paga um prêmio embutido no preço, porque ninguém aceita risco de graça.

No squad dedicado, você contrata capacidade. Um time de desenvolvedores, QA e um líder técnico trabalha exclusivamente no seu produto, sob a sua priorização. Você paga pelo time por mês, independente do que exatamente ele entregou naquele ciclo. O risco de execução fica com você: se você priorizou mal ou mudou de ideia toda semana, o time produziu menos, e a conta é sua.

Essa é a distinção central. Escopo fechado transfere risco e reduz seu controle. Squad dedicado te dá controle e transfere o risco de volta para você.

Controle sobre o que é construído

No escopo fechado, o controle é baixo durante a execução. Você definiu o que queria no começo, assinou, e agora acompanha entregas contra um documento. Mudar algo no meio significa abrir um aditivo, renegociar preço e prazo. Cada alteração vira uma pequena negociação comercial. Isso é ruim quando o produto ainda está sendo descoberto e ótimo quando o escopo é estável e bem entendido.

No squad dedicado, o controle é total e contínuo. Você reprioriza a cada sprint. Descobriu na quarta-feira que a feature que parecia essencial não importa tanto? Muda a prioridade na próxima sprint, sem aditivo, sem renegociação. Para produtos que ainda estão validando mercado, essa flexibilidade vale mais do que a previsibilidade de um contrato fechado.

Flexibilidade quando o escopo muda

Aqui está o ponto que mais gente subestima. A maioria dos projetos de software muda de escopo. Não porque alguém planejou mal, mas porque construir software é uma forma de aprender sobre o problema, e você aprende coisas que mudam o plano.

O escopo fechado penaliza mudança por design. Cada alteração custa um aditivo e atrito comercial. Se o seu produto vai mudar bastante, você vai passar mais tempo renegociando do que construindo. Já vi projetos onde metade da energia da liderança foi gasta discutindo o que estava dentro ou fora do contrato original.

O squad dedicado absorve mudança sem fricção. Mudou a estratégia, o time redireciona. Não há aditivo, porque você não contratou um escopo, contratou um time. Essa é a razão pela qual startups e produtos em evolução tendem a preferir o modelo de squad.

Modelo de custo e previsibilidade

O escopo fechado dá previsibilidade de gasto total. Você sabe, na assinatura, quanto o projeto vai custar. Para quem precisa aprovar um orçamento fixo com a diretoria ou com um conselho, isso é uma vantagem concreta. O custo aparente é fixo.

Mas cuidado com a palavra "aparente". O preço de um escopo fechado já embute a margem de risco do fornecedor. Ele estimou o pior caso razoável e cobrou por ele, porque se estourar o prazo, o prejuízo é dele. Então você paga por um risco que talvez não se materialize. E todo aditivo é renegociado sem competição, porque trocar de fornecedor no meio é caríssimo. Na prática, o custo final de um escopo fechado com muitas mudanças costuma passar do orçamento inicial com folga.

O squad dedicado tem custo mensal previsível, mas custo total aberto. Você sabe quanto gasta por mês, não sabe quantos meses vai precisar. Um squad de quatro a cinco pessoas com líder técnico e QA custa, no Brasil em 2026, algo entre R$ 60.000 e R$ 110.000 por mês, dependendo da senioridade. A conta fecha melhor quando o trabalho é contínuo e de longo prazo, porque você não paga o prêmio de risco e não renegocia mudanças.

Quem responde pela qualidade e pela continuidade

No escopo fechado, o fornecedor entrega e, muitas vezes, sai. O contrato tem começo, meio e fim. Depois da entrega, se você não fechou manutenção, o conhecimento do sistema vai embora com o time que construiu. Modernização de sistemas legados costuma ter essa origem: alguém entregou por escopo fechado, o time se dispersou, e ninguém mais entende o código.

No squad dedicado, o time permanece. O conhecimento do produto se acumula no time que fica, sprint após sprint. Isso só vale se o fornecedor tiver rotatividade baixa. Um squad dedicado com turnover alto é o pior dos dois mundos: você paga por continuidade e recebe ramp-up constante. Vale checar esse número antes de assinar. Na Bradata operamos com 0% de rotatividade nas operações em andamento, o que significa que quem começa o produto é quem continua nele.

Quando cada modelo é a escolha certa

Depois de tudo, o critério prático é mais simples do que parece.

Prefira escopo fechado quando:

• O que precisa ser construído está claro e estável, com baixa chance de mudar no meio.
• Você precisa de um orçamento fixo aprovado antes de começar.
• É um projeto pontual, com fim definido, sem evolução contínua prevista.
• Você não tem gestão técnica interna para priorizar um time no dia a dia.

Prefira squad dedicado quando:

• O produto ainda está sendo descoberto e vai mudar conforme você aprende.
• A relação é de longo prazo: o software vai evoluir por meses ou anos.
• Você quer controle sobre a priorização, sprint a sprint.
• Continuidade e acúmulo de conhecimento no time importam para a manutenção futura.

O teste rápido

Faça uma pergunta a si mesmo: o quanto do que vou construir eu já sei hoje?

Se a resposta é "quase tudo, o escopo é claro", o escopo fechado te dá previsibilidade e transfere o risco de execução. Se a resposta é "vou aprender enquanto construo", o squad dedicado te dá a flexibilidade de mudar sem pagar pedágio a cada alteração.

Não existe modelo superior. Existe o que casa com o grau de incerteza do seu produto e com quanto controle você quer manter. A maioria dos atritos que vejo em contratos de software vem de uma escolha desalinhada aqui: um produto incerto amarrado num escopo fechado rígido, ou um trabalho simples e estável pago no modelo caro de um time alocado por tempo indeterminado. Acertar essa decisão no começo economiza a renegociação e o retrabalho que vêm depois.