Quanto custa

Quanto custa uma aplicação móvel

Uma aplicação custa mais do que um sítio, e não é uma questão de complexidade: é que se paga duas vezes, e depois todos os anos. Duas vezes, porque iPhone e Android são dois sistemas distintos. Todos os anos, porque as duas lojas impõem atualizações para continuar publicável — uma aplicação em que ninguém mexe acaba retirada. O orçamento de fabrico nada diz dessa parte, e é ela que decide se o projeto sobrevive. Esta página detalha o método de cálculo, as rubricas que voltam, e o que muda uma subscrição em que uma equipa fica depois da publicação.

1. Porque se paga duas vezes

É o facto que governa todo o orçamento, e o que mais frequentemente se descobre 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 apresentação, nem as mesmas regras de permissões. Historicamente, isso significava dois desenvolvimentos completos, ou seja, cerca do dobro da carga.
As tecnologias comuns reduzem a distância sem a apagar. Escrever uma base partilhada é hoje a norma, mas a afinação fina, os ensaios e as particularidades de cada plataforma continuam a fazer-se duas vezes. Conte um acréscimo real, não uma duplicação.
Duas lojas a satisfazer. Cada uma tem as suas regras de publicação, as suas imagens a produzir nas dimensões certas, os seus textos a traduzir e a sua análise a passar. É um trabalho administrativo por si só, distinto do desenvolvimento.
Um parque de aparelhos, não um aparelho. Tamanhos de ecrã muito diferentes, versões de sistema antigas ainda em serviço. O que a web resolve com uma folha de estilos exige aqui ensaios em várias configurações.

Com âmbito igual, uma aplicação custa, portanto, estruturalmente mais do que um sítio. A verdadeira pergunta não é como pagar menos, mas se a aplicação é necessária — é a secção 5, e merece ser lida antes de pedir um orçamento.

2. Calcular um desenvolvimento, rubrica a rubrica

Tal como para um sítio, não existe qualquer tabela de referência. Eis as rubricas a fazer calcular separadamente: um orçamento que as funde numa linha não pode ser comparado com nenhum outro.

Os ecrãs. Conte-os, e distinga os que mostram dos que recolhem: um formulário, com os seus erros e os seus casos-limite, custa várias vezes um ecrã de consulta.
A conta de utilizador. Registo, início de sessão, palavra-passe esquecida, eliminação da conta — esta última exigida pelas lojas assim que há registo. Este bloco é quase sempre subestimado.
O servidor e os dados. Uma aplicação que apenas mostra conteúdo fixo é barata. Assim que regista alguma coisa, é preciso uma base, uma interface para a administrar e uma cópia de segurança. É muitas vezes a primeira rubrica do orçamento.
As notificações. Tecnicamente simples, dispendiosas em afinações: 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 da aplicação. Se houver uma compra, as lojas impõem o seu próprio mecanismo e cobram uma comissão. É ao mesmo tempo um desenvolvimento e uma parte da sua faturação.
A verificação em aparelhos reais. Não negociável, e a primeira rubrica cortada num orçamento apertado — o que se paga em correções depois da publicação, à tarifa de urgência.

3. O que corre todos os anos

Um sítio descuidado continua em linha. Uma aplicação descuidada torna-se inutilizável, e depois desaparece. É a diferença essencial, e é financeira.

As taxas de conta de programador. Publicar exige uma conta em cada loja: uma subscrição anual do lado da Apple, uma taxa única do lado da Google. Modesto, mas a subscrição da Apple não renovada retira a aplicação da venda.
As atualizações impostas. Todos os anos, as novas versões do iOS e do Android deslocam regras, e as lojas exigem uma compilação com ferramentas recentes para aceitarem uma atualização. É preciso, portanto, intervir mesmo sem mudar nada na aplicação.
O servidor. Alojamento, base de dados, cópias de segurança: uma despesa mensal que cresce com a utilização.
As correções. Uma falha não se vê como uma página avariada: vê-se nas avaliações da loja, onde fica meses.
O acompanhamento das avaliações. Ninguém trata delas, e são a primeira coisa que um futuro utilizador lê.

Provisione estas rubricas a três anos antes de assinar. Uma aplicação entregue sem orçamento de continuidade é uma aplicação que será retirada das lojas — por vezes antes de ter servido.

4. O custo das lojas: a recusa

É uma rubrica ausente de todos os orçamentos, e é real: a publicação não é um depósito, é uma análise. As duas lojas leem a aplicação e recusam por motivos muitas vezes alheios ao desenvolvimento — uma política de privacidade incompleta, uma eliminação de conta impossível de encontrar, credenciais de teste que não funcionam, uma explicação de permissão considerada insuficiente, uma semelhança com um sítio 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 tinha sido anunciado, ele desliza. Um projeto conduzido sem margem neste ponto acaba a pagar uma urgência por um motivo administrativo.

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

5. A pergunta a fazer antes de pagar

