A resposta curta
Para contratar uma software house, comece pelo problema da operação, faça a todas as candidatas as mesmas perguntas sobre método, time, uso de IA, propriedade do código e suporte, e compare as propostas pelo que cada uma inclui, exclui e documenta. Feche só com contrato que diga isso por escrito.
O portfólio mostra o que a empresa já fez. As respostas mostram como ela vai trabalhar no seu caso. Quem trabalha bem explica o próprio método com clareza, pergunta muito sobre a sua operação e põe por escrito o que fica de fora do escopo.
O que levar para a primeira reunião com a software house
Chegue com o problema, não com a solução. Você não precisa de escopo pronto, mas ajuda saber o que hoje dá trabalho, atrasa ou gera erro, quem usa a rotina, quais sistemas já existem e o que acontece se nada mudar nos próximos meses. Uma boa software house transforma isso em escopo; o artigo sobre como definir o escopo de um software mostra como esse trabalho costuma ser feito.
Se houver documentos, planilhas, relatórios ou telas do processo atual, leve. Eles mostram em minutos o que levaria uma reunião inteira para explicar. Leve também quem vai usar o sistema no dia a dia, ou pelo menos as dúvidas dessa pessoa: ela costuma enxergar problemas que a gestão não vê.
Desconfie de quem pula essa etapa e já chega com a tecnologia escolhida, o prazo fechado e o preço na primeira conversa. Sem entender a operação, qualquer número é chute.
Checklist de perguntas para a primeira reunião
Faça as mesmas perguntas a todas as empresas que estiver avaliando e anote as respostas lado a lado. Ao lado de cada pergunta, o que vale esperar ouvir.
- Como vocês entendem o problema antes de propor solução? Espere ouvir sobre conversa com quem opera, levantamento do que já existe, protótipo e validação de hipóteses antes do código.
- Com que frequência a gente vê software funcionando? A boa resposta é a cada ciclo curto, com demonstração para testar e aprovar, e não só no fim do projeto.
- Como vocês definem quando uma entrega está pronta? O critério de aceite deve ser combinado antes de cada item começar, para que "pronto" signifique a mesma coisa para os dois lados.
- O que acontece quando a prioridade muda no meio do caminho? Um método sério acomoda a mudança no planejamento do ciclo seguinte e mostra o impacto no prazo, sem esconder.
- Quem vai trabalhar no projeto e quem decide do lado de vocês? Saiba se produto, design, desenvolvimento, infraestrutura, segurança e suporte ficam com o mesmo time ou passam por fornecedores diferentes. Cada repasse é um ponto onde a informação se perde.
- Vocês já trabalharam com operações parecidas com a nossa? Peça exemplos concretos: o problema, para quem foi feito, o que foi entregue e o que deu trabalho.
- Como vocês usam inteligência artificial e quem revisa o que ela produz? Quase toda software house usa IA hoje. A pergunta é se há revisão humana antes da produção e em quais ferramentas os seus dados entram.
- Como são tratados controle de acesso, LGPD e segurança? Espere ouvir que isso entra desde o desenho, com verificação antes de cada publicação, e não como ajuste no fim.
- De quem fica o código e o que fica documentado? A propriedade do código e a transferência de conhecimento devem estar no contrato, com decisões, versões e riscos registrados.
- Quem atende depois que o sistema entra no ar? Saiba o canal, os tempos de atendimento e como o uso real vira a próxima melhoria antes de assinar.
Repare também no que a empresa pergunta de volta. Quem se interessa pela sua operação, por quem usa o sistema e pelo que já existe está tentando entender o problema. Quem fala só de tecnologia e de prazo ainda não sabe o que vai construir. Se quiser ver como respondemos a essas perguntas, o nosso método está descrito em como trabalhamos.
Sinais bons e sinais de alerta numa proposta de software
Depois das reuniões, chegam as propostas. Leia cada uma procurando os pontos abaixo, que dizem mais sobre o risco do projeto do que o valor final.
| Ponto da proposta | Sinal bom | Sinal de alerta |
|---|---|---|
| Escopo | Lista o que entra, o que fica de fora e as premissas assumidas | Descreve o sistema em frases genéricas, sem exclusões |
| Prazo | Vem de um estudo do escopo e mostra entregas intermediárias | Data fechada antes de qualquer conversa sobre a operação |
| Forma de entrega | Software funcionando a cada ciclo, com demonstração e aceite | Nada para ver ou testar até o fim do projeto |
| Time | Diz quem faz cada parte e quem é o ponto de contato | Não diz quem trabalha no projeto, ou terceiriza partes sem avisar |
| Propriedade e documentação | Código, acessos e documentação ficam com o cliente, por escrito | Silêncio sobre quem é dono do código e dos dados |
| Uso de IA | Explica onde a IA entra e garante revisão humana antes da produção | Promete que a IA resolve tudo sozinha e corta prazo por isso |
| Depois da entrega | Descreve suporte, canal de atendimento e evolução | Termina na publicação, sem falar de quem atende os chamados |
Uma proposta mais cara pode ser a mais barata se for a única que diz o que fica de fora. Escopo vago é a origem mais comum de discussão no meio do projeto. Para entender por que um prazo honesto depende do escopo, veja quanto tempo leva para desenvolver um sistema sob medida.
Como comparar propostas de software houses diferentes
Comparar só o valor total engana, porque cada empresa inclui coisas diferentes. Monte uma planilha simples com as mesmas linhas para todas: o que entra no escopo, o que fica de fora, como cada parte é entregue e aceita, quem compõe o time, de quem fica o código e o que acontece depois da publicação. Os buracos aparecem sozinhos.
Quando o problema ainda não está bem definido, faz sentido contratar primeiro um estudo curto, que produz escopo validado e prioridades, e só depois o desenvolvimento. É assim que começamos os projetos de desenvolvimento de software sob medida: um estudo que define escopo, prazo e investimento antes de qualquer compromisso maior. Com esse material em mãos, você também consegue pedir propostas comparáveis a outras empresas.
Se a dúvida for anterior, entre terceirizar ou contratar gente própria, a comparação entre software house ou equipe interna ajuda a decidir antes de abrir a concorrência.
O que deve estar no contrato com a software house
O contrato é onde as boas respostas da reunião viram obrigação. Antes de assinar, confira se ele trata destes pontos:
- Escopo, premissas e exclusões. O que será entregue, o que não será e de que informações ou acessos o projeto depende do lado do cliente.
- Forma de entrega e de aceite. Como cada entrega é demonstrada, quem aprova e em quanto tempo, e o que acontece se a entrega não atender ao critério combinado.
- Mudança de escopo. Como um pedido novo é avaliado, estimado e aprovado antes de entrar, para que nenhum dos lados seja surpreendido.
- Propriedade do código e acessos. A quem pertencem o código, os dados, os ambientes e as contas de serviço, e como tudo é entregue ao fim. O artigo sobre de quem é o código do software sob medida detalha o tema.
- Confidencialidade e tratamento de dados. Quem pode acessar os dados, para quê, e as responsabilidades de cada parte perante a LGPD quando o sistema trata dados pessoais.
- Suporte e sustentação. Canais de atendimento, tempos de resposta, o que é correção e o que é evolução, e como a evolução é orçada.
- Saída. Como funciona a transição se o contrato terminar: entrega de código, documentação e acessos, e um período de apoio para quem assumir.
Nada disso precisa estar em linguagem difícil. Precisa estar escrito. O que foi combinado só de boca costuma ser lembrado de forma diferente por cada lado seis meses depois.
Como saber se a software house usa IA com responsabilidade
A inteligência artificial acelera pesquisa, rascunho de código, testes e análise de logs, e é razoável que a empresa contratada use. O risco está em código gerado sem revisão chegando à produção, ou em dados do cliente entrando em ferramentas que ninguém autorizou.
Pergunte quem revisa o que a IA produz, em quais ferramentas os seus dados entram e se você vai saber em quais etapas ela foi usada. No nosso caso, nenhum código ou conteúdo gerado por IA vai para produção sem revisão de um profissional do time, que confere, corrige e assume a autoria, e o cliente sabe onde a IA entrou.
Como contratar uma software house sendo órgão público
As mesmas perguntas valem, mas o caminho é outro. Órgãos públicos contratam por meio de processo licitatório ou de contratação direta nas hipóteses que a lei permite, hoje regidos pela Lei 14.133/2021. Isso exige planejamento antes da compra: o problema, a solução pretendida e os critérios de aceite precisam estar descritos nos documentos da contratação, e o contrato tem fiscalização formal durante a execução.
Por isso a documentação pesa ainda mais. Ritos, responsáveis e registros definidos desde a abertura apoiam o fiscal do contrato, e acessibilidade, LGPD e registro de cada movimentação entram no escopo desde o começo. O passo a passo está no guia sobre como contratar software para órgão público. É com esse cuidado que desenvolvemos e mantemos o Ágil Cidadão, nosso sistema de atendimento ao cidadão.