# Empresa de programação: 7 critérios antes de contratar

> Founders que contratam empresa de programação avaliando stack cometem o erro mais caro do desenvolvimento de produto. Veja os 7 critérios que realmente predizem capacidade de entrega.

**URL:** https://northern.com.br/empresa-de-programacao/  
**Data:** 2026-05-31

---

Dois terços dos projetos de software são entregues com atraso, acima do orçamento ou simplesmente cancelados, segundo o [Relatório CHAOS do Standish Group](https://standishgroup.com), um dos estudos mais longos sobre projetos de tecnologia no mundo. Quando uma empresa de programação falha, raramente é por causa da tecnologia escolhida. É por processo ruim, escopo mal definido, e equipe sem senioridade real para resolver problemas de negócio.

Mas quando um founder senta para avaliar uma empresa de programação, o que ele pergunta? Qual stack vocês usam. Trabalham com React? E o backend, é Node ou Python?

Stack não salva projeto ruim. A empresa que responde essas perguntas com entusiasmo sem antes perguntar sobre seu negócio, seus usuários e seus critérios de sucesso já está mostrando como vai ser a relação.

A tese deste guia é direta: a maioria dos founders erra ao contratar uma empresa de programação porque avalia tecnologia em vez de capacidade de entrega. O que realmente prediz se seu produto vai sair, vai funcionar e vai ser seu de verdade são outros critérios, e eles aparecem muito antes da primeira linha de código.

[toc]

## Por que comparar stack tecnológica é o critério errado?

A lógica faz sentido na superfície: quanto mais moderna a tecnologia, melhor o produto. Essa correlação não existe na prática.

Node.js, Rails, Laravel, Django… cada uma dessas tecnologias tem centenas de produtos B2B em produção com milhões de usuários. Cada uma delas também tem produtos que foram ao ar, quebraram em três meses e custaram o dobro do estimado. A tecnologia não foi a variável decisiva em nenhum dos dois casos.

O que separa projetos que entregam de projetos que derrapam é o processo: como o escopo é definido, como as mudanças são gerenciadas, como a equipe comunica bloqueios, como o sucesso é medido. Isso acontece independente do framework escolhido.

Há um problema secundário em começar pela stack: você passa a ser avaliado como avaliador. A empresa de programação que percebe que você se impressiona com nomes tecnológicos vai usar isso como argumento de venda indefinidamente. Você vai terminar a reunião achando que está comprando inovação quando está comprando pitch.

A pergunta certa não é “quais tecnologias vocês dominam”. É “me mostra três projetos equivalentes ao meu que estão em produção hoje.” Aí a conversa fica honesta.

## Os 7 critérios que predizem capacidade de entrega em uma empresa de programação

Avaliação séria de uma empresa de programação começa com evidências, não com impressões. Os sete critérios abaixo são verificáveis antes de assinar qualquer coisa.

Critério
O que perguntar
Sinal positivo
Red flag

**Portfólio em produção**
“Me mostra 3 projetos ativos de clientes”
Acesso direto ao produto, cliente referenciável
Só cases em PDF ou “não podem ser divulgados”

**Processo de discovery**
“Como vocês iniciam um projeto?”
Sprint de discovery antes do desenvolvimento
Proposta enviada no mesmo dia do briefing

**Metodologia de entrega**
“Com que frequência o cliente vê o produto rodando?”
Demo quinzenal, backlog compartilhado
“Entregamos tudo no final do projeto”

**Composição da equipe**
“Quem especificamente vai trabalhar no meu projeto?”
Nomes e senioridade definidos antes de assinar
“Nossa equipe” sem especificação

**Propriedade intelectual**
“O código fica no meu repositório desde o início?”
Sim, com acesso imediato e contínuo
Entrega só no final ou “protegemos os fontes”

**Suporte pós-go-live**
“Qual o SLA para correção de bugs críticos?”
SLA (Service Level Agreement) contratual em horas
“A gente resolve, pode confiar”

**Transparência de escopo**
“Quais são os maiores riscos deste projeto?”
Riscos listados com mitigação proposta
Proposta sem nenhuma menção a riscos

O item mais subestimado nessa lista é o processo de discovery (etapa de entendimento profundo do problema antes de qualquer código). Uma empresa de programação que pula essa fase vai custar mais caro do que uma empresa mais cara que faz o discovery direito. Retrabalho em produto digital não aparece no orçamento inicial, mas ele aparece na fatura.

## Quais modelos de contratação existem e qual faz sentido para o seu momento?

Empresa de programação não é uma categoria única. Antes de entrar em proposta, você precisa entender qual modelo de engajamento resolve o seu problema.

Modelo
Como funciona
Ideal para
Limitação principal

**Projeto fechado**
Escopo e preço fixos definidos antes de começar
Requisitos estáveis e bem documentados
Mudanças de escopo viram negociação constante

**Time dedicado**
Equipe alocada exclusivamente para o produto
Produto em evolução contínua com backlog ativo
Exige que o contratante gerencie o backlog

**Fábrica de software**
Equipes compartilhadas entre vários clientes
Demandas pontuais e bem delimitadas
Atenção dividida, menor senioridade típica

Para fundadores construindo o produto core do negócio, a escolha geralmente fica entre projeto fechado (quando o escopo está muito bem definido) e time dedicado (quando o produto vai evoluir com o aprendizado do mercado). Fábrica de software funciona melhor para funcionalidades periféricas ou integrações pontuais.

Segundo análise da [Salesforce sobre modelos de contratação de tecnologia](https://www.salesforce.com/br/blog/2021/04/dev-interno-ou-outsourcing-de-ti.html), contratar desenvolvedores internos pode custar até três vezes o valor do salário quando se considera encargos, benefícios, equipamento e tempo de onboarding. Para produtos em fase de validação, time dedicado via empresa de programação frequentemente sai mais barato e mais rápido do que montar um time próprio do zero.

## O que não pode faltar no contrato com uma empresa de programação?

Contrato mal feito com empresa de programação é um dos problemas mais comuns e mais caros que fundadores enfrentam. Estes pontos precisam estar explícitos, não subentendidos:

**Propriedade intelectual desde o início.** Todo código produzido pertence ao contratante desde o primeiro commit. Isso inclui banco de dados, infraestrutura, documentação e qualquer biblioteca proprietária desenvolvida para o projeto. “Transferência após pagamento integral” é diferente de “propriedade desde o início”. A segunda protege você durante o projeto; a primeira, só no final.

**Critérios de aceite objetivos.** O que significa “entregue”? Funcionalidades específicas testadas e aprovadas, cobertura mínima de testes automatizados, performance definida em números, ausência de vulnerabilidades críticas conhecidas. Contrato que usa “satisfação do cliente” como único critério é convite para impasse.

**Acesso ao repositório durante o projeto.** Git (sistema de controle de versão de código) acessível ao contratante desde o início, não só na entrega final. Você deve conseguir fazer um fork e continuar com outra empresa de desenvolvimento em qualquer momento. Isso também incentiva a equipe a manter qualidade de código contínua.

**SLA de suporte pós-go-live.** Bugs críticos resolvidos em quanto tempo? Bugs de média severidade? Sem prazo contratual, você vai descobrir na pior hora que “a gente resolve rapidinho” não é compromisso.

**Processo de offboarding técnico.** Se a relação terminar, como acontece a transferência completa: documentação, credenciais, repositório, infraestrutura? Empresa séria já tem esse processo documentado antes que você precise.

## Cinco sinais de alerta para identificar antes de assinar com uma empresa de programação

Esses padrões indicam risco. Aparecem com frequência suficiente para merecer atenção antes de você comprometer orçamento.

**1. A proposta chega antes das perguntas.** Se a empresa de programação manda proposta detalhada em menos de 24 horas sem ter feito nenhuma reunião de alinhamento, ela não analisou seu problema. Ela usou um template. Proposta séria leva tempo porque requer entendimento real do negócio.

**2. A equipe que vai executar não aparece na conversa de venda.** O comercial fecha, o técnico sênior aparece na apresentação, e depois você descobre que a equipe real é diferente. Peça desde a primeira reunião para saber quem especificamente vai trabalhar no seu produto.

**3. Nenhuma menção a riscos ou incertezas.** Projeto de software tem imprevistos. Empresa que apresenta só o cenário ideal não está sendo honesta, ou não tem experiência suficiente para saber o que pode dar errado. Ambos são problema.

**4. Resistência ao acesso ao repositório.** “Protegemos o código dos nossos clientes de acessos externos” é argumento válido em contextos específicos. Resistência ao fato de você ter acesso ao seu próprio código no repositório desde o início do projeto não é.

**5. Contrato com cláusulas vagas sobre entrega e propriedade.** Leia o contrato antes de assinar. Não delegue essa leitura. As cláusulas sobre propriedade intelectual e critérios de aceite são as mais importantes e as mais frequentemente escritas para proteger o fornecedor, não o contratante.

### Avaliando contratar uma empresa de programação para o seu produto?

A Northern desenvolve produtos digitais de ponta a ponta: do discovery ao go-live, com time dedicado, propriedade intelectual transferida desde o início e metodologia de entrega transparente. Se você está avaliando parceiros para construir ou evoluir seu produto digital, vale uma conversa antes de decidir.

  [Falar com a Northern](https://lp.northern.com.br/contato)

## Perguntas frequentes sobre empresa de programação

    

      O que é uma software house e qual a diferença para empresa de programação?

      

    

Software house é o termo em inglês para empresa de programação. Na prática, são sinônimos: uma empresa especializada em desenvolver software sob encomenda para terceiros. A diferença percebida no mercado é de posicionamento: empresas que se apresentam como software house tendem a enfatizar a capacidade técnica; empresas de programação ou desenvolvimento tendem a destacar o processo de entrega. Para o founder, o critério de avaliação é o mesmo.

    

      Quando faz sentido contratar empresa de programação em vez de montar time interno?

      

    

Para produtos em fase de validação ou MVP (Minimum Viable Product), contratar uma empresa de programação é quase sempre mais eficiente do que montar time: você acessa uma equipe completa sem o custo de recrutamento, onboarding e encargos de uma contratação direta. Para produtos em escala com demanda contínua e previsível, montar um time interno começa a fazer sentido econômico. A decisão muda com o estágio do produto.

    

      Quanto custa contratar uma empresa de programação para desenvolver um produto digital?

      

    

Os valores variam conforme o escopo e o modelo. Um MVP bem definido pode custar entre R$ 40.000 e R$ 150.000. Um produto de médio porte fica entre R$ 150.000 e R$ 500.000. No modelo de time dedicado, o custo mensal por profissional fica entre R$ 8.000 e R$ 25.000 dependendo da senioridade. Proposta com valor muito abaixo da faixa de mercado merece investigação antes de ser aceita.

    

      O que verificar no portfólio de uma empresa de programação antes de contratar?

      

    

Portfólio relevante significa produtos em produção, com usuários reais, desenvolvidos nos últimos dois anos. Peça acesso direto ao produto e, se possível, contato com o cliente para referência. Cases em PDF apresentados em deck de vendas têm valor limitado. O que você quer ver é o produto funcionando e o cliente satisfeito o suficiente para uma conversa de cinco minutos.

    

      Qual metodologia de desenvolvimento devo exigir da empresa contratada?

      

    

Metodologia ágil é o padrão de mercado para desenvolvimento de produto digital, mas o nome sozinho não diz nada. O que importa é a prática: sprint (ciclo de desenvolvimento) com duração definida, backlog acessível ao contratante, demo do produto funcionando ao final de cada sprint, e processo claro para mudanças de escopo. Exija que esses processos estejam descritos na proposta, não apenas prometidos verbalmente.

    

      Como funciona o modelo de time dedicado numa empresa de programação?

      

    

No modelo de time dedicado, a empresa de programação aloca uma equipe fixamente para o seu produto, normalmente composta por desenvolvedor(es), designer e tech lead. Essa equipe opera como extensão do time do contratante, participando de reuniões, acessando o backlog e priorizando com base no que o negócio aprende. É o modelo mais flexível para produtos em evolução ativa, mas exige que o contratante saiba gerir prioridades e comunicar o contexto de negócio.

    

      Quem fica com a propriedade intelectual do produto desenvolvido?

      

    

O código pertence ao contratante. Esse é o padrão de mercado e deve estar explícito em contrato. Desconfie de empresas que apresentam modelos onde a propriedade intelectual é transferida apenas depois do pagamento total, ou onde parte dos componentes permanece como propriedade da empresa de programação. Em um contrato bem feito, você tem acesso ao repositório desde o primeiro dia de desenvolvimento.

    

      Qual a diferença entre projeto fechado e time dedicado para desenvolvimento de produto digital?

      

    

Projeto fechado tem escopo e preço definidos antes de começar. Funciona bem quando os requisitos são estáveis e documentados, porque o risco de retrabalho cai sobre a empresa. Time dedicado tem custo mensal com escopo flexível, funcionando melhor para produtos que vão evoluir com aprendizado do mercado. Para um MVP com requisitos definidos, projeto fechado pode ser adequado; para produto em iteração contínua, time dedicado costuma ser mais eficiente.

    

      Como garantir que a empresa de programação entregue o que prometeu?

      

    

Acordar critérios de aceite antes de assinar o contrato é o passo mais importante. Isso significa definir: quais funcionalidades são obrigatórias para a entrega, o que é cobertura mínima de testes, quais são os requisitos de performance e segurança. Com critérios objetivos, “entregue” tem definição clara. Sem eles, você vai depender de boa vontade mútua, o que não escala ao longo de um projeto de seis meses.

    

      Quais sinais indicam que devo trocar de empresa de programação?

      

    

Os sinais mais claros são: atrasos recorrentes sem comunicação proativa, backlog gerenciado de forma opaca, equipe que muda sem aviso, bugs críticos sem SLA respeitado, e resistência para transferir o repositório quando solicitado. Se você perceber mais de dois desses padrões simultaneamente, a troca é recomendada. O momento ideal para trocar é entre sprints, com repositório e documentação atualizados nas suas mãos antes de notificar o fornecedor.

## Conclusão

Contratar uma empresa de programação certa não é um exercício técnico. É uma decisão de negócio.

O founder que entra na avaliação perguntando sobre stack vai receber de volta uma conversa sobre stack, e vai assinar com a empresa que fez a melhor apresentação de tecnologia. O founder que entra perguntando sobre portfólio em produção, processo de discovery, composição real da equipe, propriedade intelectual e critérios de aceite vai ter uma conversa diferente. Vai descobrir rapidamente quem tem processo e quem tem pitch.

A tecnologia certa é aquela que uma equipe competente consegue entregar, testar e manter. Isso não depende de linguagem de programação. Depende de capacidade de execução, e você tem todas as ferramentas para avaliar isso antes de assinar qualquer coisa. Use-as antes de assinar, não depois de se arrepender.