Aplicativo que dá certo raramente é o mais bem programado — é o que resolve uma coisa só, bem, e continua funcionando depois do lançamento. Este texto reúne o que separa projeto que entra no ar de projeto que morre em desenvolvimento, do ponto de vista de quem contrata.
Uma plataforma ou as duas
A primeira decisão, e a que mais mexe no orçamento. Hoje ela importa menos do que há alguns anos, mas continua sendo escolha:
| Caminho | Quando faz sentido | Efeito no custo |
|---|---|---|
| Multiplataforma | A grande maioria dos casos: uma base de código gera Android e iOS | Próximo ao de uma plataforma só |
| Nativo | Uso intenso de câmera, sensor, mapa em tempo real ou desempenho gráfico | Perto do dobro |
| Só Android | Uso interno, com aparelhos que a empresa fornece | Menor de todos |
Para aplicativo de uso interno — equipe de campo, chão de fábrica, força de vendas — Android costuma ser a escolha óbvia: o parque de aparelhos robustos é maior e a reposição é mais barata. Se o destino for a fábrica, vale ver o guia de aplicativo para indústria, em que funcionar sem internet muda o projeto inteiro.
O que decide se o aplicativo será usado
- Abre rápido. Acima de alguns segundos até a primeira tela útil, parte das pessoas desiste — e no uso interno, volta para o papel.
- Funciona com conexão ruim. Não é caso extremo: elevador, subsolo, estrada e galpão são o dia a dia de muita gente.
- Poucos toques por tarefa. Menu profundo é o que faz o usuário abandonar.
- Não pede login toda hora. Sessão que expira sem motivo é a reclamação número um.
- Consome pouca bateria. Aplicativo que esquenta o aparelho é desinstalado, por melhor que seja.
Note que nenhum desses pontos é sobre visual. Aplicativo bonito e lento perde para aplicativo simples e rápido, sem exceção.
O que testar antes de aceitar a entrega
Você não precisa saber programar para reprovar uma entrega ruim. Cinco testes que qualquer pessoa faz em vinte minutos:
- Ligue o modo avião no meio de uma tarefa. O aplicativo deve avisar com clareza, e não perder o que já foi preenchido.
- Gire o aparelho. Tela que perde o conteúdo ao girar é sinal de descuido básico.
- Use com uma mão só. Se o botão principal fica fora do alcance do polegar, o desenho não considerou o uso real.
- Deixe aberto dez minutos. Aparelho esquentando indica consumo indevido de bateria.
- Volte depois de um dia. Se pedir login de novo sem motivo, a sessão está mal resolvida.
Esses cinco pegam a maior parte dos problemas que geram desinstalação — e todos são baratos de corrigir antes do lançamento, caros depois.
Segurança: o mínimo que precisa estar no contrato
- Comunicação criptografada entre o aplicativo e o servidor.
- Nada de dado sensível guardado no aparelho sem proteção — celular se perde e se empresta.
- Nenhuma chave ou senha embutida no código. Aplicativo publicado pode ser inspecionado por qualquer pessoa.
- Permissões mínimas. Pedir acesso a contatos e localização sem necessidade derruba a instalação e chama atenção da loja.
- Registro de acesso no servidor, para saber quem viu o quê.
Se o aplicativo trata dado de cliente, some a isso os requisitos da lei — vale ver o que a LGPD exige do sistema, porque exclusão de conta e exportação de dados precisam existir como funcionalidade, não como promessa.
Depois de publicar é que começa o custo
É a parte que quase nunca entra no orçamento inicial e a que mais gera atrito depois:
| Item | Por que é obrigatório |
|---|---|
| Atualização anual | Android e iOS mudam todo ano; aplicativo parado deixa de funcionar sozinho |
| Exigências novas das lojas | Política de privacidade, declaração de dados, versão mínima do sistema |
| Servidor e serviços | Notificação, armazenamento, envio de mensagem — custam por uso |
| Correção de falha | Erro em produção aparece em aparelho que ninguém tinha para testar |
| Contas de desenvolvedor | Custo anual na Apple, taxa única no Google |
Reserve de 10% a 20% do valor do projeto por ano para isso. Aplicativo não é entrega única: é um compromisso que se renova.
Quem vai usar muda tudo no projeto
Dois aplicativos com a mesma descrição podem ser projetos completamente diferentes, dependendo de quem abre:
| App para cliente final | App para equipe interna | |
|---|---|---|
| O que decide o sucesso | Instalar e voltar | Ser mais rápido que o papel |
| Interface | Precisa ser óbvia para quem nunca viu | Pode ser densa: o usuário usa todo dia |
| Distribuição | Lojas, com revisão a cada versão | Pode ser interna, sem loja |
| Aparelho | Qualquer um, inclusive antigo | Padronizado pela empresa |
| Maior risco | Ninguém instalar | A equipe voltar ao processo antigo |
Confundir os dois é o erro de escopo mais caro: aplicativo interno feito com preocupação de vitrine gasta em design que ninguém nota, e aplicativo de cliente feito com cara de sistema interno não passa da primeira tela.
Como acompanhar o desenvolvimento sem ser técnico
- Peça entrega a cada duas ou três semanas, e que seja aplicativo instalável, não relatório de progresso.
- Teste no seu aparelho real, não só no vídeo da demonstração.
- Teste em aparelho ruim e com internet ruim. É onde os problemas aparecem.
- Exija o código-fonte por escrito e as contas das lojas em nome da sua empresa.
- Peça a lista do que ficou de fora desta versão, por escrito, para não virar discussão no fim.
Quanto tempo o aplicativo dura
É a pergunta que ninguém faz e que define o custo total. Um aplicativo bem feito serve por anos, mas não sem manutenção: as duas plataformas lançam versão nova todo ano e passam a exigir adequação para continuar aceitando atualizações.
Na prática, um aplicativo abandonado costuma seguir funcionando por um tempo e então começa a apresentar problema em aparelho novo, até parar de ser aceito pela loja. Não é falha do desenvolvedor — é o ciclo normal da plataforma.
Por isso vale decidir no início se o aplicativo é um investimento contínuo ou um experimento com prazo. As duas respostas são legítimas; o que sai caro é achar que era a primeira e orçar como se fosse a segunda.
Os erros que mais matam projeto de aplicativo
- Querer tudo na primeira versão. Metade das funcionalidades pedidas antes de começar nunca é usada.
- Não definir quem decide. Cada divergência entre áreas trava o projeto por semanas.
- Esquecer o painel administrativo. Alguém vai precisar gerenciar conteúdo e usuários; sem painel, isso vira chamado.
- Ignorar o prazo de revisão das lojas. Pode levar dias, e sempre fica de fora do cronograma otimista.
- Achar que publicar é o fim. É onde começa o trabalho de fazer alguém instalar e voltar.
A Devuptime desenvolve aplicativos Android e iOS sob medida em Guarulhos, São Paulo, desde 2008, com código-fonte sempre entregue ao cliente. As faixas de investimento estão detalhadas em quanto custa desenvolver um aplicativo. Fale com a gente.
Perguntas frequentes
Preciso mesmo de um aplicativo? Um site que funcione bem no celular resolve a maioria dos casos, por um quinto do custo. Aplicativo se justifica com notificação, uso offline, acesso a sensor ou uso quase diário.
Quanto tempo leva? De 2 a 4 meses para uma primeira versão funcional, dependendo de quantas telas e integrações entram.
Dá para publicar em uma loja só? Dá, e para uso interno costuma ser a melhor decisão — inclusive dá para distribuir sem loja nenhuma, o que elimina a revisão.
E se eu precisar mudar depois de pronto? Aplicativo se atualiza como qualquer software. O que muda é o ciclo: cada versão passa pela revisão da loja antes de chegar ao usuário.
