Quanto custa um aplicativo

1. Por que se paga duas vezes

É o fato que governa todo o orçamento, e o que se descobre mais frequentemente depois de ter pedido um primeiro orçamento.

• Dois sistemas, dois mundos. iOS e Android não têm a mesma linguagem, nem as mesmas convenções de exibição, nem as mesmas regras de permissão. Historicamente, isso significava dois desenvolvimentos completos, portanto cerca de duas vezes a carga.
• As tecnologias comuns reduzem a distância sem apagá-la. Escrever uma base compartilhada é hoje a norma, mas o ajuste fino, os testes e as particularidades de cada plataforma continuam a fazer duas vezes. Conte um acréscimo real, não uma duplicação.
• Duas lojas a satisfazer. Cada uma tem suas regras de publicação, suas imagens a produzir nas dimensões certas, seus textos a traduzir e sua análise a passar. É um trabalho administrativo por si só, distinto do desenvolvimento.
• Um parque de aparelhos, não um aparelho. Tamanhos de tela muito diferentes, versões de sistema antigas ainda em serviço. O que a web resolve com uma folha de estilos exige aqui testes em várias configurações.

Com escopo igual, um aplicativo custa, portanto, estruturalmente mais que um site. A verdadeira pergunta não é como pagar menos, mas se o aplicativo é necessário — é a seção 5, e ela merece ser lida antes de pedir um orçamento.

2. Calcular um desenvolvimento, item por item

Como para um site, nenhuma tabela de referência existe. Estes são os itens a fazer calcular separadamente: um orçamento que os funde em uma linha não pode ser comparado a nenhum outro.

• As telas. Conte-as, e distinga as que exibem das que captam: um formulário, com seus erros e seus casos-limite, custa várias vezes uma tela de consulta.
• A conta de usuário. Cadastro, acesso, senha esquecida, exclusão da conta — esta última exigida pelas lojas assim que há cadastro. Esse bloco é quase sempre subestimado.
• O servidor e os dados. Um aplicativo que apenas exibe conteúdo fixo é barato. Assim que registra algo, é preciso um banco, uma interface para administrá-lo e uma cópia de segurança. É muitas vezes o primeiro item do orçamento.
• As notificações. Tecnicamente simples, custosas em ajustes: permissões a pedir, comportamentos diferentes nos dois sistemas, e uma lógica de negócio a escrever para decidir o que enviar e quando.
• O pagamento dentro do aplicativo. Se houver uma compra, as lojas impõem seu próprio mecanismo e cobram uma comissão. É ao mesmo tempo um desenvolvimento e uma parte do seu faturamento.
• A homologação em aparelhos reais. Não negociável, e o primeiro item cortado em um orçamento apertado — o que se paga em correções depois da publicação, à tarifa de urgência.

3. O que corre a cada ano

Um site negligenciado continua no ar. Um aplicativo negligenciado torna-se inutilizável, e depois desaparece. É a diferença essencial, e ela é financeira.

• As taxas de conta de desenvolvedor. Publicar exige uma conta em cada loja: uma assinatura anual do lado da Apple, uma taxa única do lado do Google. Modesto, mas a assinatura da Apple não renovada retira o aplicativo da venda.
• As atualizações impostas. Cada ano, as novas versões do iOS e do Android deslocam regras, e as lojas exigem uma compilação com ferramentas recentes para aceitar uma atualização. É preciso, portanto, intervir mesmo sem mudar nada no aplicativo.
• O servidor. Hospedagem, banco de dados, cópias de segurança: uma despesa mensal que cresce com o uso.
• As correções. Uma falha não se vê como uma página quebrada: vê-se nas avaliações da loja, onde fica meses.
• O acompanhamento das avaliações. Ninguém cuida delas, e são a primeira coisa que um futuro usuário lê.

Provisione esses itens em três anos antes de assinar. Um aplicativo entregue sem orçamento de continuidade é um aplicativo que será retirado das lojas — às vezes antes de ter servido.

4. O custo das lojas: a recusa

É um item ausente de todos os orçamentos, e é real: a publicação não é um depósito, é uma análise. As duas lojas leem o aplicativo e recusam por motivos muitas vezes alheios ao desenvolvimento — uma política de privacidade incompleta, uma exclusão de conta impossível de encontrar, credenciais de teste que não funcionam, uma explicação de permissão julgada insuficiente, uma semelhança com um site sem valor próprio.

