Como contratar uma software house para um projeto com IA: as perguntas que fazemos questão de responder

Neste artigo9 partes

1. Antes de pedir proposta: o que você precisa ter claro
2. Quem está na reunião e quem vai gerenciar o projeto
3. Desenvolvimento interno ou terceirizado
4. O que acontece depois do Go Live
5. Dados, LGPD e propriedade do código
6. Como a IA é usada no projeto e quem revisa
7. Quando não vale a pena contratar, ou quando o fornecedor deve dizer não
8. Relações longas e o que elas mostram
9. Como comparar propostas com o mesmo critério
10. Perguntas frequentes

Antes de pedir proposta: o que você precisa ter claro

Antes de comparar fornecedores, a sua empresa precisa saber três coisas: qual problema quer resolver, quem é dono desse problema do lado de dentro e o que vai significar "funcionou". Sem isso, toda proposta parece boa, porque não há critério para dizer que alguma é ruim.

A tentação é começar pela lista de software houses, pedir três orçamentos e escolher pelo preço ou pela apresentação mais bonita. O resultado costuma ser um projeto que entrega exatamente o que foi pedido e não resolve o que a empresa precisava. A diferença entre as duas coisas raramente está no código. Está no entendimento.

Na Pocket Lab, o método começa por entender a fundo antes de construir. Isso não é frase de apresentação: é a razão pela qual a primeira reunião fala de processo, de gente e de dado, e não de tecnologia. Um bom fornecedor faz perguntas que você ainda não tinha feito. Se a primeira conversa já termina com preço e prazo, ninguém entendeu o problema ainda.

Um exercício útil antes de qualquer reunião é escrever, em uma página, o que acontece hoje, o que deveria acontecer, quem usa e quem decide. Se o projeto nasceu numa área de negócio e não na TI, como um sistema que substitui planilhas no financeiro ou nas operações, vale ler também como a área de negócio conduz um sistema interno sem criar sistema paralelo.

Escolher uma software house é comparar respostas, não apresentações. Pergunte o que ela responde por padrão.

Compartilhar esta frase

Com o problema claro, a escolha vira uma comparação de respostas. As seções abaixo trazem as perguntas que mais separam um fornecedor sólido de um fornecedor frágil. São as mesmas que fazemos questão de responder por escrito antes de qualquer assinatura.

Quem está na reunião e quem vai gerenciar o projeto

Pergunte quem, do lado do fornecedor, vai estar nas reuniões depois da assinatura. Se a resposta for alguém diferente de quem gerencia o projeto, existe uma camada de atendimento entre a sua empresa e quem decide. Essa camada custa caro.

Ela funciona como um telefone sem fio. Você explica o problema para o atendimento, o atendimento repassa para a gerência, a gerência traduz para o desenvolvimento. A cada passagem, um pedaço do contexto se perde. Quando a dúvida volta, volta pelo mesmo caminho, e o tempo do projeto vai embora em reuniões de alinhamento.

Na Pocket Lab, o atendimento é feito por quem gerencia o projeto. Quem ouve o problema é quem decide como resolver e quem responde quando algo sai do esperado. Não é a única forma de trabalhar, mas é a que mais reduz ruído.

Repare também em quem aparece na fase comercial e some depois. É comum a reunião de venda ter a presença de um sócio ou de um diretor técnico, e o projeto ser conduzido por outra pessoa, que não participou de nada. Não há problema em ter equipe, desde que você saiba desde o início quem vai estar do outro lado da mesa quando a primeira decisão difícil aparecer.

O que perguntar: quem vai participar das reuniões depois da assinatura? Essa pessoa tem autonomia para decidir sobre escopo e solução técnica? Se ela sair do projeto, quem assume?

Desenvolvimento interno ou terceirizado

Pergunte quem vai escrever o código. É comum uma empresa vender o projeto e repassar o desenvolvimento a terceiros, às vezes sem que o cliente saiba. Isso muda três coisas: a qualidade, porque ninguém de dentro acompanha o que foi feito; o dado, porque mais gente passa a ter acesso a ele; e a responsabilidade, porque quando algo quebra, cada parte aponta para a outra.

Terceirizar não é proibido, e existem parcerias técnicas bem conduzidas. O ponto é saber. Se uma parte do trabalho vai para outra empresa, você precisa saber qual parte, quem é essa empresa, que acesso ela terá e quem responde por ela.

A Pocket Lab escolheu um lado e o publica: "Sites, plataformas e integrações desenvolvidos internamente. O seu site não vira projeto terceirizado que ninguém acompanha." Quem desenvolve é quem mantém, e quem mantém conhece o que construiu.

