Web app vs mobile app: a decisão antes do build

Uma fundadora com quem trabalhamos no ano passado chegou ao kickoff com uma certeza: precisava de um app iOS. O produto dela era uma ferramenta de agendamento e cobrança para fisioterapeutas autônomos, o tipo de trabalho que acontece em uma mesa entre um paciente e outro, no notebook, com um segundo monitor mostrando a agenda do dia. Ela queria na App Store mesmo assim, porque era isso que um produto de verdade parecia para ela. Construímos um web app no lugar. Dezoito meses depois, ela tem clínicas pagantes em três estados e nunca uma vez sentiu falta do app nativo que pediu no primeiro dia.

Essa é a pergunta web app vs mobile app inteira em uma história. Um web app roda no navegador e funciona em qualquer dispositivo que abra uma URL. Um mobile app é instalado a partir de uma app store e roda de forma nativa no celular. Escolher entre os dois não é uma escolha sobre qual tecnologia é mais moderna. É uma pergunta sobre onde seus clientes de fato fazem o trabalho, e do que esse trabalho precisa do aparelho na mão deles. Responda isso com honestidade e a plataforma cai sozinha da resposta.

A maioria dos fundadores em estágio inicial é empurrada para o outro lado. O instinto de app store diz “empresa séria tem app”, então eles pagam para construir e manter duas plataformas para alcançar clientes que teriam sido igualmente bem servidos por um único bom web app. Este é um guia para tomar essa decisão a partir da cadeira do fundador, não da do desenvolvedor, com um framework que você roda em uma tarde.

Três coisas que os fundadores vivem confundindo

Antes de a decisão fazer sentido, três palavras precisam se separar, porque fundadores as usam como sinônimos e aí compram a coisa errada.

Um site é conteúdo que você lê. Um site institucional, um blog, uma landing page. Ninguém faz login para trabalhar.

Um web app é software que roda no navegador e no qual as pessoas fazem login para usar. O Gmail é um web app. O Figma é um web app. O dashboard do seu banco é um web app. Ele vive em uma URL, atualiza no instante em que você sobe a versão, e funciona no notebook, no tablet e no navegador do celular sem você construir três versões. Um progressive web app, ou PWA, é um web app que pode ser salvo na tela inicial do celular, funcionar em parte offline e enviar push notifications. Ele se parece e se comporta perto de um app instalado sem passar por uma loja.

Um mobile app é a coisa que você baixa da App Store ou da Google Play. Roda de forma nativa no celular, pode usar a câmera, GPS, Bluetooth e o sistema de notificações completo, e funciona offline por padrão. Construir um normalmente significa construir duas vezes, uma para iOS e uma para Android, ou usar um framework cross-platform para compartilhar código. Essa segunda decisão, nativo versus cross-platform, só importa depois que você decidiu que precisa de um mobile app afinal.

Mantenha essas três coisas separadas e boa parte da confusão no debate “web app vs mobile app” desaparece. Muito fundador acha que precisa de um mobile app quando o que precisa é de um web app que por acaso funciona bem no celular.

A pergunta real não é web vs mobile

Aqui está o movimento que economiza mais dinheiro do fundador: pare de comparar as plataformas e comece a descrever o trabalho.

As plataformas são só mecanismos de entrega. O que importa é o trabalho que seu cliente está fazendo quando recorre ao seu produto, e onde ele está quando faz isso. Um técnico de campo fotografando um medidor danificado num telhado sem sinal está fazendo um trabalho diferente de um gestor de operações conciliando notas fiscais numa terça à tarde. O primeiro precisa da câmera, do GPS e de armazenamento offline, então quer ser nativo. O segundo precisa de um teclado de verdade e de uma tela grande, então quer ser um web app. Nenhum dos dois fundadores deveria começar por “iOS ou navegador”. Deveriam começar pelo telhado e pela terça à tarde.

É por isso que a SERP cheia de listas “20 prós e contras” é inútil para você. Prós e contras no abstrato são ruído. A mesma funcionalidade que é um pró para um app de fitness de consumo, push notifications te cutucando para fechar os anéis, é irrelevante para uma ferramenta B2B que as pessoas abrem quando um e-mail manda. Você não precisa de uma matriz de funcionalidades. Você precisa conhecer o dia do seu cliente.

As quatro perguntas que realmente decidem

Rode seu produto por estas quatro. As respostas apontam para web app, PWA ou nativo de forma muito mais confiável do que qualquer tabela de comparação genérica.

1. Onde o trabalho acontece fisicamente? Numa mesa, no notebook, com outras abas abertas? Isso é território de web app, ponto final. Em movimento, em campo, no corredor de uma loja, no carro, longe de um teclado? Isso puxa para mobile. Seja honesto sobre onde o trabalho de fato ocorre, não sobre onde você imagina os usuários sonhando com a sua marca.

2. Do que o trabalho precisa do aparelho? Liste os recursos de hardware e de sistema operacional que a tarefa central genuinamente exige. Câmera para captura de documento ou código de barras. GPS para localização. Bluetooth para um dispositivo. Uso offline confiável sem sinal. Push notifications ricas que precisam chegar mesmo com o app fechado. Se a sua tarefa central precisa de dois ou mais desses de forma profunda, um app nativo justifica o custo. Se não precisa de nenhum, você está pagando por um app nativo para entregar uma experiência de web.

3. Com que frequência os clientes voltam, e por qual porta? Uma ferramenta que as pessoas usam todo dia, que querem a um toque de distância na tela inicial, se beneficia de ser instalada. Uma ferramenta usada por semana ou por mês, que se alcança clicando num link de um e-mail ou de uma mensagem no Slack, é melhor como web app. Descoberta importa aqui. Se seus clientes te encontram e voltam por e-mail, busca e links compartilhados, uma URL é a sua porta de entrada. Um anúncio na app store não é.

4. Quanto você pode pagar para construir e manter ao longo de 18 meses, não só para lançar? Esta é a pergunta que fundadores pulam e da qual se arrependem. Um app nativo raramente é uma construção só. É iOS mais Android, dois processos de revisão de loja, atualizações de sistema operacional que quebram coisas duas vezes por ano, e um ciclo de release em que corrigir um bug significa esperar pelos revisores da Apple em vez de subir a correção em uma hora. Construir para duas plataformas nativas normalmente custa bem mais do que um único build web, e a diferença de manutenção se acumula a cada trimestre depois do lançamento. Se o seu runway é apertado, cada plataforma que você adiciona é um imposto que você paga para sempre.

Se três das quatro respostas apontam para o navegador, construa o web app e pare de se convencer a fazer mais. Se três apontam para o celular, o custo nativo está justificado. Quando elas se dividem, as duas próximas seções são para você.

Quando um web app ou PWA é a escolha certa

Para a maioria dos produtos B2B, ferramentas internas, dashboards, marketplaces e qualquer coisa que as pessoas usam numa mesa, um web app não é o meio-termo. É a resposta correta.

Você sobe a versão no momento em que faz o deploy, sem nenhuma revisão de loja sentada entre você e seus clientes. Um único código serve notebook, tablet e navegador de celular. O onboarding é um link, que é a distribuição de menor atrito que existe. E quando um cliente bate num bug numa sexta, você conserta na sexta, não na próxima terça depois que um revisor acordar.

Se o seu produto quer um pé no celular sem o custo nativo completo, um PWA é o meio subestimado. Os clientes podem adicioná-lo à tela inicial, ele pode funcionar offline para dados em cache, e pode enviar push notifications no Android e, cada vez mais, no iOS. Ele não vai igualar um app nativo em gráficos pesados, acesso profundo ao hardware ou no capricho dos gestos nativos da plataforma. Para uma grande fatia dos produtos de fundador, ele não precisa. O trade-off honesto é que PWAs perdem para o nativo em capacidade bruta e ganham em custo e velocidade de iteração. Para uma ferramenta na qual as pessoas fazem login para trabalhar, essa troca normalmente favorece a web. A orientação do próprio Google sobre progressive web apps é um bom ponto de partida sobre o que eles conseguem e o que não conseguem fazer hoje.

Quando você realmente precisa de um app nativo

Às vezes o celular não é um item desejável. Ele é o produto.

Construa nativo quando a tarefa central vive no celular e se apoia com força no aparelho: um app de navegação, um produto câmera-first, uma ferramenta de entrega ou logística usada em campo, qualquer coisa que precise de operação offline confiável, localização em tempo real, hardware Bluetooth ou confiabilidade de notificação que você não pode comprometer. Construa nativo quando o uso diário e habitual é o modelo de retenção inteiro e o ícone na tela inicial está fazendo trabalho de verdade para trazer as pessoas de volta. Construa nativo quando a performance é a experiência, onde meio segundo de travada lê como quebrado.

Se esse é você, o custo nativo não é desperdício. É o preço do produto funcionar afinal. O ponto do framework não é te convencer a desistir do nativo. É garantir que você está pagando por nativo porque o trabalho exige, não porque a App Store pareceu um marco a ser batido.

“Qual construir primeiro?”

Esta é a pergunta que metade da SERP promete responder e aí desconversa. Aqui está a versão honesta.

