Time interno vs outsourcing de desenvolvimento de software: a pergunta está errada, e essa é a pergunta que funciona

Por que o frame binário desmonta para a maioria dos fundadores não-técnicos, a decisão de três eixos que entra no lugar, e uma regra de 90 dias para escolher o caminho sem queimar um milhão de reais.

Um fundador que vou chamar de Diego sentou na minha frente em setembro do ano passado com duas vagas abertas no laptop. Estava levantando uma Série A. Tinha onze clientes pagantes em um protótipo no-code. O board queria ver “uma área de engenharia” antes do próximo term sheet. As vagas eram para um Senior Backend Engineer e um Senior Frontend Engineer, ambas mirando R$ 30 mil de salário base, ambas para começar em seis semanas. Ele me perguntou o que eu achava dos salários.

Eu fiz uma pergunta diferente. Qual era o problema de engenharia que ele estava contratando para resolver. Ele citou o fluxo de cobrança quebrado do protótipo, três pedidos de feature de cliente, e a integração com a ferramenta de analytics que o board gostava. Esses são problemas de produto, falei. Não de engenharia. O menor time que entrega um v1 funcional para essa lista não se parece com dois engenheiros sêniores.

A escolha entre time interno vs outsourcing de desenvolvimento de software é a pergunta que o Diego estava de fato fazendo, exceto que não é uma pergunta. São três perguntas empilhadas em uma frase, e respondê-las como um binário é como fundadores não-técnicos queimam nove meses e um milhão de reais antes de perceber que contrataram contra o estágio da empresa.

Esse artigo é o framework que usamos com fundadores na cadeira do Diego. Funciona para builds early-stage, crescimento pós-PMF, e para o meio desconfortável onde nenhum dos dois caminhos puros parece certo.

A resposta curta para o leitor do AI Overview

Time interno (in-house) significa contratar engenheiros como funcionários CLT da sua empresa. Outsourcing de desenvolvimento de software significa contratar um parceiro externo (uma software house, um time freelancer, ou uma agência offshore) para construir o software por você. A maioria dos fundadores não-técnicos, especialmente antes do product-market fit, tem um resultado melhor com outsourcing ou um caminho híbrido do que com um time interno completo, porque contratar engenheiros gera overhead de gestão, risco de hiring, e compromissos de capital que negócios early-stage ainda não estão preparados para absorver.

Essa é a resposta para a pergunta-título. O resto do artigo é sobre por que a maioria dos fundadores ignora essa resposta, e como saber quando você é a exceção.

Por que o frame binário desmonta

Os dez primeiros resultados do Google para “in-house vs outsourcing software development” são quase idênticos. Cada um é uma tabela equilibrada de prós e contras hospedada no site de um vendor cujo negócio é vender outsourcing. O truque retórico é consistente: outsourcing ganha em velocidade, custo, e acesso a talento; in-house ganha em cultura, controle, e ownership de longo prazo; você escolhe pelas suas prioridades. Daí um botão diz “Fale com nossos especialistas.”

Esse frame desmonta no contato com a realidade. Por dois motivos.

Primeiro, a maioria dos fundadores não-técnicos não está escolhendo entre dois caminhos prontos. Está escolhendo entre um caminho que ainda não tem condição de bancar e outro caminho que mandaram evitar. Um fundador pré-Série A que contrata quatro engenheiros sêniores assina um run rate anual de R$ 1,4 milhão antes de saber se o produto se sustenta. Um fundador que terceiriza o build inteiro para uma agência offshore de US$ 25 a hora economiza caixa e herda um ativo que não consegue manter quando a agência para de retornar ligação. Nenhum dos caminhos puros é a resposta certa para esse estágio.

Segundo, a pergunta esconde três problemas diferentes. Construir a primeira versão de um produto. Escalar e manter um produto que já roda. Suportar ferramentas internas que o time de operações usa. Cada um tem uma resposta certa diferente. Os artigos de prós e contras achatam tudo numa decisão só e perdem o fundador.

A pergunta certa não é time interno vs outsourcing. A pergunta certa é qual problema você está resolvendo, em qual estágio, com qual orçamento por trimestre. Três eixos. Quando você se posiciona neles, o caminho cai sozinho.