Muitas aplicações não deveriam ter sido desenvolvidas, e o orçamento teria estado melhor noutro lado. Três perguntas resolvem isso com honestidade.

A utilização é repetida? Instala-se uma aplicação por aquilo que se abre com frequência — encomendar, acompanhar, picar o ponto, fidelizar. Para uma consulta ocasional, um sítio no telemóvel faz melhor, sem instalação a obter.
Precisa do aparelho? Notificações, câmara, localização, funcionamento sem rede, códigos de barras: se nada disso serve, a aplicação não traz o que a web não sabe fazer.
Quem a vai instalar? É o ponto que afunda mais projetos. Obter uma instalação é mais difícil do que obter uma visita. Sem um público já cativo — clientes habituais, associados, equipas de terreno — a aplicação ficará vazia, seja qual for a sua qualidade.

Se as três respostas não forem claras, comece pelo sítio: a página sobre quanto custa um site descreve esse caminho. A aplicação virá quando a utilização existir.

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

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

Na nullbot, a aplicação descreve-se em conversa, tal como o sítio. Vê-se a funcionar num simulador de iOS e Android antes de qualquer publicação — pode manipulá-la e tirar-lhe capturas. Pode ter a sua base de dados, passa por uma verificação, produz-se o binário para cada destino, e a publicação na App Store e no Google Play comanda-se do mesmo sítio, com o estado de cada loja à vista.

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

A despesa deixa de ser um projeto a financiar e depois a refinanciar. Torna-se uma subscrição mensal, e a publicação já não é uma linha de chegada.

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

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

Semana 1. A aplicação está publicada nas duas lojas, as suas fichas estão preenchidas, uma conta de teste funciona para a análise. Um prestador competente sabe fazê-lo.
Mês 3. Três queixas incidem sobre o mesmo ecrã, uma avaliação de duas estrelas está à cabeça, saiu uma versão de sistema. A pergunta passa a ser: quem publicou a correção? Um projeto entregue sem seguimento está aqui já a perder os seus utilizadores.
Ano 2. As duas lojas exigem uma compilação com ferramentas mais recentes, sob pena de recusarem qualquer atualização. Sem intervenção, a aplicação continua instalada em quem já a tem, deixa de se instalar em qualquer lado e acaba por não arrancar. É o momento em que aparece um orçamento de remodelação — pela mesma razão pela qual voltará a aparecer.

8. Os limites, ditos com franqueza

Uma aplicação muito especializada continua a ser desenvolvimento à medida. Tratamento avançado de imagem, equipamento ligado 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 aceitação, nem um prazo. O que se promete é retomar o processo até passar.
Uma aplicação não cria o seu público. Se ninguém a instala, nenhuma equipa mudará isso. Releia a secçã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 utilizadores são-lhe submetidas antes de saírem.

9. Perguntas frequentes

Porquê não dar um preço médio para uma aplicação móvel?

Porque a distância entre uma aplicação de consulta e uma aplicação com contas, pagamento e notificações é tal que uma média nada informaria. As rubricas da secção 2, calculadas para o seu caso, dão uma ordem de grandeza defensável. Um valor único daria sobretudo uma falsa segurança no momento de comparar dois orçamentos.

Uma única aplicação para iPhone e Android custa menos?

Menos do que dois desenvolvimentos separados, sim, e é a prática corrente. Mas a poupança não é de metade: a afinação fina, os ensaios e as particularidades de cada plataforma continuam a fazer-se dos dois lados, e as fichas de loja são a produzir duas vezes. Conte um acréscimo relativamente a uma plataforma única, não uma gratuitidade da segunda.

É preciso uma conta Apple e Google em meu nome?

É fortemente preferível, e é um ponto a resolver antes de assinar. Uma aplicação publicada na conta de um prestador é difícil de recuperar, e o seu histórico de avaliações não se transfere. Abra as contas em nome da empresa, ainda que depois delegue o acesso: são quinze minutos no início, e um bloqueio completo mais tarde.

O que acontece se eu nunca atualizar a aplicação?

Três coisas, por esta ordem. As lojas recusam primeiro as suas novas versões porque as ferramentas de compilação são demasiado antigas. Depois a aplicação deixa de funcionar corretamente nos telemóveis recentes. Por fim, uma aplicação sem atualização há muito tempo pode ser retirada da venda. É o que distingue uma aplicação de um sítio: a inação não a deixa no lugar, elimina-a.

O meu sítio chega em vez de uma aplicação?

Na maioria dos casos de empresa, sim — e continua a ser verdade mesmo quando uma aplicação daria gosto. Um site funciona em todos os telemóveis, não exige instalação, não tem análise a passar nem atualização imposta todos os anos. A aplicação justifica-se quando a utilização é repetida e é preciso algo do aparelho. As três perguntas da secção 5 resolvem isso em poucos minutos.

Para saber mais

Ler a seguir: como se cria a aplicação, passo a passo, quanto custa um site, ou quanto custa um funcionário.