A pergunta errada vem primeiro
"Devemos construir um site ou um aplicativo?" é a pergunta que ouvimos em quase toda primeira reunião. É a pergunta errada. Ela pula uma etapa.
A pergunta certa é: o que esse produto precisa fazer, e para quem? Um site de marketing, um aplicativo web personalizado e um Progressive Web App (PWA) resolvem problemas diferentes. Escolher o formato errado não desperdiça apenas orçamento — ele te prende a uma arquitetura cara de desfazer seis meses depois, geralmente logo após a primeira rodada de feedback real dos usuários.
Este é o framework que usamos com clientes antes de escrever uma única linha de código, junto com faixas honestas de quanto cada opção custa e quanto tempo leva em 2026.
Três trabalhos diferentes, não três níveis do mesmo trabalho
As equipes costumam tratar isso como uma escada — site de marketing na base, PWA no topo, aplicativo no meio. Isso não é preciso. Eles não são versões mais ou menos sofisticadas uns dos outros. Eles respondem perguntas diferentes.
Site de marketing. Trabalho: converter um visitante em lead ou venda. Orientado a conteúdo, majoritariamente público, sem contas de usuário (ou, no máximo, uma versão simplificada para conteúdo restrito). O sucesso é medido em taxa de conversão, velocidade de carregamento e posicionamento nas buscas. Construído sobre um CMS ou um framework de site estático, raramente com lógica de backend personalizada além de formulários e analytics.
Aplicativo web personalizado. Trabalho: permitir que um usuário autenticado realize trabalho de verdade — gerenciar estoque, analisar sinistros, agendar horários, gerar relatórios. É aqui que vive a lógica de negócio: permissões, fluxos de trabalho, validação de dados, integrações com seu CRM ou ERP. O sucesso é medido em tempo de conclusão de tarefas e taxa de erro, não em visualizações de página.
PWA. Trabalho: dar a um aplicativo web a sensação de um aplicativo nativo — ícone instalável, acesso offline às telas principais, notificações push — sem o ciclo de revisão da App Store ou duas bases de código separadas. Não é tanto uma quarta categoria quanto um modo de entrega adicionado sobre um aplicativo web. Você não constrói "um PWA" em vez de um aplicativo web; você constrói um aplicativo web e decide quanto da camada PWA (service workers, cache offline, prompts de instalação) vale a pena adicionar.
Como escolher, na prática
Faça estas quatro perguntas, nesta ordem:
- O usuário faz login e realiza trabalho repetível, ou o visitante lê e vai embora? Trabalho repetível → aplicativo web. Ler e sair → site de marketing.
- O produto precisa funcionar com uma conexão instável, no celular, longe de uma mesa? Técnicos de campo, equipe de armazém, motoristas de entrega — sim. Profissionais de escritório com conexão estável — geralmente não, e a camada PWA é uma complexidade extra que você ainda não precisa.
- A visibilidade nas buscas faz parte de como as pessoas te encontram? Se sim, esse conteúdo precisa estar em um site de marketing rápido e rastreável — não escondido atrás da tela de login do seu aplicativo — e precisa ter os fundamentos técnicos (fundamentos de SEO: conteúdo renderizado no servidor, URLs limpas, schema funcionando) desde o primeiro commit, não adicionados depois do lançamento.
- Você precisa dos dois? A maioria das empresas B2B precisa: um site de marketing para gerar o lead, e um aplicativo web atrás do login onde o cliente pagante realmente vive. São duas construções, não uma — e tratar isso como um único projeto é um motivo comum para projetos web estourarem o orçamento original.
Se você está construindo o segundo tipo — o aplicativo que seus clientes realmente usam — é aí que nossa equipe de desenvolvimento web passa a maior parte do tempo, porque é ali que o custo e o risco realmente se concentram.
O que realmente impacta o custo
O custo não depende principalmente do número de páginas ou de "quantas funcionalidades". Ele depende de quatro fatores:
Complexidade do modelo de dados. Um aplicativo CRUD com poucos tipos de entidade simples é uma construção diferente de um com permissões baseadas em função em muitos tipos de entidade e trilhas de auditoria. Cada relação adicionada multiplica a superfície de testes, não apenas o schema.
Integrações. Cada sistema de terceiros ao qual você se conecta — Stripe, Salesforce, a API de uma transportadora, um banco de dados legado interno — adiciona tempo significativo dependendo de quão bem documentada e estável é a API desse sistema. Sistemas internos sem documentação são uma das maiores fontes de atraso de cronograma que vemos, porque os casos extremos só aparecem depois que a integração já começou.
Requisitos de tempo real e offline. Um painel que atualiza ao carregar a página é barato. Um painel com atualizações ao vivo via websockets, ou uma visualização mobile que precisa funcionar sem conexão e sincronizar depois, adiciona tempo de engenharia significativo sobre a construção base das telas afetadas.
Maturidade do design. Se você começa com um arquivo do Figma com todos os estados (vazio, carregando, erro, caso extremo) já desenhados, a construção anda rápido. Se o design acontece em paralelo com o desenvolvimento, espere retrabalho — as telas são construídas em cima de uma especificação que muda debaixo delas.
A senioridade e a localização da equipe afetam o valor da hora, mas raramente explicam as maiores variações no custo total do projeto. Os quatro fatores acima, sim.
Prazos realistas para 2026
Estas são faixas aproximadas para uma única construção bem escopada — não um portfólio com tudo que uma grande empresa poderia precisar — baseadas em projetos que escopamos recentemente:
- Site de marketing (algumas páginas, baseado em CMS, sem backend personalizado): algumas semanas.
- Aplicativo web personalizado, complexidade padrão (autenticação, alguns tipos de entidade principais, uma ou duas integrações): cerca de um trimestre.
- Aplicativo web personalizado, alta complexidade (permissões para múltiplas funções, várias integrações, recursos em tempo real): dois trimestres ou mais.
- Adicionar a camada PWA a um aplicativo web existente (cache offline para telas principais, prompt de instalação, push): algumas semanas, dependendo de quanto do aplicativo precisa funcionar offline versus apenas ser instalável.
Qualquer pessoa que dê um número fechado sem perguntar sobre seu modelo de dados, suas integrações e o estágio do seu design está chutando.
O padrão que mais vemos
O erro mais comum não é escolher o formato errado — é escolher um formato e pedir que ele faça os dois trabalhos. Uma empresa constrói um site de marketing bem-feito e depois tenta encaixar um painel de cliente na mesma base de código porque "já está construído". Meses depois, o painel está brigando com o CMS pelo controle do roteamento, e cada atualização de conteúdo arrisca quebrar um recurso da área logada.
A solução quase sempre é separá-los desde o início: um site de marketing leve, otimizado para velocidade e buscas, e um aplicativo web separado, otimizado para a experiência logada, compartilhando um design system, mas não uma base de código. Custa um pouco mais no início. Evita uma reconstrução depois.
Conclusão
Não comece com "site ou aplicativo". Comece com o que o usuário está fazendo e quanto disso precisa sobreviver a uma conexão ruim. Trate o site de marketing e o produto logado como duas decisões separadas, mesmo que uma única equipe construa os dois. E, ao precificar uma construção personalizada, pergunte sobre o modelo de dados e as integrações antes de perguntar sobre o número de páginas — é dali que vem o número real.
Se você está no ponto de escopar uma dessas construções e quer uma resposta direta sobre custo e prazo para o seu caso específico, fale com a gente antes de escrever o RFP.