A decisão de três eixos

Esse é o framework. Passe por todos os três.

Eixo 1, o problema

Existem três problemas de engenharia, e só três. Seja honesto sobre qual é o seu.

Construir. Você ainda não tem software rodando para clientes pagantes. Tem um protótipo, um stack no-code que ultrapassou seu limite, ou uma especificação escrita. O trabalho é engenharia de produto: definir o que construir, sequenciar a construção, e entregar um v1 que se sustenta.

Escalar. Você tem software em produção. Clientes estão usando. O trabalho é manutenção, performance, integrações, features pedidas por cliente, e a construção lenta da infraestrutura interna (testes, deploy, monitoramento) que permite o time andar mais rápido sem quebrar coisa.

Operar. Seu negócio roda em ferramentas internas (dashboards, sistemas de cobrança, fluxos de operações) que ninguém de fora da empresa vê. O trabalho é trocar planilhas por software no qual o time confia, construir admin tools que o suporte usa, automatizar passagens manuais entre áreas.

Três problemas, três respostas certas diferentes. A maioria dos fundadores tem um ou dois desses ao mesmo tempo. Construir e escalar raramente acontecem em paralelo dentro de uma empresa pequena; o time que acabou de construir o v1 vira o time que escala.

Eixo 2, o estágio

Pré-PMF. Você ainda não encontrou product-market fit. Clientes estão usando alguma coisa, mas o loop de valor não é estável. Receita é imprevisível, churn é alto, a especificação muda todo mês. Qualquer coisa que trave compromisso agora (funcionários, contratos plurianuais, infraestrutura customizada) é perigoso porque você ainda não sabe o que construir.

Pós-PMF, crescimento inicial. Um produto está rodando. A unit economics é honesta. Você está escalando demanda e a pergunta de engenharia muda de “o que devemos construir” para “como entregamos mais rápido sem quebrar mais.” Esse é o estágio onde in-house começa a importar, porque o trabalho compõe e o ownership do código vira um ativo real.

Estabelecido. Engenharia agora é o músculo operacional do negócio. Você tem um roadmap medido em anos, não meses. Estratégia de produto e estratégia de engenharia se entrelaçam. Nesse ponto, um time in-house é quase sempre a resposta certa para o produto core, e outsourcing vira tática para picos de capacidade ou trabalho especializado.

Eixo 3, o orçamento por trimestre

Seja específico sobre quanto você consegue gastar em engenharia nos próximos quatro trimestres, manutenção pós-launch incluída.

Um engenheiro sênior no Brasil, totalmente carregado, custa entre R$ 25 mil e R$ 40 mil por mês (no mercado americano, US$ 20 mil a US$ 25 mil). Um time interno de dois engenheiros é R$ 600 mil a R$ 960 mil por ano antes de você contar o gerente que vai precisar contratar acima deles. Uma software house sênior no mesmo mercado custa entre US$ 20 mil e US$ 40 mil por mês para um time embedded de dois a três engenheiros mais um tech lead e um project manager. Envelope diferente, formato de compromisso diferente. Uma agência offshore a US$ 25–50 por hora custa US$ 40 mil a US$ 80 mil por trimestre para um time pequeno, mas entrega qualidade variável e exige mais tempo do fundador no review.

Orçamento não é variável livre. Compõe. Um time que custa R$ 200 mil por mês também custa R$ 200 mil mês que vem, no mês seguinte, e no mês em que você descobrir que escolheu o caminho errado.

Como os três eixos escolhem o caminho

Se posicione na grade. O caminho aparece.

Construir, pré-PMF, orçamento abaixo de R$ 1 milhão para o ano. Não contrate engenheiros. O menor time que entrega um v1 para um fundador não-técnico nesse estágio é um a dois engenheiros sêniores de uma software house com um tech lead revisando o trabalho, mais você sendo dono da especificação e do loop de feedback do cliente. O artigo sobre como avaliar uma software house cobre o que olhar nesse parceiro. Se o orçamento é abaixo de R$ 200 mil para o v1, no-code ou uma build customizada bem estreita é a resposta; o artigo sobre como criar um software quando você não é o programador caminha pelas quatro decisões em ordem.

