Desenvolvimento de aplicativos: guia completo para empresas

Toda semana chega a mesma pergunta ao nosso time: 'quanto custa fazer um aplicativo?'. A pergunta parece simples, mas ela esconde outras cinco: qual problema o app resolve, quem vai usar, o que precisa estar nas lojas, quais sistemas precisam conversar com ele e quanto a empresa consegue sustentar de manutenção. Este guia responde a todas elas em ordem, com critério prático e sem vender complexidade desnecessária.

O conteúdo é longo de propósito. Ele foi escrito para ser lido antes de assinar uma proposta de desenvolvimento, seja com a Appmart.ai, seja com qualquer outro fornecedor. Se você já sabe o que quer, use o sumário para pular direto para custos, prazos ou publicação nas lojas.

Resposta rápida: como decidir a tecnologia do seu app

Se você precisa apenas de presença no celular, conteúdo, catálogo, área logada simples e velocidade de entrega, um PWA resolve. Se precisa estar na App Store e no Google Play, com ícone próprio, push notifications e distribuição por busca nas lojas, o WebView entrega isso reaproveitando o que já existe na web. Se o produto depende de câmera avançada, sensores, bluetooth, processamento offline pesado, integrações nativas com o sistema operacional ou performance gráfica, o caminho é nativo.

Por que o celular virou o campo de disputa

O acesso à internet no Brasil é majoritariamente móvel. As pesquisas oficiais que acompanham conectividade, PNAD Contínua (IBGE) e TIC Domicílios (Cetic.br/CGI.br): mostram há anos o telefone celular como o dispositivo mais utilizado para acessar a rede, à frente do computador, com penetração crescente em todas as classes e regiões. Os painéis públicos da Anatel, por sua vez, acompanham a evolução dos acessos móveis e de banda larga fixa no país.

A consequência prática para uma empresa é direta: a decisão de compra acontece em uma tela pequena, muitas vezes com conexão instável, entre notificações concorrentes. Quem depende exclusivamente de redes sociais e marketplaces para chegar a esse consumidor não controla o alcance, não controla o custo por contato e não é dono da base. Um aplicativo próprio muda essa equação porque coloca a marca dentro do dispositivo, com canal direto e dados próprios.

As quatro arquiteturas possíveis e o que cada uma custa de verdade

1. PWA (Progressive Web App)

Um PWA é um site que se comporta como aplicativo: instala na tela inicial, abre em tela cheia, guarda recursos em cache para funcionar com conexão ruim e pode receber notificações push na maior parte das plataformas. A documentação do web.dev, mantida pelo time do Chrome, define os requisitos técnicos, manifest, service worker, HTTPS, e o Lighthouse audita se o site cumpre esses critérios.

O grande atrativo é o custo de distribuição: não existe fila de revisão, não existe taxa de conta de desenvolvedor, e uma correção publicada às 14h está disponível para todo mundo às 14h01. A limitação é o acesso a recursos profundos do aparelho, que varia por sistema operacional, e a ausência da vitrine das lojas.

2. WebView (casca nativa com conteúdo web)

Um app WebView é um aplicativo nativo de verdade, publicado na App Store e no Google Play, cuja interface principal é uma superfície web renderizada por componentes oficiais das plataformas (WKWebView no iOS, WebView no Android). Ele reaproveita o investimento já feito no site ou no sistema web, mas ganha ícone na tela inicial, push notifications nativas, deep links e presença nas buscas das lojas.

É importante ser honesto sobre o principal risco: as diretrizes de revisão da Apple são explícitas ao rejeitar aplicativos que sejam apenas um site empacotado, sem funcionalidade nativa relevante ou valor próprio. Um WebView bem construído resolve isso com camadas nativas reais, push, armazenamento offline, biometria, compartilhamento, câmera para upload, navegação nativa e tratamento de estados sem conexão.

3. Multiplataforma (React Native, Flutter)

