React Native, Flutter ou PWA: Qual Tecnologia Usar para o App da Sua Empresa

O gestor de uma rede de franquias recebeu três orçamentos para criar um app de pedidos internos. O primeiro indicava Flutter. O segundo, React Native. O terceiro, PWA. Os valores iam de R$ 28 mil a R$ 94 mil. Nenhum dos três fornecedores explicou por que havia escolhido aquela tecnologia. Ele não sabia qual pergunta fazer, e nenhum dos três fornecedores se preocupou em ajudá-lo a descobrir.

Não é escolher entre Flutter e React Native. É saber se a tecnologia proposta serve para o que sua empresa precisa, e se o fornecedor está vendendo o que você precisa ou o que ele sabe fazer.

Por que a tecnologia do app afeta o seu bolso, não só o código

A tecnologia define quanto você vai gastar para construir, quanto vai gastar para manter e o que vai acontecer com o dinheiro investido se precisar trocar de fornecedor no ano que vem.

Um app desenvolvido em Flutter por um time especializado fica preso naquele time. Se a agência fechar ou encarecer, você não chega facilmente em outro desenvolvedor com o mesmo domínio. Imagine um app contratado por R$ 60 mil. Sem documentação, outro time pode cobrar entre R$ 18 mil e R$ 36 mil só para ler e mapear o código antes de tocar em qualquer funcionalidade. Projetos mal documentados chegam ao limite superior dessa faixa.

O problema não foi usar Flutter, foi escolher Flutter sem avaliar o mercado local de desenvolvedores e o custo real de troca de fornecedor.

Em 2021, a SAP adquiriu o AppGyver, uma plataforma no-code popular entre pequenas empresas e startups. A versão community, usada por quem não pagava licença, ficou sem evolução ativa. As empresas que construíram apps inteiros ali, sem exportar o código, ficaram presas. O produto existia, mas parou de crescer junto com o negócio.

Em 2023, o Bubble.io, principal plataforma no-code para web apps, introduziu as "workload units", mudando o modelo de cobrança. Apps que rodavam por um custo fixo passaram a custar mais, sem aviso proporcional, em produção.

A decisão de tecnologia não é técnica. É financeira e operacional.

O que é cada uma em uma frase, sem jargão de desenvolvedor

PWA (Progressive Web App): um site que se comporta como app. Funciona no navegador, pode ser "instalado" na tela inicial do celular, mas não aparece nas lojas e tem acesso limitado a recursos do dispositivo.

React Native: um framework criado pelo Facebook para escrever um único código que gera apps para Android e iOS ao mesmo tempo. O resultado parece e age como um app nativo.

Flutter: uma ferramenta criada pelo Google com o mesmo objetivo: um código, dois sistemas. Usa uma linguagem própria chamada Dart e tem desempenho visual um pouco mais previsível que o React Native em alguns casos.

App nativo: escrito especificamente para iOS (Swift) ou Android (Kotlin/Java). O mais caro porque exige dois times ou dois projetos separados. O mais capaz porque usa os recursos do dispositivo sem intermediários.

Na pesquisa Stack Overflow Developer Survey 2024, Flutter tinha 9,4% de uso entre desenvolvedores profissionais e React Native 8,4%. Em projetos multiplataforma especificamente, Flutter detinha 32,8% do mercado e React Native 27,2%. Na prática, o que importa é: tem desenvolvedor Flutter ou React Native na sua cidade que você consegue contratar por fora se a agência atual encarecer? Para a maioria das cidades brasileiras fora do eixo SP-RJ, React Native tem pool de contratação maior, simplesmente porque JavaScript é mais ensinado.

Custo de desenvolvimento: o que entra na conta e o que o orçamento não mostra

Desenvolver um app no Brasil em 2025 custa, em média: de R$ 15 mil a R$ 30 mil para versões simples, de R$ 30 mil a R$ 70 mil para soluções com integrações, acima de R$ 100 mil para projetos com arquitetura mais robusta. Projetos de porte médio bem estruturados variam entre R$ 120 mil e R$ 195 mil por plataforma, segundo dados da Goappy e da Corujalab.