Construir, pré-PMF, orçamento entre R$ 1 milhão e R$ 5 milhões para o ano. Mesma resposta. Você tem orçamento para uma software house com time mais sênior, mas o erro nesse estágio é converter esse orçamento em headcount antes de saber o que construir. Já vimos fundadores com seed de R$ 7 milhões transformarem isso em time de seis engenheiros e um CTO e produzirem nada utilizável em dezoito meses. O time não é o gargalo. A decisão de produto é.

Construir, pós-PMF, qualquer orçamento acima de US$ 300 mil/trimestre. Aí in-house começa a importar. Você conhece o produto. Conhece o cliente. Consegue escrever uma vaga que nomeia o problema de engenharia, não só a feature. Contrate um engenheiro sênior que já construiu e escalou antes. Combine ele com o parceiro que construiu o v1 se você usou um. O handoff é trabalho real, trate dessa forma. O artigo sobre fractional CTO cobre o papel-ponte entre “não temos liderança técnica” e “acabamos de contratar nosso primeiro VP de Engenharia.”

Escalar, pós-PMF. Time interno, ponto. Você não consegue terceirizar julgamento de produto pra sempre, e quem mantém o código precisa morar no código. Outsourcing aqui é tática para picos, não estratégia.

Operar (ferramentas internas), qualquer estágio. Quase nunca é problema de time de engenharia interno. Ferramentas internas são o pão com manteiga de uma boa software house, ou, se o volume permitir, um stack no-code com um implementador part-time. O artigo sobre quanto custa desenvolver um app abre os drivers de orçamento que mais movem esse número.

O caminho mais difícil de defender em qualquer célula dessa grade é “contratar dois engenheiros sêniores in-house, pré-PMF, com orçamento abaixo de R$ 1 milhão.” Esse é o erro do Diego. É também o caminho que a maioria dos fundadores escolhe por padrão quando confunde a pergunta de quem constrói com a pergunta de quem é dono.

O que você de fato compra em cada caminho

Os artigos de prós e contras erram essa parte porque listam atributos, não compromissos.

In-house compra ownership e overhead de gestão. Você é dono do código, do time, e das decisões de gente. Também é dono do pipeline de recrutamento, das avaliações de performance, dos planos de equity, do escritório ou da infraestrutura remota, do gerente que vai entrar em cima do time, e dos meses de bandwidth de gestão que você passa a não ter mais para vendas. Para um fundador não-técnico, o custo de gestão é a maior linha escondida. Já vimos fundadores irem de CEO para “a pessoa que toca o standup de engenharia” dentro de um trimestre, que é exatamente o que estavam tentando evitar contratando o time.

Outsourcing compra capacidade e escopo definido. Você compra trabalho especificado por um preço especificado em um prazo especificado. Não compra ownership das pessoas, do crescimento delas, ou da lealdade delas com a sua empresa. Também não compra a opção de redirecionar elas na terça porque a call de cliente da segunda mudou tudo; só compra essa opção se escreveu o contrato dessa forma e o parceiro está montado para isso. O parceiro certo faz o outsourcing parecer colaboração; o parceiro errado faz parecer abrir ticket para uma caixa preta.

Híbrido compra a opção de converter depois. Um fundador que trabalha com uma software house sênior no v1 e depois contrata o primeiro engenheiro in-house, frequentemente a mesma pessoa que liderou a build, comprou a opcionalidade de converter capacidade em ownership quando o timing for certo. Esse é o caminho que a Pixel Breeders constrói e o caminho que a maioria dos fundadores não-técnicos deveria adotar como padrão.

As cinco perguntas que escolhem o caminho

Responda cada uma em uma frase antes de assinar qualquer contrato, in-house ou outsourcing.

1. Que problema de engenharia eu estou contratando para resolver, em linguagem clara? Se a resposta honesta é “preciso entregar as próximas três features de produto,” isso é problema de engenharia de produto, e um parceiro que já entregou v1 antes é mais rápido do que uma contratação fresca aprendendo o seu código do zero. Se a resposta honesta é “preciso escalar a plataforma de 50 para 500 clientes,” isso é problema de manutenção e infraestrutura, e um engenheiro in-house que mora no código ganha.

