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.