Os erros mais caros ao contratar um aplicativo para a empresa acontecem antes da primeira linha de código. São eles: contratar sem um objetivo de negócio claro, querer todas as funções na primeira versão, ignorar a integração com o sistema e o site que a empresa já usa, esquecer a publicação nas lojas e a manutenção depois do lançamento e não deixar no contrato quem fica com o código. Nenhum desses erros é técnico. Todos se resolvem com conversa e com contrato antes de assinar.
Abaixo, cada erro tem o motivo de sair caro e o que fazer no lugar.
Por que contratar sem um objetivo claro sai caro?
Um aplicativo pedido porque "o concorrente tem" ou porque "cliente gosta de app" não tem como ser avaliado. Se ninguém sabe o que ele deve mudar no negócio, ninguém consegue decidir quais telas importam, o que fica de fora e, depois do lançamento, se o investimento valeu.
Por que custa caro: sem um objetivo, o escopo vira uma lista de desejos, e cada reunião acrescenta uma função. Outro resultado comum é um app que repete o que o site já faz, e aí o cliente não tem motivo para instalar.
Como evitar: escreva em uma frase o problema que o app resolve. Por exemplo: "reduzir as ligações de clientes perguntando pelo status do pedido", "permitir que os técnicos de campo registrem atendimentos sem papel" ou "fazer quem já compra comprar de novo". Depois, defina como vai medir isso. Vale também perguntar se o aplicativo é mesmo o melhor caminho. Ele faz mais sentido quando o uso é frequente ou quando precisa de recursos do celular, como notificações, câmera, localização ou funcionamento sem internet. Se o uso é raro, um site bem feito ou um sistema web pode resolver.
Vale a pena colocar todas as funções na primeira versão?
Quase nunca. Cada função a mais aumenta o prazo, o custo, o trabalho de teste e a chance de erro. E só depois que as pessoas começam a usar o app você descobre o que elas realmente usam.
Por que custa caro: o lançamento atrasa, o orçamento acaba antes de chegar ao que importa, e funções que ninguém usa continuam pedindo manutenção para sempre.
Como evitar: separe o núcleo, que é o que atende o objetivo definido acima, do que pode ficar para depois. Lance uma primeira versão enxuta, acompanhe o uso e evolua em ciclos curtos. Uma pergunta ajuda a cortar: "se o app tivesse só três funções, quais seriam?"
O app precisa conversar com o sistema que a empresa já usa?
Na maioria dos casos, sim. Pedidos, estoque, cadastro de clientes, agendamentos e financeiro já ficam em algum lugar: um ERP, um sistema de gestão, a loja virtual ou o site. Um aplicativo isolado obriga alguém a digitar os mesmos dados duas vezes, e os números passam a não bater.
Por que custa caro: quando a integração aparece no meio do projeto, prazo e orçamento costumam mudar. O trabalho depende de o sistema atual oferecer uma forma de conexão (uma API), de ter documentação e, às vezes, de autorização do fornecedor desse sistema. Se nada disso existe, é preciso construir a ponte, e isso é um projeto à parte.
Como evitar: antes de pedir orçamento, liste os sistemas que a empresa usa, quem fornece cada um e quais dados o app vai ler ou gravar em cada um. Peça ao fornecedor que avalie as integrações já na proposta, e não depois de fechar o contrato.
O que acontece depois que o aplicativo fica pronto?
Muita gente acha que o projeto termina quando o app funciona no celular de teste. Ainda faltam duas etapas que costumam ficar de fora do orçamento: a publicação e a manutenção.
Publicação nas lojas da Apple e do Google
Para chegar ao público, o app precisa ser aprovado na App Store e no Google Play. Cada loja tem suas regras e seu processo de revisão. Elas pedem uma conta de desenvolvedor, uma política de privacidade, descrição e imagens. A revisão pode recusar o app e pedir ajustes, o que leva tempo. Um detalhe importante: as contas nas lojas devem ficar em nome da sua empresa, e não em nome do desenvolvedor.
Manutenção depois do lançamento
A Apple e o Google lançam versões novas dos seus sistemas todo ano, e as lojas costumam exigir que os apps se adaptem a elas. Os componentes usados no app ficam desatualizados, surgem falhas de segurança, e os usuários pedem melhorias. Sem manutenção, o app perde qualidade aos poucos e pode até sair da loja.
Por que custa caro: o lançamento atrasa porque ninguém planejou a publicação. Meses depois, o app apresenta um problema e não existe contrato para corrigir.
Como evitar: inclua a publicação no escopo. Pergunte o que a garantia depois do lançamento cobre e por quanto tempo, e como funciona a manutenção depois dela. Coloque esse custo no planejamento anual. Na hora de colocar propostas lado a lado, este guia ajuda: como comparar orçamento de site ou sistema sem errar.
Quem fica com o código do aplicativo?
Se o contrato não diz, a resposta pode ser "o fornecedor". Sem o código-fonte, a empresa não consegue trocar de fornecedor, pedir uma auditoria nem fazer qualquer mudança sem depender de quem desenvolveu.
Por que custa caro: numa troca de fornecedor, o app pode ter que ser refeito do zero, e o investimento se perde.
Como evitar: o contrato deve dizer com clareza:
- a quem pertence o código desenvolvido sob medida e em que momento ele passa a ser seu;
- que o código-fonte e a documentação serão entregues;
- quais componentes de terceiros o app usa e em que condições eles podem ser usados;
- que as contas nas lojas, os servidores e os domínios ficam em nome da empresa.
Vale pedir para o seu advogado ler essas cláusulas antes de assinar.
Que perguntas fazer ao fornecedor antes de assinar?
Leve esta lista para a reunião. As respostas mostram se o fornecedor pensou no seu negócio ou só no app.
- Que problema do meu negócio este app resolve, e como vamos medir o resultado?
- O que entra na primeira versão e o que fica para depois?
- Com quais sistemas o app vai se integrar, e isso já está no orçamento?
- O app será nativo ou híbrido, e por quê? (Se o assunto for novo para você, veja app nativo ou híbrido: qual escolher.)
- Quem cuida da publicação nas lojas, e em nome de quem ficam as contas?
- O que a garantia cobre, por quanto tempo, e como funciona a manutenção depois dela?
- Em que momento o código passa a ser meu, e como recebo o código-fonte?
- Como vou acompanhar o andamento: haverá entregas parciais e reuniões combinadas?
Respostas claras e por escrito são um bom sinal. Respostas vagas, ou "isso a gente vê depois", mostram exatamente onde o projeto pode sair mais caro.
Esse é o tipo de projeto que fazemos na OMS. O código desenvolvido sob medida passa a ser do cliente após a conclusão e a quitação do projeto. Depois do lançamento, há garantia de 30 dias para correções e planos de manutenção evolutiva. Para saber mais, veja como funciona o nosso desenvolvimento de aplicativos.