2. Em que estágio o negócio realmente está, sem o deck? Pré-PMF é a resposta se a receita é imprevisível e o churn é alto. Pós-PMF é a resposta se cliente volta e a unit economics fecha. O fundador pré-PMF que diz para o board “estamos pós-PMF” contrata contra o estágio errado, todas as vezes.

3. Qual é o orçamento real por trimestre para engenharia, incluindo os meses depois do launch? Uma build de seis meses sem reserva de manutenção é uma build de seis meses seguida de um produto quebrado. O artigo sobre quanto custa desenvolver um app abre os drivers que mais movem esse número.

4. Quem do time vai ser dono do entregável de engenharia depois que ele for ao ar? Software sem dono interno quebra silenciosamente. Se a resposta é “o desenvolvedor que vou contratar,” o sistema é frágil por design. Se a resposta é “eu, com reuniões semanais de review com o parceiro,” o caminho pode ser terceirizado. Se a resposta é “ainda não sabemos,” o caminho precisa começar contratando o dono primeiro, antes de qualquer linha de código.

5. O que muda se eu estiver errado? Se a resposta errada significa demitir um parceiro e onboardar outro, o custo é dois meses e um contrato. Se a resposta errada significa demitir quatro engenheiros, isso é um ano de rescisões, equity desfeito, e o time que assistiu como você lidou contando para o próximo candidato exatamente o que viu. Downside assimétrico deveria fazer o caminho de menor compromisso ganhar sempre que o upside for parecido.

A regra dos 90 dias

Se um fundador não consegue responder as cinco perguntas acima em uma frase cada, o caminho à frente não é “contratar mais rápido.” O caminho é noventa dias de discovery estruturado: escrever a especificação numa página, conversar com dez clientes, entregar uma versão fina do produto (no-code ou parceiro), olhar o que quebra, e aí decidir quem constrói depois.

Já rodamos essa regra com vinte e poucos fundadores nos últimos três anos. O padrão é consistente. Os que tiraram os noventa dias produziram um job spec que nomeava os problemas de engenharia, não as features. Os que pularam essa fase contrataram quatro engenheiros no mês um e reorganizaram o time no mês sete. Não existe versão dessa história em que o segundo grupo ficou mais feliz com o resultado.

Quando in-house é a resposta certa

In-house ganha em condições específicas. Seja honesto sobre se elas se aplicam a você.

O produto está rodando. Cliente paga, volta, e indica. A pergunta deixou de ser “o que construir” e virou “como entregar mais rápido.” Contratar engenheiros que moram no código agora é ativo que compõe.

Você consegue nomear os problemas de engenharia, não só as features. “Precisamos reduzir o p95 de latência de 800ms para 200ms,” não “o app parece lento.” “Precisamos migrar de uma instância única de Postgres para um setup com sharding antes do Q3,” não “escalar o banco.” Se a sua especificação de hiring lê como um backlog de produto, você ainda não está contratando engenheiros; está contratando builders de produto, e um parceiro é mais rápido.

Você tem um engenheiro no time ou um fractional CTO que sabe contratar outros engenheiros. Um fundador não-técnico não consegue avaliar o julgamento técnico de um engenheiro sênior backend sozinho. Pode tocar o processo de recrutamento e ser dono da decisão cultural, mas a régua técnica precisa ser colocada por alguém que já entregou o tipo de sistema que você está tentando construir. Sem essa pessoa, a contratação in-house é cara e coroa com US$ 250 mil por ano em jogo.

O runway cobre a curva de ramp-up. Engenheiros sêniores novos levam três a seis meses para virarem net-positive em um código que não escreveram. Se o seu runway é de doze meses, você está apostando a empresa em esses engenheiros virarem net-positive em nove. É uma aposta que a maioria dos fundadores pré-Série B não deveria fazer.

Se essas quatro condições não estão todas verdadeiras, a resposta quase sempre é uma build liderada por parceiro com plano claro de converter para in-house quando elas estiverem. O artigo sobre o papel do CTO que você ainda não consegue contratar cobre o que o fundador continua devendo para o time em qualquer dos caminhos.

Quando outsourcing é a resposta certa

Outsourcing de desenvolvimento de software ganha em três situações e perde em uma quarta. A quarta é o que a SERP entende errado.