O que o orçamento raramente mostra:

• Custo de publicação nas lojas (Google Play e App Store cobram taxas anuais e têm processos de aprovação que podem atrasar o lançamento por semanas)
• Custo de infraestrutura de servidor (onde o app vai se conectar para buscar dados, processar pedidos, autenticar usuários)
• Custo de notificações push (serviços como Firebase têm camada gratuita, mas projetos maiores saem da faixa sem aviso)
• Custo de manutenção quando o Android ou iOS atualiza o sistema operacional e o app para de funcionar

Um estudo do Boston Consulting Group divulgado em junho de 2024 apontou que ao menos um terço dos projetos de desenvolvimento de software atrasa ou estoura o orçamento. O problema raramente é o desenvolvedor. É o cliente que pede 'só mais uma coisa' em cada reunião, e o fornecedor que aceita sem revisar o contrato.

Peça sempre um orçamento com escopo fixo por escrito. Se o fornecedor se recusar a detalhar o que está e o que não está incluído, esse é o primeiro sinal de problema.

Custo de manutenção: o que você vai pagar todo mês depois que o app sair do forno

O app entrou em produção. Agora começa a conta que nenhuma proposta detalhou.

PWA: mais barato para manter porque é essencialmente um site. O desenvolvedor que cuida do seu site pode, em muitos casos, cuidar do PWA. Custo de servidor e hospedagem já costumam estar na conta mensal de qualquer empresa com presença digital.

React Native e Flutter: exigem atualizações periódicas quando o iOS ou o Android muda. Cada nova versão do sistema operacional pode quebrar funcionalidades. Você vai precisar de um desenvolvedor com conhecimento específico nessa tecnologia disponível quando isso acontecer, e vai acontecer pelo menos uma ou duas vezes por ano.

App nativo: dobro da manutenção. Um projeto para Android, outro para iOS. Se os dois precisam de atualização ao mesmo tempo, o custo também dobra.

Quem vai manter o app depois da entrega, e a que custo? Essa resposta raramente aparece na proposta.

Se a resposta for "a gente mesmo pode fazer a manutenção por um contrato mensal", pergunte qual é o valor, o que está incluído e o que acontece se você quiser trocar de fornecedor.

Câmera, GPS, notificações e offline: o que cada tecnologia consegue (e onde trava)

Antes de discutir custo, uma pergunta resolve ou elimina tecnologias: o que o app precisa acessar no celular?

Se o seu app precisa leitura de QR code no estoque, integração com impressora Bluetooth ou biometria para autenticar acesso, o PWA provavelmente não resolve. Esse ponto sozinho elimina ou mantém tecnologias antes de qualquer discussão de custo.

Publicar nas lojas ou não publicar: o que muda na prática para a sua empresa

Apps na Google Play Store e na App Store passam por revisão. O processo leva de um a sete dias. Cada atualização que você quiser publicar passa pelo mesmo processo.

Isso tem impacto direto no tempo entre "corrigimos um erro" e "o usuário recebe a correção". Num app crítico para operação, esperar três dias por uma aprovação pode ser caro.

PWA não passa por revisão. Você publica a atualização e o usuário já tem acesso na próxima vez que abrir. Isso é uma vantagem real em contextos onde velocidade de atualização importa.

A desvantagem é que o PWA não aparece nas lojas. Se o objetivo é que o cliente final encontre o app pesquisando "app da empresa X" na Play Store, o PWA não entrega isso. Se o objetivo é uso interno pelos seus funcionários, a distribuição por link resolve e elimina toda a burocracia de loja.

Quando o PWA é a resposta certa (e quando ele é a opção barata que vai custar caro depois)

O PWA faz sentido quando:

• O app vai ser usado em conexão boa (escritório, loja com Wi-Fi)
• Os usuários são funcionários, não clientes que precisam encontrar o app numa loja
• As funcionalidades são formulários, consultas, aprovações, listas
• O orçamento é limitado e a prioridade é lançar rápido para validar o processo

O PWA vai custar caro depois quando:

