Digite “melhores software houses do Brasil” e você recebe listas. Dez empresas, selos bonitos, cases de logo, uma nota de estrelas que ninguém sabe de onde saiu. O que esses listões nunca te dão são as perguntas que realmente separam um parceiro de médio prazo de um fornecedor que entrega telas e desaparece. Elas não dão porque essas perguntas são desconfortáveis — e desconforto não vende ranking.
Este texto é o oposto do listão. Não vou te indicar empresa nenhuma. Vou te dar o roteiro de perguntas-armadilha para fazer na reunião, o que uma boa resposta parece, e por que a distinção entre “parceiro” e “fornecedor” decide mais sobre o sucesso do seu produto do que qualquer selo. Contratar desenvolvimento é um casamento de médio prazo: escolher mal não custa só o contrato, custa tempo de mercado.
Parceiro vs. fornecedor: a diferença que ninguém coloca no contrato
Um fornecedor entrega exatamente o que você pediu. Parece bom, até você lembrar que você — founder ou gestor de PME — nem sempre sabe pedir a coisa certa. Você pede “um app com essas telas”; um fornecedor entrega as telas. Um parceiro pergunta por que essas telas, o que você quer provar com elas, e te avisa quando o que você pediu vai te prejudicar em produção.
A diferença raramente está escrita no contrato. Ela aparece no comportamento sob estresse. Quando o escopo muda, o fornecedor abre um aditivo e cobra; o parceiro discute o trade-off antes de você gastar. Quando algo quebra em produção, o fornecedor aponta que “estava fora do escopo”; o parceiro entra junto porque o seu resultado é a métrica dele também. Você não descobre isso lendo o site — descobre nas perguntas certas e na reação a elas.
Nenhum dos dois é errado por definição. Para uma fatia bem delimitada — uma integração, uma tela, um ajuste pontual — um fornecedor competente é exatamente o que você precisa. O problema é contratar um fornecedor esperando um parceiro, e só perceber a diferença no dia em que o produto cai e ninguém atende.
As perguntas-armadilha (e o que uma boa resposta parece)
Aqui está o roteiro que os listões omitem. Faça essas perguntas na reunião e anote as respostas — literalmente, porque você vai querer compará-las depois entre os candidatos.
1. De quem é o código no final? A resposta certa é “100% seu, incluindo versões intermediárias e acesso ao repositório desde o dia um”. Qualquer hesitação aqui é bandeira vermelha. Advogados de propriedade intelectual são diretos: sem cláusula explícita de cessão de direitos, o código pode não ser seu, e a empresa pode retê-lo como garantia de pagamento ou como forma de te manter refém da manutenção dela.
2. O que acontece se atrasar? Ninguém gosta dessa pergunta, e é justamente por isso que ela funciona. Uma boa resposta descreve como o atraso é comunicado, com que antecedência, e o que muda no combinado. Uma resposta ruim é “não costumamos atrasar” — todo mundo atrasa, a questão é como lidam quando acontece.
3. Qual o SLA de suporte depois do go-live? Peça números. Um padrão de mercado aceitável: bug crítico (sistema fora do ar) respondido em até 2 horas; bug grave (funcionalidade importante quebrada) corrigido em até 24 horas; bug moderado (com solução alternativa) em até 5 dias úteis. Sem SLA por escrito, “suporte” vira favor — e favor não tem prazo.
4. Quem mantém isso daqui a seis meses? A pergunta mais barata e mais reveladora de todas. Se a resposta é vaga (“a gente vê depois”), você está comprando um órfão. Manutenção, hospedagem e operação precisam ter dono definido antes de assinar.
5. Como vocês estimam e lidam com mudança de escopo? Escopo muda sempre. Você quer entender o processo: discovery honesto, critério de aceite por entrega, e um jeito combinado de tratar o que surgir. “A gente ajusta no meio do caminho” sem processo é o começo de um orçamento que triplica.
6. Posso ligar para dois clientes seus? Depoimento no site é marketing. Referência que atende o telefone é evidência. A CodeCortex resume três sinais objetivos de casa séria: entrega de documento de arquitetura antes do contrato, pelo menos três clientes dispostos a atender uma ligação de referência, e senioridade média de time acima de seis anos. Se faltar qualquer um dos três, o risco sobe.
Sinais verdes e sinais vermelhos
Depois de fazer as perguntas, alguns padrões emergem. Reuni os que mais importam numa tabela para você usar como checklist na hora de comparar candidatos.
| Área | Sinal verde | Sinal vermelho |
|---|---|---|
| Escopo | Discovery honesto com critério de aceite por entrega | ”Qualquer coisa em 7 dias” sem discovery |
| Código | Repositório sob seu controle desde o início | Acesso ao código só na entrega final |
| Ambientes | Staging antes de produção, sempre | Recusa ou omissão de staging |
| Suporte | SLA com prazos escritos | ”Suporte” sem prazo definido |
| Cobrança | Preço e prazo por entrega | Hora aberta sem escopo fechado |
| Operação | Modelo de manutenção definido no contrato | ”A gente vê depois do go-live” |
| Comunicação | Ponto de contato único e claro | WhatsApp eterno sem dono |
| Portfolio | Casos com operação real, não só layout | Só telas bonitas, nenhuma menção a produção |
Nenhum sinal isolado condena uma empresa. Mas três ou quatro vermelhos juntos dizem, com clareza, que você está diante de um fornecedor que se vende como parceiro.
Use a tabela ao vivo, na reunião, e observe o que acontece quando você pergunta sobre um item vermelho. A reação importa tanto quanto a resposta: um bom parceiro trata a pergunta difícil como legítima e responde com naturalidade; um fornecedor na defensiva desconversa, minimiza ou tenta te fazer sentir que você está sendo paranoico por perguntar. Você está avaliando não só o que a empresa faz, mas como ela se comporta quando é questionada — porque é exatamente assim que ela vai se comportar quando o projeto apertar.
Preço por entrega, não por hora
Um ponto que merece parágrafo próprio porque é onde mais gente se queima. Cobrança por hora sem escopo fechado transfere todo o risco de estimativa para você e, pior, recompensa a lentidão: quanto mais devagar, mais fatura. Preço e prazo por entrega, com critério de aceite, colocam o risco de estimar certo em quem tem competência para estimar — a software house.
Isso não significa que hora seja sempre errado. Em regime de staff augmentation, com o seu time no comando, hora faz total sentido. O problema é o híbrido pior dos mundos: hora aberta com escopo indefinido, onde nem você nem a empresa sabem onde o projeto termina. Orçamento transparente — com escopo, SLA, prazo, propriedade do código, hospedagem e modelo de cobrança explícitos — é a marca de quem trata você como parceiro.
Os riscos que só aparecem depois do deploy
A maioria das dores de software não nasce no desenvolvimento. Nasce depois, na operação, quando o fornecedor já emitiu a nota e sumiu. Vale mapear esses riscos antes de assinar, porque é aí que a diferença entre parceiro e fornecedor cobra o preço mais alto.
- Produto sem quem opere. Vira risco puro de publicar app em produção: cai e ninguém atende, porque manutenção não tinha dono.
- Infra que ninguém entende. Sem DevOps para PMEs — deploy, monitoramento, backup —, cada atualização vira uma aposta.
- Dado exposto. Se a conformidade com a LGPD ficou “para depois”, o depois chega em forma de multa.
- Custo de IA fora de controle. Produtos com IA embutida têm um custo de operação em produção que precisa estar na conta desde o discovery, não como surpresa na primeira fatura de API.
- Go-live sem rede. Sem testes antes do go-live, o primeiro cliente vira o QA — e ele não pediu esse emprego.
Uma boa pergunta de fechamento para qualquer candidato é: “Depois que vocês entregam, o que continua sendo responsabilidade de vocês?” A resposta desenha, melhor que qualquer selo, se você contratou um parceiro ou um fornecedor.
E se o meu projeto for pequeno?
Nem tudo precisa de uma software house completa. Se o que você quer é presença digital, um site institucional resolve — e não é web app. Contratar uma casa de engenharia para fazer um site é pagar caro por competência que você não vai usar. O inverso também é verdade: contratar quem só faz site para construir um produto com login, dados e integração é economizar no lugar errado.
O critério é sempre o mesmo: o tamanho do risco de produção decide o tamanho do parceiro. Projeto sem dado sensível, sem escala, sem operação contínua? Fornecedor pontual serve. Produto que vai cobrar cliente, guardar dado e crescer? Aí você precisa de alguém que ainda esteja por perto no sexto mês.
Como decidir sem se arrepender
Reduza a decisão a três ações concretas, que sozinhas cortam a maior parte do risco: ligue para pelo menos dois clientes de referência e pergunte se o prazo foi cumprido; exija escopo detalhado com critério de aceite por entrega antes de assinar qualquer coisa; e confirme em contrato que o código-fonte será 100% seu no final. Se qualquer uma das três esbarrar em resistência, você já tem sua resposta.
O melhor parceiro não é o que promete o mundo na primeira reunião. É o que te faz perguntas difíceis sobre o seu próprio negócio, escopa com honestidade mesmo quando isso reduz o contrato, e trata a operação depois do go-live como parte do trabalho, não como upsell. Se quiser esse tipo de conversa — a que começa entendendo o seu problema antes de cotar telas —, fale com um consultor da Pixelize e traga o desafio real; o caminho certo aparece no discovery, não no orçamento.
Perguntas frequentes
Qual a diferença entre fornecedor e parceiro de software?
Fornecedor entrega o que foi pedido e encerra. Parceiro questiona o pedido quando ele te prejudica, pensa na operação depois do go-live e trata o seu resultado como métrica dele. A diferença aparece menos no contrato e mais em como reagem quando algo dá errado.
De quem é o código que a software house desenvolve?
Deveria ser seu, mas só é se o contrato disser isso explicitamente — incluindo versões intermediárias e acesso ao repositório. Sem cláusula clara de cessão de direitos, a empresa pode reter o código como garantia de pagamento ou para te manter dependente da manutenção dela.
O que é um SLA aceitável para manutenção?
Um padrão de mercado: bug crítico com sistema fora do ar respondido em até 2 horas; bug grave em até 24 horas; bug moderado com solução alternativa em até 5 dias úteis. Sem SLA escrito, “suporte” vira favor, e favor não tem prazo.
Como saber se a software house não vai sumir depois do deploy?
Pergunte quem opera o produto depois do lançamento, sob qual acordo, e peça o modelo de manutenção por escrito. Exija acesso ao repositório desde o início e documentação de arquitetura. Contrato que entrega só “código” sem caminho de produção é sinal amarelo.
O que perguntar antes de assinar contrato?
O que acontece se atrasar, quem é seu ponto de contato diário, como lidam com mudança de escopo, quem mantém depois, e se o código é 100% seu no fim. Peça também referências de clientes reais dispostos a atender uma ligação — não só depoimentos no site.
Preço por hora ou por entrega?
Prefira preço e prazo por entrega, com critério de aceite. Cobrança por hora sem escopo fechado transfere todo o risco de estimativa para você e recompensa a lentidão. Por entrega, o risco de estimar certo fica com quem tem competência para estimar.