Ganha para construir o v1 com prazo apertado e capital pré-PMF. A capacidade é alugada. O compromisso é delimitado. O trabalho do fundador é a especificação e o loop de cliente, não o time.

Ganha para capacidade especializada que um time interno não tem como manter. Um engagement curto com uma firma de segurança para fazer um pentest antes de uma rodada. Uma firma de infraestrutura de dados para montar o pipeline de analytics uma vez. Esses são problemas de pico, não de regime.

Ganha para ferramentas internas em quase qualquer estágio. Uma software house com track record certo de operações entrega um dashboard admin em oito semanas que um time interno levaria seis meses para priorizar. Ferramentas internas merecem a mesma craft que software de cliente, mas raramente merecem um headcount dedicado.

Perde quando o fundador trata o parceiro como body shop. “Me manda 4 React engineers por 2 meses.” Isso não é outsourcing. É staff augmentation, e é o caminho que produz o pior código, o pior handoff, e a pior experiência de fundador. Se o fundador não consegue descrever o trabalho como um problema com definição de pronto, o trabalho não está pronto para ser terceirizado.

A resposta honesta que a maioria dos artigos evita

O caminho certo para a maioria dos fundadores não-técnicos com quem trabalhamos é híbrido, com o timing invertido em relação a como a pergunta costuma ser feita. Eles começam com um parceiro que constrói o v1 com o fundador sendo dono da especificação. Convertem um ou dois desses engenheiros em time interno depois do PMF, frequentemente contratando o tech lead do parceiro direto. Mantêm a relação com o parceiro para picos de capacidade e ferramentas internas. O time puro in-house só emerge no ano três ou quatro, quando a empresa está estabelecida e a função de engenharia é um dos músculos operacionais do negócio.

Essa sequência não é nova. É o que todo fundador não-técnico funcional na nossa rede fez. Os artigos da SERP não dizem isso porque são escritos por vendors vendendo um estágio da sequência por vez. A decisão não é in-house versus outsourcing. É in-house e depois outsourcing, ou outsourcing e depois in-house, com a ordem definida pelo que a empresa de fato precisa em cada estágio.

FAQ

Qual a diferença entre outsourcing e desenvolvimento de software in-house?

Outsourcing de desenvolvimento de software significa contratar um parceiro externo (uma software house, um freelancer, ou uma agência) para construir o software por você sob escopo e orçamento definidos. Desenvolvimento de software in-house significa contratar engenheiros como funcionários CLT da sua empresa, que são donos do código e reportam para a sua linha de gestão. A diferença não é só onde os engenheiros sentam; é o que você compromete financeira, organizacional, e operacionalmente.

Quais as desvantagens de desenvolvimento de software in-house?

Risco de hiring, overhead de gestão, compromissos de folha que não são desfeitos rápido, e o tempo do fundador rodando uma área de engenharia em vez de rodar o negócio. Para um fundador não-técnico pré-PMF, o custo de gestão sozinho costuma ser a maior linha de despesa escondida.

Quais as desvantagens de outsourcing de desenvolvimento de software?

Menos controle direto sobre prioridade no dia a dia, overhead de comunicação com um time que não mora na sua empresa, e o risco de longo prazo de herdar código que você não consegue manter se o parceiro virar pouco confiável. O parceiro certo mitiga os três. O parceiro errado amplifica os três.

Quando uma startup deve contratar engenheiros in-house?

Depois que o product-market fit é real, depois que o fundador consegue nomear problemas de engenharia (não só features de produto) na vaga, depois que existe pelo menos uma pessoa tecnicamente confiável no time que sabe avaliar candidatos de engenharia, e quando o runway cobre uma curva de ramp-up de seis meses antes de a contratação virar net-positive.

Quanto custa outsourcing de desenvolvimento de software?

Uma software house sênior baseada nos EUA cobra tipicamente US$ 20 mil a US$ 40 mil por mês para um time embedded de dois a três engenheiros mais um tech lead. Agências offshore vão de US$ 25 a US$ 50 por hora, colocando um time pequeno em US$ 40 mil a US$ 80 mil por trimestre, com qualidade mais variável e mais tempo de review do fundador. O artigo sobre quanto custa desenvolver um app cobre os seis drivers que mais movem o número.