Há um jeito simples de testar a resposta: peça para conversar, ainda na fase de proposta, com quem vai desenvolver. Um fornecedor que desenvolve internamente costuma topar sem dificuldade. Um fornecedor que repassa o projeto tende a desviar o assunto.

O que perguntar: quem escreve o código? Alguma parte do projeto vai para terceiros? Quem vai manter o sistema depois, e é a mesma equipe que construiu?

O que acontece depois do Go Live

Pergunte o que acontece no dia seguinte ao lançamento. Muitos projetos são vendidos como entrega única: o fornecedor publica, emite a nota e passa para o próximo cliente. Três meses depois, uma atualização quebra um formulário e ninguém sabe a quem ligar.

Um site ou sistema no ar muda o tempo todo. Recebe atualização, ganha uso, vira alvo de ataque, perde desempenho. Sem alguém responsável, o risco recai sobre quem comprou. Por isso tratamos hospedagem gerenciada e manutenção contínua com monitoramento como produto, e não como rodapé de contrato. ESPAS Brasil e Ace Trade são exemplos de clientes atendidos dessa forma, com site, hospedagem e manutenção sob a mesma responsabilidade.

A pergunta não é se o fornecedor oferece manutenção, porque quase todos oferecem. É o que essa manutenção cobre, quem responde e o que fica fora. O detalhamento está no guia sobre o que exigir de manutenção depois do lançamento.

Outro ponto que costuma ficar esquecido é a documentação. Um sistema bem documentado pode ser mantido por outra pessoa, inclusive por outro fornecedor, se um dia for preciso. Um sistema sem documentação prende a sua empresa a quem o construiu, e isso pesa mais do que qualquer cláusula de contrato. Pergunte o que será documentado, onde essa documentação fica e quem tem acesso a ela.

O que perguntar: quem hospeda e mantém o sistema depois da entrega? O que é monitorado? Como se abre um chamado? O que está fora do escopo da manutenção?

Dados, LGPD e propriedade do código

Pergunte, e peça por escrito, onde ficam os dados, quem tem acesso a eles, de quem é o código e o que acontece com tudo isso se o contrato terminar. São as perguntas que menos aparecem na reunião comercial e as que mais pesam no dia em que a relação acaba.

Onde ficam os dados. Em que ambiente o sistema roda, em nome de quem estão as contas de hospedagem e dos serviços contratados, e em que país os dados estão armazenados.

Quem acessa. Quais pessoas do fornecedor têm acesso a dados de produção, e com que finalidade. Se o sistema trata dado pessoal, como o fornecedor ajuda a sua empresa a cumprir a LGPD em formulários, consentimento e retenção.

De quem é o código. Se o código, o conteúdo e as configurações pertencem à sua empresa, e se você recebe acesso ao repositório ou só ao sistema publicado.

O que acontece no fim. Como é feita a entrega de código, dados e acessos se o contrato terminar, e quanto disso depende de boa vontade.

Onde a IA entra no caminho do dado. Se o fornecedor usa ferramentas de IA no desenvolvimento ou se o produto tem IA dentro, o dado da sua empresa pode passar por serviços de terceiros. Vale saber quais, com que regra e se há dado pessoal envolvido. A preferência por dados fictícios ou anonimizados em tudo que não precisa de dado real é um bom sinal de cuidado.

Nenhuma dessas respostas deveria ser "depois a gente vê". As respostas certas variam de projeto para projeto, e o contrato é o lugar de registrá-las. Para questões jurídicas específicas, a revisão do contrato por um advogado da sua confiança continua sendo o caminho.

Como a IA é usada no projeto e quem revisa

Pergunte onde a IA entra no projeto e quem revisa o que ela produz. Hoje, quase toda software house usa IA de alguma forma. A diferença não está em usar, e sim em declarar como usa e quem responde pelo resultado.

A regra que adotamos é pública: a IA tira o repetitivo do caminho, e arquitetura, decisão técnica e revisão continuam humanas. Na prática, isso significa que a IA acelera estrutura de código, testes de rotina, documentação e monitoramento, e que nada vai para produção sem que uma pessoa com nome revise. A divisão completa está em o que a IA faz e o que continua humano num projeto de software.

Se o projeto tem IA dentro do produto, como um assistente, uma análise automática ou uma integração com modelo de linguagem, a conversa ganha outras perguntas: quanto custa operar, para onde vai o dado que passa pelo modelo e o que acontece quando a IA erra. Um fornecedor sério responde a essas perguntas antes de você fazê-las.