Para a maioria dos fundadores, construa o web app primeiro, mesmo que você esteja confiante de que um app nativo está no seu futuro. O web app é mais barato, sobe mais rápido, roda em todo dispositivo que seus primeiros clientes têm, e te ensina o que o produto deveria ser antes de você se comprometer com a plataforma mais cara. Você descobre quais funcionalidades importam, em quais telas as pessoas vivem, e quais partes do seu plano de dia um estavam erradas. Aí, se as quatro perguntas ainda apontarem para nativo, você o constrói sabendo exatamente o que construir, em cima de um backend que o web app já provou.

A exceção é o pequeno conjunto de produtos em que o celular é a experiência inteira desde o primeiro dia, em que um web app não seria uma versão menor do produto, mas uma versão diferente e pior. Um app de consumo cuja pitch inteira é câmera-mais-localização não tem nenhuma versão web útil. Para todo o resto, web primeiro não é se contentar com menos. É sequenciamento, e é a mesma disciplina por trás de um produto mínimo viável de verdade: construa a menor coisa que faz o trabalho bem, aprenda, depois expanda a superfície de propósito. A decisão web app vs mobile app é uma instância do julgamento mais amplo de build versus buy versus sequenciar que todo fundador faz uma dúzia de vezes.

A app store é distribuição, e distribuição tem preço

Mais uma coisa que o instinto “empresa séria tem app” não vê. A App Store e a Google Play não são só um lugar para colocar o seu app. São um canal de distribuição, e canais cobram aluguel.

Esse aluguel vem em três formas. Tem a comissão, historicamente de 15 a 30 por cento de tudo que você vende dentro do app, embora o programa para pequenos negócios da Apple baixe para 15 por cento abaixo de um milhão de dólares por ano. Tem a latência de revisão: cada release, incluindo a correção urgente, espera numa fila que você não controla. E tem a descoberta, que os fundadores mais superestimam. Ninguém está navegando na loja e tropeçando na sua ferramenta B2B de agendamento. Você vai divulgá-la pelos mesmos canais pelos quais divulgaria um web app, e aí pedir para as pessoas irem instalar, somando um passo. A loja é um pedágio que você escolhe atravessar quando a experiência nativa vale o pedágio. Não é alcance grátis, e não é troféu.

Nada disso significa evitar a App Store. Significa contá-la como custo, do jeito que você conta qualquer outro, em vez de tratar “estamos na App Store” como um objetivo que se paga sozinho. Ele raramente se paga por conta própria.

A fundadora da ferramenta de fisioterapia entendeu isso assim que abrimos a conta. Os clientes dela estavam em mesas, o trabalho precisava de teclado e tela e de nada do hardware do celular, eles voltavam por lembretes de e-mail, e o runway dela não conseguia carregar dois builds nativos. Cada uma das quatro perguntas apontava na mesma direção. O app nativo nunca foi o produto de que ela precisava. Era a imagem na cabeça dela do que um produto deve ser. O trabalho, uma vez descrito sem rodeio, já tinha escolhido o navegador.

FAQ

O que é melhor, um mobile app ou um site?
Nenhum é melhor no abstrato. Um site é para conteúdo que as pessoas leem; um web app é software no qual as pessoas fazem login; um mobile app é instalado a partir de uma loja e usa o hardware do celular. O certo depende de onde o trabalho acontece e do que ele precisa do aparelho. Para a maioria dos produtos de mesa e B2B, um web app ganha em custo, velocidade e alcance. Para produtos de campo, de câmera ou de hábito diário, o nativo se paga.

Um web app pode ser um mobile app?
Na prática, sim, e é isso que um progressive web app é. Um PWA roda no navegador mas pode ser salvo na tela inicial, funcionar offline para dados em cache e enviar push notifications, então se comporta muito como um app instalado sem passar por uma app store. Ele não vai igualar um app nativo em uso pesado de hardware ou gráficos, mas para muitos produtos fecha a maior parte da diferença por uma fração do custo.

Por que PWA não é popular?
PWAs são amplamente usados, só que de forma silenciosa. Vários produtos que você usa são PWAs sem anunciar. A percepção de que não são populares vem de duas coisas: o iOS passou a suportá-los mais tarde e de forma mais parcial que o Android, e não há um anúncio de loja para deixá-los visíveis, então a adoção é invisível por desenho. Para fundadores, essa invisibilidade é uma vantagem, já que a distribuição acontece pelos seus próprios links em vez de uma loja lotada.

O Facebook é um web app ou um mobile app?
Os dois, e esse é o ponto. Empresas grandes rodam um web app e apps nativos de iOS e Android em paralelo porque têm o orçamento e a base de usuários para justificar cada plataforma. Esse é o modelo errado para copiar no estágio inicial. Apps grandes estão em todo lugar porque podem se dar a esse luxo, não porque todo produto precisa começar assim. Escolha a única plataforma que o trabalho dos seus clientes de fato exige, prove ela, depois adicione superfícies quando os números, e não o instinto, mandarem.