Neste artigo
Uma agência web local, o fornecedor da caixa registadora ou um consultor de franchising faz, mais cedo ou mais tarde, a mesma pergunta: quer a sua própria app? A resposta que recebe é quase sempre emocional — "esteja onde está o seu cliente" — e quase nunca calculada no papel. Este artigo calcula-a, com os números que a própria indústria das apps publica.
Uma app nativa parece o passo lógico a seguir ao seu website: o cliente já encomenda a partir de um ecrã, porque não também a partir de um ícone no telemóvel? A ideia não é o problema. O que acontece a seguir, sim — e essa parte raramente é mencionada por quem lhe vende a app.
A indústria das apps móveis mede há dez anos, com exatidão, o que acontece a uma instalação: quantas pessoas a abrem, quantas continuam lá ao fim de um mês, quantas voltam ao fim de três. Estes números são sólidos, públicos e notavelmente constantes — e quase nunca aplicados a um único estabelecimento de restauração.
Este artigo faz exatamente isso, em quatro números: o que uma app custa mesmo a construir e a manter, que fatia dos seus próprios clientes a instala realisticamente, quantos deles ainda a abrem ao fim de 30 e 90 dias, e — a pergunta que realmente importa — quantas visitas extra são precisas até se pagar a si própria. No fundo, insira os seus próprios números numa calculadora que usa exatamente as mesmas contas do resto deste artigo.
A conclusão não é "nunca" nem "sempre". Para um estabelecimento independente com um único local, a resposta é quase sempre não — os números abaixo mostram exatamente porquê. Para um grupo com vários locais ou um conceito focado em entregas com volume real de encomendas repetidas, as mesmas contas podem fechar. A diferença não está na ambição, está na escala.
O guia definitivo Tecnologia & Dados No Restaurante: 6 Passos De 7 Ferramentas Para 1 Sistema De uma caixa registadora isolada a um sistema integrado: o guia completo para escolhas tecnológicas que realmente compensam. Abrir o guia1. O que custa construir uma app — e continuar a pagá-la
Um orçamento para uma app "simples" de encomendas e fidelização para um único local ronda, em agências especializadas, entre cerca de 8.000 € e 25.000 €, consoante quanto do seu sistema atual tenha de ser integrado. Junte reservas, seguimento de entregas ou um programa de fidelização mais completo, e sobe rapidamente para 40.000 € a 80.000 € — e é aí que a conta começa. Compare isso com honestidade com o que já tem na sua lista de subscrições de software: uma app raramente é o primeiro custo que quer acrescentar.
Acima do custo de desenvolvimento há dois custos recorrentes que nenhum orçamento coloca em destaque. A Apple cobra cerca de 92 € por ano por uma conta de developer, sem a qual nenhuma app de iOS chega a ficar online — deixe de pagar um ano e a sua app desaparece da App Store, por mais clientes que já a usem. A Google cobra 23 € uma única vez por uma conta Play Console. Valor pequeno, mas é o primeiro de muitos: cada grande atualização de iOS ou Android obriga a um novo ciclo de revisão, e uma app que fica dois anos sem atualização acaba rejeitada ou simplesmente impossível de encontrar na loja.
Há dois caminhos mais baratos, e ambos merecem uma menção honesta antes de continuar a ler. Uma progressive web app (PWA) — "adicionar ao ecrã principal" diretamente a partir do seu website atual — custa uma fração de uma app nativa, porque não há revisão da App Store, nem duas bases de código separadas, nem fatura anual da Apple envolvida. E se o sistema de reservas ou de encomendas que já usa oferece uma app como funcionalidade própria, o custo marginal dessa app é zero: já a está a pagar, use-a ou não.
Faça as contas: 70 € por ano para a Apple, 18 € uma única vez para a Google — antes de sequer escrever uma linha de código, e sem qualquer garantia de que um único cliente a chegue a abrir.
2. Quantos dos seus clientes a instalam mesmo
Pergunte a uma agência de apps qual a taxa de instalação e a resposta fica vaga: "depende". Pergunte às plataformas de fidelização que constroem apps autónomas para restaurantes pelos seus próprios números, e a resposta é mais concreta — mas é um número com origem. Os fornecedores de apps de fidelização reportam normalmente uma taxa de instalação de 10 a 20%, medida sobre os seus melhores clientes: pessoas que já são habituais. É a mesma armadilha dos quiosques de autoatendimento: tecnologia apelativa que só compensa para uma fatia muito específica dos seus clientes.
Esse é o problema. Esses 10 a 20% não são uma percentagem de todos os seus clientes, são uma percentagem dos seus habituais — e os habituais são já, por si só, uma minoria. Estudos sobre restauração colocam consistentemente em cerca de 70 a 77% a fatia de clientes que nunca voltam, e atribuem cerca de 65 a 80% da faturação aos clientes que voltam. Por outras palavras: o grupo sequer candidato a instalar uma app é, ele próprio, apenas um quinto a um quarto de toda a sua base de clientes.
Sobreponha estes dois números, e a fatia de TODA a sua base de clientes que instala a app cai para poucos pontos percentuais — não dez, muito menos vinte. Numa base de mil clientes são cerca de duzentos e vinte habituais, dos quais cerca de um em sete instala a app: trinta e três pessoas. Esse é o ponto de partida realista, não o número otimista do orçamento.
Em 1.000 clientes, com as proporções acima. Cada barra é uma fatia do passo anterior.
Estes são valores orientativos, não uma lei: um estabelecimento com clientes de entrega verdadeiramente fiéis atinge uma fatia de habituais mais alta; um com muito turismo, mais baixa. O padrão — um funil acentuado de cliente a instalação a uso ativo — confirma-se em quase todos os estudos.
3. Quem ainda abre a app ao fim de 30 e 90 dias
Uma instalação não é um utilizador. A indústria das apps móveis mede isto há anos através de curvas de coorte — quantas das pessoas que instalaram no dia zero voltam mais tarde — e o padrão é notavelmente constante, seja qual for a categoria de app. Business of Apps e Adjust reportaram para 2026 uma retenção média no dia 1 de cerca de 25%: de todos os que instalam, cerca de um em cada quatro chega a abrir a app uma segunda vez.
A partir daí, a queda acelera. As mesmas fontes situam a retenção média no dia 30 entre 5 e 7%, e nessa altura mais de 90% de todos os utilizadores já abandonaram a app. Ao dia 90 — o momento em que um desconto para a segunda visita deveria realmente começar a compensar — a retenção, na maioria das categorias, situa-se entre 3 e 5%. Isto não é o azar de um developer descuidado; é a média de milhares de apps, em dezenas de categorias.
Traduzindo isto para as trinta e três instalações do número anterior, restam, três meses depois, aproximadamente um utilizador ativo. Não um em trinta e três por cento — uma pessoa. Esta é a realidade por trás de "construímos uma app para trazer os clientes de volta": a probabilidade de um cliente qualquer ainda a abrir ao dia 90 anda perto de um em mil.
4. Quantas visitas extra são precisas para não perder dinheiro
Uma app só se paga a si própria se um utilizador ativo vier com mais frequência do que teria vindo sem ela — não mais do que a média, mais do que teria vindo de qualquer forma. Essa diferença não existe em nenhuma norma publicada do setor: nenhum relatório diz quantas visitas extra um utilizador da app gera realmente, porque varia por estabelecimento, conceito e oferta.
O que sabemos, colocamos frente a frente. Pegue no custo de desenvolvimento, divida-o pelo seu gasto médio por visita, e obtém o número total de visitas extra que a app tem de gerar para se pagar a si própria. Divida isso novamente pelo número de utilizadores ativos que restam ao fim de 90 dias, e fica claro quantas visitas extra por mês cada utilizador restante teria de fazer — um número que, para um estabelecimento normal, resulta totalmente irrealista.
Para um estabelecimento independente de dimensão média, o prazo de retorno estende-se por décadas. Não porque a app não valha nada, mas porque o número de pessoas que ainda a usam ao dia 90 é demasiado pequeno para sustentar um custo de desenvolvimento de milhares de euros — mesmo que cada utilizador restante fosse improvavelmente fiel.
Mesmo estabelecimento, mesmas taxas de instalação e retenção, três formas de ter uma app.
A barra da PWA assume as mesmas taxas de instalação e retenção da app nativa — só o custo de desenvolvimento difere. Na prática, o limiar para tocar em "adicionar ao ecrã principal" é mais baixo do que uma descarga de uma loja de apps, por isso isto é mais um piso do que tão depressa uma PWA se paga do que um teto.
Calcule para o seu próprio estabelecimento
Os números acima são médias. Introduza a sua própria base de clientes, gasto e orçamento — tudo é calculado localmente no seu navegador.
—
O número "visitas extra por mês graças à app" é a única suposição aqui sem fonte publicada — introduza-o com prudência em vez de com otimismo. Tudo é calculado localmente no seu navegador; nada é enviado nem guardado.
Quando as contas fecham mesmo
A conta acima está escrita para o estabelecimento que a maioria dos leitores deste artigo gere: um local, alguns milhares de clientes, um orçamento na casa das dezenas de milhares de euros. Mude essa escala e a conclusão pode inverter-se — não porque a curva de retenção mude, mas porque o custo de desenvolvimento não é multiplicado por local, enquanto a base de clientes é.
Considere um conceito focado em entregas com vários locais e uma base de clientes combinada de cerca de 50 000 pessoas, com uma frequência de encomenda mais alta e uma fatia de habituais maior do que o estabelecimento de restauração médio — realista para um negócio que entrega regularmente em vez de receber clientes ocasionalmente. Mesma app, mesmo orçamento de cerca de 37 500 €, mas agora repartida por uma base de utilizadores ativos muito maior.
Com pressupostos de instalação e retenção igualmente prudentes, essa app atinge o ponto de equilíbrio em cerca de 10 meses — em vez de décadas. A diferença não está na app, está no denominador: nessa escala restam utilizadores ativos suficientes para sustentar o custo de desenvolvimento; num único estabelecimento independente, não.
O que fazer antes de assinar
Assinar um orçamento custa uma assinatura. Estes três passos custam uma hora, e decidem se essa assinatura poupa dinheiro ou o custa.
Antes de pedir um orçamento
- Conte quantos dos seus clientes são realmente habituais — pessoas que voltam pelo menos mensalmente. Esse número, não toda a sua base de clientes, é aquilo sobre o qual uma app é de facto construída.
- Faça a si próprio uma única pergunta: o que faz a app que uma lista de difusão no WhatsApp, um cartão de fidelização gratuito ou um favorito no ecrã principal não conseguem fazer? Se a resposta honesta for "nada de concreto", a app é uma forma cara de fazer o mesmo.
- Abra a calculadora acima com os seus próprios números antes de falar com uma agência — assim saberá que resposta um orçamento lhe tem de dar, e não o contrário.
Se ainda assim construir uma
- Comece com uma PWA, não com uma app nativa. Se, ao fim de meio ano, estiver mesmo a ser usada, tem prova antes de fazer o investimento dez vezes maior.
- Coloque desde o primeiro dia uma vantagem concreta na app que não existe em mais lado nenhum — um cartão de selos que só acumula ali, um prato visível em primeira mão só ali. Sem motivo para a manter aberta, a curva de coorte acima repete-se exatamente.
- Reserve 15 a 20% do custo de desenvolvimento por ano para manutenção e atualizações das lojas de apps — isso não é um extra, é o preço de continuar online.
O caminho mais barato
- Verifique primeiro se o sistema de reservas ou de encomendas que já usa — ou está a considerar — já oferece uma app como funcionalidade, ao lado da outra automatização que já lhe dá. Nesse caso, o custo marginal é zero.
- Compare com honestidade esse caminho gratuito com o orçamento: as mesmas notificações push, a mesma integração de fidelização, sem uma fatura Apple separada.
- Leia o que uma app integrada assim oferece de concreto na página de produto da nossa própria app — a mesma pergunta, sem a agência pelo meio.
Nem um não, nem um sim — uma conta
Quase todo o proprietário que lê este artigo reconhece a sensação de que uma app faz parte de "um estabelecimento moderno". Essa sensação não está errada — simplesmente não é um modelo financeiro. Os quatro números acima mostram o que acontece entre o orçamento e o primeiro fecho anual: um funil acentuado de cliente a instalação a uso ativo, e um custo de desenvolvimento que tem de ser repartido por demasiado poucos utilizadores restantes.
Para um estabelecimento independente de dimensão média, a resposta é quase sempre: não agora, não nativa, não a esse preço. Isto não é um julgamento sobre a ambição — é o que as curvas de coorte de toda a indústria das apps preveem, aplicadas a um único estabelecimento em vez de a um público de massas.
O que funciona é o mesmo instinto — estar mais perto do cliente — sem o custo de desenvolvimento, a fatura das lojas de apps e a obrigação de atualização anual. A nossa própria app é exatamente esse caminho: a mesma funcionalidade, dentro de um sistema que já usa, sem uma segunda fatura de agência.