Antes de pedir orçamento
Contratar uma software house é entregar a alguém a construção de uma parte do seu negócio que você provavelmente não consegue avaliar linha por linha. Você não vai ler o código, mas vai conviver com ele: com a lentidão, com o erro que volta toda semana, com a dificuldade de mudar uma tela simples. Por isso a escolha precisa ir além do preço e da boa impressão na primeira reunião.
Antes de falar com fornecedores, escreva em poucas linhas o problema que o projeto resolve, quem vai usar, o que precisa estar pronto na primeira versão e se existe uma data que não pode mudar, como um lançamento ou uma temporada de vendas. Esse resumo ajuda a comparar respostas e a perceber quem está prestando atenção no seu caso e quem está repetindo um roteiro.
Portfólio: peça o que está no ar
Imagem bonita no Behance ou no Instagram não prova que o sistema funciona. Peça links de projetos publicados: o site que carrega, o app que dá para instalar, a loja que vende de verdade. Abra no celular, navegue, preencha o formulário e veja se a página continua rápida fora do Wi-Fi.
Pergunte também qual foi o papel da empresa em cada projeto. Ela fez tudo ou só o design? Pegou um sistema pela metade e terminou? Ainda cuida dele hoje? Uma software house séria responde isso sem rodeio e, quando existe contrato de confidencialidade, explica o que pode mostrar e o que não pode.
Se o seu projeto tem uma exigência específica, como cobrança recorrente, integração com ERP ou um recurso de inteligência artificial, pergunte se a empresa já construiu algo parecido e peça para ver funcionando. Experiência com o tipo de problema vale mais do que experiência com a tecnologia da moda.
Como é o processo, do diagnóstico à entrega
Pergunte o que acontece entre o "fechado" e o lançamento. A resposta deveria ter etapas claras: entender o negócio, definir o escopo, desenhar as telas, desenvolver, testar e publicar. Quando a empresa pula direto do orçamento para a programação, as dúvidas que deveriam aparecer no diagnóstico aparecem no meio do projeto, quando corrigir custa mais caro.
Repare também no ritmo de entregas. Projetos divididos em etapas curtas, com versões de teste que você abre no próprio celular ou navegador, permitem corrigir o rumo cedo. O formato contrário, meses de silêncio e uma grande entrega no fim, é onde nascem as piores surpresas.
- Qual é a primeira etapa e o que eu recebo quando ela termina?
- Vou ver um protótipo das telas antes do desenvolvimento começar?
- De quanto em quanto tempo recebo uma versão para testar?
- Quem testa o sistema e em quais aparelhos?
- O que acontece se eu quiser mudar algo no meio do caminho?
Quem faz o trabalho e como vocês vão conversar
Nem sempre quem vende é quem constrói. Algumas empresas fecham o contrato e repassam o desenvolvimento para freelancers ou para outra empresa, e o cliente só descobre quando a qualidade cai ou quando ninguém sabe responder uma pergunta técnica. Repassar parte do trabalho não é proibido, mas precisa estar claro desde o começo. Pergunte quem vai trabalhar no projeto, se é equipe própria e se você vai conseguir falar com quem programa quando precisar.
Combine também como será a comunicação: por qual canal, com que frequência chegam as atualizações e quem é a pessoa de referência do seu lado e do lado deles. Uma conversa curta por semana com o que foi feito, o que vem a seguir e o que está travado resolve mais do que dezenas de mensagens soltas no WhatsApp. E observe como a empresa se comunica já na fase de orçamento. Se ela demora dias para responder agora, dificilmente vai acelerar depois que o contrato estiver assinado.
Código, domínio e acessos: de quem é cada coisa
Essa é a pergunta que muita gente esquece e que mais dói depois. O código-fonte é seu? O domínio está registrado no nome da sua empresa? As contas de hospedagem, banco de dados, App Store, Google Play e gateway de pagamento ficam no seu CNPJ ou no da software house?
O cenário a evitar é aquele em que tudo está na conta do fornecedor. Se a relação acabar, você fica sem acesso ao próprio produto ou precisa negociar para recebê-lo de volta. O ideal é que o código fique num repositório ao qual você tenha acesso, que as contas principais estejam em seu nome e que exista documentação suficiente para outro time continuar o trabalho.
Vale perguntar quais tecnologias serão usadas e por quê. Uma stack consolidada e bem documentada facilita contratar outra pessoa no futuro. Uma ferramenta proprietária que só aquela empresa sabe operar prende você a ela.
Contrato e escopo por escrito
Uma boa proposta descreve o que será entregue com detalhe suficiente para não haver discussão depois: telas, funções, perfis de usuário, integrações, o que fica fora do escopo, prazo de cada etapa, valor e forma de pagamento. Frases como "sistema completo de gestão" ou "app igual ao do concorrente" não servem como escopo, porque cada lado vai imaginar uma coisa diferente.
Leia com atenção o que acontece quando surge uma mudança. Ela vai surgir, porque o projeto ensina coisas que ninguém sabia no começo. O contrato precisa dizer como as mudanças são avaliadas, orçadas e aprovadas antes de entrar no cronograma. Confira também a garantia de correção de erros depois da entrega, a confidencialidade, o tratamento de dados pessoais conforme a LGPD e as condições para encerrar a parceria.
O que acontece depois do lançamento
Lançar é o começo do uso real, e é com uso real que aparecem os ajustes. Uma tela que quebra em um modelo específico de celular, um fluxo que os clientes não entendem, uma integração que muda de versão sem aviso. Pergunte quem resolve isso, em quanto tempo e como é cobrado.
Pergunte se existe plano de manutenção, o que ele cobre (correções, atualizações de segurança, pequenas melhorias, monitoramento) e como funciona quando você quiser uma função nova. A empresa que entrega e some deixa o cliente procurando outro fornecedor para mexer num código que não conhece, e esse recomeço costuma custar caro.
Sinais de alerta antes de assinar
Alguns comportamentos aparecem antes mesmo do contrato e dizem muito sobre como o projeto vai ser:
Desconfie também do excesso de jargão técnico usado para impressionar. Quem domina o assunto consegue explicar em português simples por que uma escolha faz sentido para o seu caso.
- Orçamento enviado sem nenhuma pergunta sobre o seu negócio, o público ou as regras do sistema.
- Prazo curto demais para o tamanho do escopo, prometido antes de entender o projeto.
- Resposta "a gente faz tudo" para qualquer pedido, sem apontar riscos nem sugerir o que pode ficar para depois.
- Recusa em mostrar projetos no ar ou em dizer quem vai desenvolver.
- Código, domínio e contas que ficam no nome da empresa contratada.
- Pagamento integral adiantado, sem etapas ligadas a entregas.
- Proposta sem nenhuma linha sobre o que está fora do escopo.
Perguntas para levar na reunião
Se quiser um roteiro, leve estas perguntas para cada fornecedor e compare as respostas lado a lado. Mais do que o conteúdo, preste atenção em quem responde com clareza e em quem desconversa.
Na BG Coding, o orçamento só sai depois de entendermos o projeto, e a proposta chega com escopo, prazo e valor definidos, dividida em etapas que você acompanha. O código e os acessos ficam com o cliente. Se você está comparando fornecedores, pode usar essa mesma lista com a gente.
- Posso ver projetos parecidos com o meu funcionando?
- Quais são as etapas e o que eu recebo em cada uma?
- Quem vai trabalhar no projeto e com quem eu falo no dia a dia?
- De quanto em quanto tempo vou testar uma versão nova?
- O código, o domínio e as contas ficam no meu nome?
- Como são tratadas as mudanças de escopo?
- O que está incluído depois do lançamento?