Frameworks multiplataforma compilam uma base de código para iOS e Android com interface nativa. Entregam performance próxima do nativo puro na maioria dos casos de negócio, com um time só. O custo aparece na dependência de bibliotecas de terceiros para recursos específicos e na necessidade de atualizar o framework quando os sistemas operacionais mudam.

4. Nativo puro (Swift / Kotlin)

Construído com as ferramentas oficiais de cada plataforma. É a escolha certa quando o produto vive de performance gráfica, sensores, processamento local, integrações profundas com o sistema ou requisitos de segurança e certificação específicos. Custa mais para construir e, principalmente, para manter, porque são duas bases de código.

Quanto custa: como montar o orçamento sem se enganar

Não existe preço de tabela para aplicativo, e desconfie de quem oferece um. O que existe é uma estrutura de custo previsível. Ela tem cinco linhas, e ignorar qualquer uma delas é o motivo mais comum de projeto estourado.

1. Descoberta e definição de escopo: entender objetivo, jornada, integrações e critérios de sucesso antes de escrever código.
2. Design de produto e interface: fluxos, protótipo navegável, design system, estados de erro, vazio e carregamento.
3. Desenvolvimento: front-end, back-end, integrações, autenticação, painel administrativo.
4. Qualidade e publicação: testes em dispositivos reais, acessibilidade, performance, contas de desenvolvedor, fichas de loja e revisão.
5. Operação contínua: hospedagem, monitoramento, correções, atualizações de SDK, adequação a políticas e evolução funcional.

Uma proposta com 80% do esforço em desenvolvimento e quase nada em descoberta, design e QA quase sempre significa retrabalho pago depois. Uma proposta sem linha de operação contínua significa que, em seis meses, o app vai parar de funcionar em algum aparelho e ninguém terá orçamento para corrigir.

Prazos reais: onde o cronograma trava

Cronogramas de aplicativo raramente atrasam por causa do código. Atrasam por três motivos: definição de escopo que muda no meio, integração com sistema legado do cliente que ninguém documentou, e a revisão das lojas. A revisão da Apple pode pedir ajustes de privacidade, de descrição, de fluxo de exclusão de conta ou de valor nativo do app. O Google Play tem políticas próprias de conteúdo, permissões e dados do usuário que precisam ser declaradas com precisão.

Publicação nas lojas: o que costuma reprovar

As causas de reprovação se repetem tanto que dá para listá-las. Vale conferir esta lista antes de submeter, não depois.

• App sem valor nativo próprio, funcionando apenas como atalho para um site.
• Ausência de política de privacidade acessível e coerente com os dados realmente coletados.
• Falta de fluxo de exclusão de conta dentro do app, quando existe cadastro de usuário.
• Permissões pedidas sem justificativa clara na interface e na ficha da loja.
• Login social ou por terceiros sem as alternativas exigidas pela plataforma.
• Conteúdo de demonstração, telas quebradas ou funcionalidades que não abrem no aparelho do revisor.
• Capturas de tela e descrição que prometem algo que o app não entrega.

Reserve tempo de cronograma para a revisão. Ela não é uma formalidade: é uma etapa de produto, com idas e vindas, e precisa de alguém responsável por responder rápido.

Performance: a métrica que decide se o app é usado

Aplicativo lento é aplicativo desinstalado. Em projetos com base web, PWA e WebView, as Core Web Vitals do Google (carregamento, interatividade e estabilidade visual) são o termômetro objetivo, e o Lighthouse gera o relatório. Em projetos nativos, os equivalentes são tempo de inicialização a frio, taxa de travamento e consumo de bateria e dados.

Segurança, LGPD e as obrigações que ninguém pode terceirizar

Se o app coleta qualquer dado pessoal, nome, e-mail, telefone, localização, identificador de dispositivo, a Lei 13.709/2018 se aplica. Isso significa base legal definida, finalidade informada em linguagem clara, consentimento quando for a base escolhida, política de privacidade acessível, canal para o titular exercer direitos e caminho real para exclusão de conta e dados.

