13 MINUTOS DE LEITURA
Site para SaaS: como estruturar o site do produto
Por:
Henrique Sabino
Um site para SaaS não é uma landing page. É um conjunto de páginas que precisa vender, explicar e sustentar o produto ao mesmo tempo: home, funcionalidades, preços, casos, documentação e registro de mudanças. A landing resolve uma campanha. O site do produto resolve o ciclo inteiro de compra.
Essa distinção quase não aparece em português. Procure o assunto e a busca devolve modelos de landing page ou conteúdo sobre como construir o software, que são duas coisas diferentes desta. Este artigo trata da terceira: a estrutura de páginas que um produto vendido por assinatura precisa ter, e o que muda em cada uma conforme o produto amadurece.
O que é um site para SaaS e por que ele não é uma landing page?
Uma landing page existe para uma decisão única, quase sempre vinda de uma campanha paga. Ela tem um argumento, uma prova e um botão. Funciona muito bem para o que foi feita e falha quando alguém chega com outra pergunta.
O site de um SaaS recebe públicos em estágios diferentes na mesma semana. Alguém que nunca ouviu falar do produto, alguém comparando três opções, alguém que já é cliente procurando documentação e alguém do time de compras querendo entender o modelo de cobrança. Uma página só não sustenta essas quatro conversas. Quem tenta resolver tudo em uma landing acaba com um texto que não serve para nenhum dos quatro.
Se o produto ainda não existe ou não vendeu, a conversa é outra e a página única continua sendo a resposta certa. Vale ver o que colocar no site antes de existir produto antes de investir em estrutura completa.
As páginas que todo site de SaaS precisa ter
A lista abaixo não é um teto e sim um mínimo. Cada linha responde a uma pergunta que alguém vai fazer, e a página existe para que a resposta não dependa de uma reunião.
Página | Pergunta que responde | Quando entra |
|---|---|---|
Home | Que problema isso resolve, para quem | desde o primeiro dia |
Funcionalidades | Como o produto resolve, na prática | quando há mais de um caso de uso |
Preços | Quanto custa e o que limita cada plano | assim que houver plano definido |
Casos ou clientes | Funcionou para alguém parecido comigo | com o primeiro cliente autorizado |
Documentação | Como eu uso, sem falar com ninguém | quando o produto tem configuração |
Registro de mudanças | Isso continua sendo mantido | quando há entrega frequente |
Blog | Vocês entendem do assunto | quando há alguém para escrever |
As duas últimas linhas são as que mais separam um site de SaaS de um site institucional comum. Documentação e registro de mudanças são conteúdo vivo, publicado toda semana, e é isso que determina a exigência técnica do projeto.
Como estruturar a página de preços?
Com o preço visível, sempre que ele existir. Esconder valor atrás de formulário só funciona quando o ticket é alto e a venda é consultiva de verdade. Em todos os outros casos, o visitante interpreta a ausência como caro demais ou desorganizado, e sai comparar com quem publica.
A estrutura que funciona tem quatro partes: os planos lado a lado com o que limita cada um, a unidade de cobrança dita sem ambiguidade, o que acontece ao ultrapassar o limite, e um bloco de perguntas frequentes tratando das objeções comerciais reais. A dúvida mais frequente numa página de preços não é quanto custa. É o que acontece se eu crescer.
A construção do próprio produto muda o que cabe nessa página. Sobre isso, vale entender o produto por trás da página de preços, porque limite de plano é decisão de arquitetura antes de ser decisão de marketing.
Trial, demo ou formulário: o que pedir ao visitante?
Depende do ticket e de quanto o produto se explica sozinho. Produto simples e barato pede teste imediato. Produto caro e configurável pede conversa. O erro comum é copiar o modelo de uma empresa com ticket completamente diferente do seu.
Há dados públicos que ajudam a decidir. Segundo o relatório de conversão da ChartMogul com a ProductLed, de janeiro de 2026, que analisou 200 produtos B2B, a mediana de conversão de gratuito para pago ficou em 8%. O recorte mais interessante é outro: testes que exigem cartão de crédito convertem em torno de 30%, mais de cinco vezes o resultado dos que não exigem.
Isso não significa que pedir cartão é sempre melhor. Significa que pedir cartão filtra, e filtrar cedo costuma valer mais que volume de cadastro. A decisão sobre qual pedido colocar na página é a mesma discussão de decidir qual é o próximo passo do visitante, aplicada a um produto de assinatura.
Qualquer que seja o pedido, o produto precisa aparecer funcionando antes dele. Um vídeo curto da interface real convence mais que qualquer descrição, e vale gravar a demo do produto com qualidade de peça de marketing em vez de improvisar uma captura de tela.
Docs, changelog e blog: o que o CMS precisa aguentar
Aqui está a exigência técnica que define o projeto. Documentação cresce sem parar, registro de mudanças é publicado a cada entrega e o blog acumula. Em pouco tempo, o site de um SaaS ativo tem mais páginas geradas por conteúdo do que páginas desenhadas à mão.
Na prática isso significa escolher uma plataforma que aguente coleções de conteúdo de verdade e permitir que o time publique sem depender de desenvolvedor. A página oficial de planos do Framer, consultada em setembro de 2026, dá a régua desse tipo de exigência: o plano intermediário cobre 10 coleções e 2.500 itens, com excedente vendido à parte até 40 mil itens.
Dois pontos costumam ser esquecidos no orçamento. O primeiro é quem escreve: documentação sem dono envelhece rápido e vira passivo. O segundo é a plataforma que dá CMS para docs e changelog sem virar projeto de engenharia. E há a conta recorrente de quem atualiza changelog e docs toda semana, que raramente entra na conversa antes de o site existir.
Site do produto e app: onde termina um e começa o outro?
Termina no login. Tudo que existe antes de entrar na conta é site: público, indexável, feito para convencer. Tudo depois é produto: privado, funcional, feito para ser usado. Misturar os dois é a origem de metade dos problemas de site de SaaS que chegam até nós.
Quando a fronteira fica confusa, aparecem sintomas conhecidos: páginas de marketing dentro do aplicativo, dados sensíveis em página pública, ou um site que só o time de engenharia consegue alterar, o que trava o marketing. Definir a divisa cedo evita retrabalho caro depois, e a discussão completa está em a fronteira entre o site e o sistema.
Erros comuns no site de um SaaS
Os cinco abaixo aparecem com frequência nos produtos que chegam até nós, e todos têm a mesma raiz: tratar o site como peça de lançamento e não como parte da operação. Corrigir depois custa mais caro do que estruturar certo desde o começo.
Descrever funcionalidade em vez de resultado. A lista de recursos não diz o que muda na vida de quem compra. Recurso é meio, resultado é o que se vende.
Esconder o preço sem motivo. Só faz sentido em venda consultiva de ticket alto. No resto, afasta quem estava pronto para comprar.
Documentação como anexo. Tratada como sobra do projeto, envelhece e vira o principal motivo de chamado de suporte.
Registro de mudanças abandonado. Um changelog parado há oito meses comunica exatamente o oposto do que ele existe para comunicar.
Site que só o desenvolvedor edita. Se publicar um texto exige abrir uma tarefa de engenharia, o conteúdo simplesmente para.
Quanto custa um site de SaaS e o que muda conforme o estágio
Um site de produto com estrutura completa fica na faixa de R$ 10 mil a R$ 40 mil, e o que move o valor dentro dela é o número de páginas com layout próprio, quem escreve os textos e quanto do movimento é feito sob medida. Produto com área logada e integrações entra em outra conta, na faixa de R$ 20 mil a R$ 100 mil.
O caminho mais econômico é construir por camadas, seguindo a maturidade do produto. Home e preços primeiro, funcionalidades quando houver mais de um caso de uso, documentação quando a configuração exigir, registro de mudanças quando a frequência de entrega justificar. A régua completa por tipo de projeto está em o orçamento de um site com muitas páginas e integrações.
Perguntas frequentes
Devo mostrar o preço no site do meu SaaS?
Sim, sempre que existir um plano definido. Esconder valor só se justifica em venda consultiva com ticket alto e escopo variável. Nos demais casos, o visitante interpreta a ausência como preço alto ou falta de clareza e vai comparar com quem publica.
Qual a diferença entre landing page e site de SaaS?
A landing serve a uma decisão única, quase sempre vinda de campanha paga. O site do produto atende públicos em estágios diferentes ao mesmo tempo, do curioso ao cliente que procura documentação. Um não substitui o outro e muitas empresas mantêm os dois.
Preciso de blog no site do produto?
Só se houver quem escreva com constância. Blog parado comunica abandono e pesa contra. Se a escolha for entre blog irregular e documentação bem mantida, a documentação entrega mais, porque atende cliente e ainda atrai busca de quem procura solução.
O site do SaaS deve ficar no mesmo domínio do aplicativo?
Normalmente sim, com o produto em um subdomínio ou em um caminho após o login. Domínios separados fragmentam autoridade de busca e confundem quem já é cliente. O importante é a divisa ser clara: público antes do login, privado depois.
Quanto tempo leva para fazer um site de SaaS?
De 4 a 6 semanas para a estrutura inicial com home, funcionalidades e preços. Documentação e registro de mudanças costumam entrar em uma segunda fase, porque dependem de conteúdo que o time do produto precisa produzir e manter. O que mais alonga o prazo não é a construção das páginas, é a definição do que cada uma vai dizer.
Se você está estruturando o site do seu produto agora, vale conversar sobre o site do seu produto com a Wama. Boa parte do nosso portfólio é SaaS, com site, sistema e aplicativo convivendo no mesmo projeto.