• O app precisa funcionar offline com frequência e gravar dados localmente para sincronizar depois
• Os usuários vão usar câmera, biometria ou Bluetooth como parte central do fluxo
• O crescimento futuro exige funcionalidades de hardware que o PWA não suporta

O risco real não é escolher PWA. É escolher PWA porque é mais barato agora e descobrir em 14 meses que precisa refazer tudo em React Native. Um app de gestão de pedidos validado em PWA por R$ 25 mil, depois reescrito em React Native por R$ 55 mil, com três meses de operação travada no meio: custo real de R$ 80 mil. O React Native feito desde o início, no mesmo escopo, sairia entre R$ 45 mil e R$ 65 mil.

Quando o Flutter ou o React Native fazem sentido para uma PME

Faça essas três perguntas antes de assinar:

1. O app vai para as lojas? Se sim, PWA sai da lista.

2. O app precisa de câmera, biometria, Bluetooth ou outra integração com hardware? Se sim, PWA sai da lista.

3. Qual é o tamanho da comunidade de desenvolvedores que conhece essa tecnologia na sua cidade? Isso define o custo de manutenção no longo prazo. Flutter e React Native têm comunidades grandes no Brasil. Uma tecnologia obscura proposta por uma agência específica pode deixar você sem opção de troca de fornecedor.

React Native faz sentido se o time de tecnologia da empresa já trabalha com JavaScript, porque há reaproveitamento de conhecimento. Flutter faz sentido se o objetivo é visual mais polido e desempenho mais previsível em dispositivos variados.

Na prática, a diferença técnica entre Flutter e React Native costuma pesar menos do que o histórico do fornecedor e o que está escrito no contrato.

O checklist para avaliar qualquer proposta que você receber, antes de assinar

Essas perguntas devem ter resposta clara antes de qualquer assinatura. Se o fornecedor não souber responder, ou desviar, registre como sinal de alerta.

Sobre a tecnologia escolhida:

• Por que essa tecnologia para o meu problema específico? (Se a resposta for "é o que usamos", questione)
• Essa tecnologia vai conseguir fazer X, Y e Z que são centrais para o meu processo?
• O que acontece quando o iOS ou Android lançar uma atualização grande?

Sobre o custo real:

• O que não está incluído nesse orçamento?
• Qual é o custo mensal de infraestrutura de servidor?
• Qual é o custo de manutenção depois da entrega e o que está coberto?

Sobre o risco de aprisionamento:

• O código vai ser meu? Em qual formato ele é entregue?
• Se eu precisar trocar de fornecedor, outro desenvolvedor consegue continuar o projeto sem refazer tudo?
• Existe documentação técnica incluída no escopo?

Sobre o histórico do fornecedor:

• Vocês têm outros clientes usando esse app em produção? Posso conversar com um?
• Quanto tempo de experiência com essa tecnologia específica?
• O que acontece se o prazo atrasar? Existe penalidade no contrato?

O gestor de franquias com três orçamentos na mão deveria ter feito pelo menos metade dessas perguntas antes de qualquer reunião de proposta. Provavelmente eliminaria dois dos três fornecedores ainda na primeira conversa.

Se o app envolve login, pagamento, notificações ou dados sensíveis, complemente essa análise com as 23 perguntas antes de contratar uma empresa para desenvolver aplicativo.

Se a proposta tiver qualquer um desses pontos, peça explicação antes de assinar: escopo sem detalhamento, tecnologia escolhida sem justificativa para o seu caso, ausência de cláusula de entrega de código, fornecedor que descarta outra tecnologia sem explicar por quê.

Se você está com orçamentos na mão e nenhum fornecedor explicou por que escolheu aquela tecnologia, nem o que acontece se precisar trocar de equipe daqui a um ano, manda para a Coffe&Code Labs. A gente analisa a proposta gratuitamente e te diz se a tecnologia proposta aguenta o crescimento que você espera, ou se está te vendendo o mais barato agora que vai virar retrabalho em 14 meses. Veja também como estruturamos projetos de desenvolvimento de sistemas para empresas.