• Comunicação sempre em HTTPS, com certificados válidos e renovação monitorada.
• Autenticação e autorização verificadas no servidor, nunca apenas na interface.
• Credenciais, chaves e tokens fora do código do aplicativo, no back-end.
• Coleta mínima: só o dado que tem uso definido e finalidade declarada.
• Registro de auditoria para operações sensíveis, com quem fez, o quê e quando.
• Plano de resposta a incidente definido antes de precisar dele.

Retenção: o app só vale se for aberto de novo

A métrica que separa um app que gera receita de um app que gera custo é retenção. Instalação é vaidade; retorno é negócio. E retenção não se resolve com design bonito, resolve-se com motivo recorrente para abrir.

1. Defina o 'momento de valor': a ação que faz o usuário perceber utilidade. Leve-o até lá na primeira sessão.
2. Crie um gatilho recorrente legítimo: status de pedido, saldo, agenda, benefício, conteúdo novo, lembrete útil.
3. Use push com parcimônia e segmentação. Notificação irrelevante é o caminho mais rápido para a desinstalação.
4. Meça coortes semanais, não médias gerais. Média esconde queda.
5. Feche o ciclo: o que o dado do app mostra precisa mudar a operação da empresa.

Aplicações por segmento

Varejo e comércio de bairro

Catálogo, pedido recorrente, programa de fidelidade, aviso de reposição e canal direto sem depender do alcance orgânico de rede social. O ganho principal é a recompra: o cliente que já comprou volta com custo de contato próximo de zero.

Serviços e profissionais liberais

Agenda, confirmação de horário, histórico de atendimento, envio de documentos e lembretes. A redução de falta em agendamento costuma pagar sozinha a operação do canal.

Associações, sindicatos e organizações da sociedade civil

Carteirinha digital, comunicação com associados, prestação de contas, inscrição em atividades e captação. É um dos contextos em que o app substitui com vantagem uma lista de transmissão frágil e não rastreável.

Franquias e redes com múltiplas unidades

Padronização de processo, treinamento, checklist de operação, comunicação da franqueadora e visão consolidada de desempenho por unidade. Aqui o app é ferramenta de governança, não só de marketing.

Erros que mais destroem orçamento

• Contratar app nativo para validar uma ideia que ainda não tem usuário nenhum.
• Tratar o aplicativo como 'site mobile bonito', sem motivo recorrente de uso.
• Deixar a integração com o ERP ou sistema legado para a última semana do cronograma.
• Não reservar tempo para a revisão das lojas.
• Publicar sem analytics: e depois discutir o que fazer sem nenhum dado.
• Encerrar o contrato no dia da publicação, sem plano de manutenção.
• Confundir número de instalações com resultado de negócio.

Checklist antes de assinar qualquer proposta

1. Qual problema de negócio o app resolve, em uma frase?
2. Qual é o critério de sucesso mensurável nos primeiros 90 dias?
3. Quem são os perfis de usuário e o que cada um pode fazer no sistema?
4. Quais sistemas precisam se integrar e quem é o responsável técnico de cada um?
5. Quais dados pessoais serão coletados e com qual base legal?
6. Precisa estar nas lojas? Por quê?
7. Quem opera o app depois de publicado, dentro da empresa?
8. Qual é o custo mensal de operação e quem paga?
9. O que acontece se, em 90 dias, o resultado não aparecer?

Como a Appmart.ai conduz projetos

Começamos por um diagnóstico curto e objetivo: objetivo comercial, jornada do usuário, integrações existentes, restrições legais e orçamento disponível. A partir daí recomendamos a tecnologia adequada, inclusive quando a recomendação é não fazer app agora, e desenhamos um escopo enxuto para a primeira versão, com critério de sucesso definido por escrito.

A entrega acontece em ciclos curtos, com ambiente de homologação acessível no celular do cliente desde as primeiras semanas. Publicação, monitoramento e evolução fazem parte do contrato, porque aplicativo é ativo digital: precisa de dono, orçamento e rotina.