O que perguntar: em que etapas vocês usam IA? Que dado da minha empresa passa por ferramentas de IA, e com que regra? Quem revisa o que vai para produção?

Quando não vale a pena contratar, ou quando o fornecedor deve dizer não

Um bom fornecedor diz quando o projeto não vai dar resultado. Essa é talvez a pergunta mais reveladora de todas: em que situação vocês recusam um projeto? Quem nunca recusou nada costuma aceitar tudo, inclusive o que não deveria.

Recusar trabalho que não vai dar resultado faz parte de como a Pocket Lab trabalha. Não por virtude abstrata, mas porque um projeto que fracassa custa caro para os dois lados. Os casos mais comuns em que a resposta certa é não, ou ainda não, são estes:

• O problema ainda está mal definido. Se ninguém consegue descrever o que deveria acontecer, construir agora só produz retrabalho. Primeiro vem o entendimento.
• Uma ferramenta pronta resolve. Se existe um produto de mercado que atende bem ao processo, desenvolver sob medida é gastar mais para ter o mesmo.
• Não há dono interno. Sistema sem alguém da sua empresa para decidir, testar e adotar tende a ficar pronto e não ser usado.
• Há IA onde não há revisor. Colocar IA num processo crítico sem ninguém para conferir o resultado transfere o risco para o cliente final.
• O problema é de organização, não de software. Às vezes, um ajuste de processo ou de responsabilidade resolve o que parecia pedir um sistema novo.

Se o fornecedor que você está avaliando faz perguntas sobre esses pontos, e às vezes sugere um caminho menor ou mais simples, é um bom sinal. É sinal de que ele está olhando para o seu resultado, e não só para o próprio contrato.

Relações longas e o que elas mostram

Relação longa com cliente é uma das poucas provas que não se fabricam numa apresentação. Ela mostra que o fornecedor continuou entregando depois do lançamento, atravessou mudanças de equipe e de prioridade do cliente e seguiu sendo útil.

A Pocket Lab atende a 360 Compliance desde 2018. Não é o único exemplo, mas é um bom retrato do tipo de relação que buscamos: contínua, com quem conhece o histórico do cliente e consegue sugerir o próximo passo sem precisar reaprender o contexto.

Relações assim também mostram algo que portfólio não mostra: como o fornecedor se comporta quando o projeto já não é novidade. O primeiro mês de um projeto costuma ter toda a atenção da equipe. O quarto ano é que revela se existe método, documentação e alguém que ainda se importa.

Ao avaliar uma software house, peça referências de clientes atendidos há mais tempo, não só dos projetos mais recentes. Pergunte o que mudou na relação ao longo dos anos e quem do fornecedor continua no atendimento. A resposta diz mais do que qualquer portfólio.

Como comparar propostas com o mesmo critério

Faça a todos os fornecedores as mesmas perguntas, por escrito, e compare as respostas lado a lado. Parece óbvio, mas a maioria das comparações acontece entre documentos com formatos, escopos e premissas diferentes, e aí o preço vira o único ponto comparável.

Três cuidados ajudam. Primeiro, peça que cada proposta traga um diagnóstico do problema, e não só uma lista de entregas: quem não entendeu o problema não tem como orçá-lo direito. O que uma proposta boa precisa mostrar está detalhado em o que exigir numa proposta de desenvolvimento de software. Segundo, peça que cada uma diga o que está fora do escopo. É ali que mora a maior parte das surpresas. Terceiro, compare o depois: manutenção, hospedagem, custo de operação e o que acontece se o contrato terminar. Se o projeto envolve IA, inclua as linhas de custo que costumam ficar fora da proposta.

Com as respostas na mesa, a decisão tende a ficar mais clara do que parecia. E, se ainda houver dúvida, vale uma segunda reunião com a pergunta mais difícil para cada fornecedor. O jeito como ele responde ao que não sabe também é critério.

Se a sua empresa está nessa etapa, conheça como trabalha a Software House da Pocket Lab e faça a ela as mesmas perguntas.

Perguntas frequentes

Como escolher uma software house?

Comparando como cada uma responde sobre quem gerencia, quem desenvolve, o que acontece depois do lançamento, a propriedade do código, o destino dos dados e o uso de IA.

Qual o risco do desenvolvimento terceirizado?

Perda de acompanhamento, de responsabilidade clara e de controle sobre os dados. A pergunta central é quem de fato escreve e mantém o código.

Uma software house deve recusar projeto?

Sim, quando o projeto não vai dar resultado ou existe solução mais simples. Isso é sinal de maturidade, não de falta de interesse.