Cada recusa custa duas coisas. Tempo: uma correção, um novo envio, uma nova espera. E uma data: se o lançamento foi anunciado, ele escorrega. Um projeto conduzido sem margem nesse ponto acaba pagando uma urgência por um motivo administrativo.

Pergunte, portanto, a qualquer prestador quem gerencia a publicação e quem retoma as recusas. A resposta vale uma linha de orçamento.

5. A pergunta a se fazer antes de pagar

Muitos aplicativos não deveriam ter sido desenvolvidos, e o orçamento estaria melhor em outro lugar. Três perguntas resolvem isso com honestidade.

• O uso é repetido? Instala-se um aplicativo pelo que se abre com frequência — pedir, acompanhar, registrar ponto, fidelizar. Para uma consulta ocasional, um site no telefone faz melhor, sem instalação a obter.
• Você precisa do aparelho? Notificações, câmera, localização, funcionamento sem rede, códigos de barras: se nada disso serve, o aplicativo não traz o que a web não sabe fazer.
• Quem vai instalar? É o ponto que afunda mais projetos. Obter uma instalação é mais difícil que obter uma visita. Sem um público já cativo — clientes habituais, associados, equipes de campo — o aplicativo ficará vazio, qualquer que seja sua qualidade.

Se as três respostas não forem claras, comece pelo site: a página sobre quanto custa um site detalha esse caminho. O aplicativo virá quando o uso existir.

6. Pagar pelo depois, não pela publicação

Se a despesa se concentra depois do lançamento, então o que se precisa comprar não é um desenvolvimento: é uma presença que dure.

Na nullbot, o aplicativo se descreve em conversa, como o site. Vê-se ele rodar em um simulador de iOS e Android antes de qualquer publicação — pode-se manipulá-lo e tirar capturas. Ele pode ter seu banco de dados, passa por uma homologação, produz-se o binário para cada destino, e a publicação na App Store e no Google Play se comanda do mesmo lugar, com o status de cada loja à vista.

Continua não sendo o que vendemos. O que vendemos é o ano seguinte: a equipe de agentes que fica. Ela prepara as atualizações que as lojas reclamam, retoma uma recusa de análise, corrige o que falha, mantém as fichas e suas traduções, vigia as avaliações. O aplicativo não espera um orçamento de manutenção que não virá — é o trabalho corrente da equipe.

A despesa deixa de ser um projeto a financiar e depois a refinanciar. Ela se torna uma assinatura mensal, e a publicação não é mais uma linha de chegada.

7. Semana 1, mês 3, ano 2

Os três momentos que separam as ofertas — e não são os mesmos que para um site, porque as lojas impõem seu calendário.

• Semana 1. O aplicativo está publicado nas duas lojas, suas fichas estão preenchidas, uma conta de teste funciona para a análise. Um prestador competente sabe fazer isso.
• Mês 3. Três reclamações se referem à mesma tela, uma avaliação de duas estrelas está no topo, uma versão de sistema saiu. A pergunta passa a ser: quem publicou a correção? Um projeto entregue sem continuidade já está aqui perdendo seus usuários.
• Ano 2. As duas lojas exigem uma compilação com ferramentas mais recentes, sob pena de recusar qualquer atualização. Sem intervenção, o aplicativo continua instalado em quem já o tem, não se instala mais em lugar nenhum, e acaba não iniciando. É o momento em que aparece um orçamento de reformulação — pela mesma razão pela qual ele reaparecerá.

8. Os limites, ditos com franqueza

• Um aplicativo muito especializado continua sendo desenvolvimento sob medida. Processamento avançado de imagem, hardware conectado por Bluetooth, cartografia fina, um jogo: são ofícios, e um orçamento de desenvolvimento clássico.
• A análise das lojas não se garante. Nenhum prestador pode prometer uma aprovação, nem um prazo. O que se promete é retomar o processo até passar.
• Um aplicativo não cria seu público. Se ninguém o instala, nenhuma equipe mudará isso. Releia a seção 5: é a decisão mais econômica do projeto.
• O que compromete a empresa passa por uma validação. Uma colocação à venda, uma mudança de preço, uma mensagem enviada a todos os usuários são submetidas a você antes de sair.

9. Perguntas frequentes

Para ir além

Ler em seguida: como o aplicativo é criado, passo a passo, quanto custa um site, ou quanto custa um funcionário.