Os erros mais caros de quem contrata o primeiro aplicativo (e como evitar cada um)
Gabriela Dionelli · · 7 min de leitura
Você decidiu tirar a ideia do papel. Pesquisou, pediu orçamentos, talvez já tenha até uma proposta na mesa. E aí bate a dúvida: como saber se você está prestes a tomar uma decisão boa ou a queimar suas economias em um projeto que nunca vai ao ar?
Respira. Vamos por partes. Eu trabalho do outro lado dessa mesa e vejo os mesmos erros se repetirem em quase todo primeiro projeto. A boa notícia: nenhum deles tem a ver com você não ser técnico. Todos têm a ver com decisões que você consegue tomar melhor sabendo o que observar. Este artigo é a lista dos erros que mais custam dinheiro, com o que fazer no lugar.
Erro 1: contratar o app inteiro de uma vez
É o erro mais caro de todos, e o mais comum. Você imagina o produto completo, com login social, chat, notificações, painel administrativo, sistema de pontos, e pede orçamento disso tudo. O número assusta, você negocia, fecha, e seis meses depois tem um produto enorme que nenhum usuário real testou.
O problema não é o tamanho do investimento. É a ordem. Quando você constrói tudo antes de qualquer usuário usar, cada funcionalidade é uma aposta. E apostas erradas em software não se devolvem: o dinheiro do chat que ninguém abriu já foi.
O que fazer no lugar: contrate a primeira versão com a menor lista de funcionalidades que resolve o problema central. No Revo, nosso próprio aplicativo de eventos, a primeira versão não tinha metade do que tem hoje. Foi o comportamento de usuários reais que decidiu o que construir depois. Hoje são mais de 40 mil usuários, e boa parte das funcionalidades que imaginávamos no início nunca precisou existir.
Erro 2: escolher pelo orçamento mais barato
Você recebe três propostas: R$ 25 mil, R$ 60 mil e R$ 110 mil para o "mesmo" projeto. A tentação de fechar a mais barata é enorme, especialmente quando o dinheiro é seu.
Só que orçamentos muito diferentes quase nunca descrevem o mesmo projeto. O barato geralmente esconde uma destas três coisas: um escopo que não inclui o que você acha que inclui, uma equipe júnior aprendendo no seu projeto, ou uma empresa que fecha qualquer valor para ganhar o cliente e renegocia no meio do caminho.
O padrão que mais vejo: o projeto de R$ 25 mil trava aos 70% de conclusão, o cliente já pagou quase tudo, e a escolha vira pagar "só mais um pouco" repetidas vezes ou abandonar o investimento. No fim, sai mais caro que a proposta do meio, e com um ano de atraso.
O que fazer no lugar: compare escopo, não preço. Peça para cada fornecedor listar exatamente o que está incluído: quantas telas, quais integrações, publicação nas lojas, quantos meses de correção de bugs após a entrega. Quando os escopos ficam comparáveis, a diferença de preço passa a fazer sentido, e aí sim você decide.
Erro 3: fechar contrato sem definir quem é dono do código
Parece detalhe jurídico, mas é um dos erros que mais aprisionam clientes de primeira viagem. Se o contrato não diz que o código-fonte é seu, na prática ele pode ficar com quem desenvolveu. Resultado: se a relação azedar, você não consegue levar o projeto para outra equipe. Fica refém.
O que fazer no lugar: antes de assinar, confirme três pontos no contrato:
- O código-fonte e o repositório pertencem a você (ou à sua empresa) após o pagamento.
- As contas de infraestrutura (servidores, banco de dados, lojas de aplicativos) ficam no seu nome, não no do fornecedor.
- Existe previsão de entrega de documentação e acesso caso o contrato termine, por qualquer motivo.
Fornecedor sério aceita esses três pontos sem drama. Resistência aqui é sinal de alerta.
Erro 4: pular a etapa de design e ir direto para o código
"Design a gente vê depois, o importante é funcionar." Essa frase custa caro por um motivo de comportamento humano, não de estética: usuário não lê manual, não dá segunda chance e abandona qualquer tela que exija esforço para entender. A maioria das desinstalações acontece nos primeiros minutos de uso, antes de o app ter chance de mostrar valor.
Quando o design é improvisado durante o desenvolvimento, cada ajuste vira retrabalho de programação. Mudar um fluxo de cadastro no protótipo custa horas. Mudar depois de programado custa semanas.
O que fazer no lugar: exija um protótipo navegável antes de qualquer linha de código. É uma simulação clicável das telas, feita em ferramenta de design, que você testa no celular como se fosse o app real. Custa uma fração do desenvolvimento e é o momento certo de errar: mudar ali é barato. E tem um bônus: você consegue mostrar o protótipo para dez pessoas do seu público essa semana e observar onde elas travam. Isso você consegue validar sem gastar quase nada.
Erro 5: não perguntar o que acontece depois do lançamento
Todo orçamento fala do desenvolvimento. Quase nenhum cliente de primeira viagem pergunta sobre o depois, e é aí que mora um custo invisível: aplicativo publicado precisa de manutenção. Sistemas operacionais atualizam, bibliotecas ficam obsoletas, as lojas mudam exigências, bugs aparecem com uso real.
Quem não planeja isso descobre da pior forma: o app para de funcionar em celulares novos, o desenvolvedor original sumiu ou cobra valores de emergência, e o produto que custou dezenas de milhares de reais vai morrendo aos poucos.
O que fazer no lugar: pergunte na proposta quanto custa a manutenção mensal e o que ela cobre. Uma referência realista no mercado brasileiro: entre R$ 1.500 e R$ 5 mil por mês para apps de pequeno e médio porte, variando com a complexidade e o volume de usuários. Se a resposta for "depois a gente vê", insista até virar número.
Erro 6: medir progresso por promessa, não por entrega
Projeto de software tem um risco silencioso: durante meses, tudo "está andando bem" nas mensagens, e você não tem como verificar. Quando a primeira entrega real chega, atrasada e diferente do combinado, você já pagou boa parte do valor.
O que fazer no lugar: estruture o pagamento por marcos de entrega, não por tempo. Cada parcela liberada contra algo que você consegue ver e testar: protótipo aprovado, primeira versão navegável, versão de testes no seu celular, publicação nas lojas. E peça acesso a uma versão de testes desde cedo. Acompanhar o app crescendo no seu próprio aparelho, a cada duas ou três semanas, transforma você de refém em participante do projeto.
Como a gente trabalha para você não cair nesses erros
Na OCA Software House, esses seis pontos não são recomendações da porta para fora, são o nosso processo. Todo projeto começa com escopo enxuto e protótipo navegável, o contrato deixa o código no nome do cliente, o pagamento é por marco de entrega e a manutenção entra na conversa desde a primeira proposta. A gente opera o próprio produto, o Revo, com mais de 40 mil usuários e 300 eventos por mês, então cada recomendação vem de algo que mantemos em produção, não de teoria.
E somos honestos sobre escopo: com frequência, a nossa primeira contribuição é dizer o que NÃO construir agora. Seu primeiro produto não precisa ser perfeito. Precisa existir, chegar em usuários reais e te dar informação para a versão seguinte.
Seu próximo passo essa semana
Antes de assinar qualquer contrato, faça este exercício, que custa R$ 0: escreva em uma página qual problema o app resolve, para quem, e quais são as três funcionalidades mínimas para resolver esse problema. Todo o resto vai para uma lista chamada "versão 2". Esse documento vale mais que qualquer reunião de vendas: ele te protege de escopo inflado e torna os orçamentos comparáveis.
E se quiser conversar com quem constrói e opera aplicativos todos os dias, a conversa começa sem compromisso:
