O que aprendi administrando um negócio por 4 anos em um mercado de SaaS altamente competitivo

xguru · 2025-04-14T11:01:01+09:00

O OnlineOrNot, criado por Max Rozen, começou em um mercado onde já existiam mais de 200 produtos concorrentes No início, muitos produtos eram difíceis de usar, e depois inúmeros concorrentes surgiram e desapareceram rapidamente Alguns concorrentes receberam investimento de VC e foram adquiridos por grandes empresas, e a experiência do usuário foi piorando cada vez mais O OnlineOrNot tem como objetivo ser um negócio sustentável no longo prazo, financiado com recursos próprios O autor ainda mantém um emprego em tempo integral enquanto continua desenvolvendo seu SaaS de forma consistente Ele escreve uma retrospectiva todos os anos, e algumas lições aprendidas no passado acabaram se mostrando erradas com o tempo Princípios que não mudaram Ao longo dos anos, aprendi muita coisa sobre administrar um negócio, mas ainda existem princípios centrais que continuam os mesmos Investir 2 horas em cada dia útil Mesmo antes de começar o OnlineOrNot, eu já dedicava 2 horas todas as manhãs, antes do trabalho, a projetos pessoais Usei esse tempo para concluir centenas de textos, um livro e vários projetos de software Mais importante do que quanto você investe por dia é o esforço consistente, todos os dias Para garantir esse tempo, eu acordava 2 horas mais cedo e ajustava minha rotina Não fazer outros side projects Como diz o ditado, “quem persegue dois coelhos não pega nenhum”, então foquei em uma coisa só Algumas pessoas excepcionais conseguem fazer vários projetos darem certo, mas eu reconheço que não sou assim Considerei que o trecho de $0 até $500 de MRR é o mais difícil e que não vale a pena repeti-lo várias vezes Preferi focar em um modelo que já funciona, e escolhi meu marketing com a mesma lógica A prioridade é resolver a dor do cliente Quando um usuário se cadastra, envio um e-mail automático perguntando: “Por que você se cadastrou?” Leio todos os e-mails e respondo pessoalmente, e isso se tornou a principal fonte de insights para melhorar o produto Entender o que incomoda os usuários e realmente resolver isso Repetir e melhorar com persistência Se eu não consigo colocar algo em produção em até 2 horas, reduzo o escopo e publico primeiro uma versão menor Nem sempre dá para acertar exatamente as 2 horas, mas prefiro lançar rapidamente uma versão inicial e expandir depois Se eu tento construir tudo antes de publicar, acabo perdendo motivação e foco Concluir funcionalidades gradualmente por trás de feature flags é muito mais eficaz Lições aprendidas Ler poucos livros e começar a fazer logo No começo, li dezenas de livros de negócios para cometer menos erros Mas no fim percebi que aprender errando na prática é o jeito mais eficaz Ex.: apareceu na capa do Hacker News e recebeu 6.000 visitas, mas só um número de um dígito chegou de fato até o app Só no formulário de cadastro havia 75% de abandono → adicionar uma única opção de login com OAuth reduziu isso para 50% Se eu começasse de novo, leria apenas estes três livros e partiria para a execução: The Mom Test (Rob Fitzpatrick) Deploy Empathy (Michele Hansen) Badass: Making Users Awesome (Kathy Sierra) Se precisar de mais detalhes práticos sobre operar um SaaS, eu também recomendaria The SaaS Playbook (Rob Walling) Antes de vender assinatura, resolva o problema O objetivo de um SaaS não é vender assinaturas, e sim resolver a dor do cliente Em vez de pensar “se eu continuar criando funcionalidades, uma hora as pessoas vão usar”, é preciso mudar para “vamos resolver um problema irritante no trabalho do usuário” SaaS é apenas uma forma de resolver problemas; também é possível fazer isso com screencasts, documentação, textos, livros, workshops, exemplos de código e outras abordagens Construa pequeno e publique com frequência Usuários sugerem ideias de funcionalidades, mas na prática quase nunca as usam Quem está começando um SaaS tende a ficar tão feliz só por alguém conversar com ele que acaba implementando qualquer funcionalidade sem pensar muito É melhor perguntar como a pessoa pretende usar aquilo e investigar como outros usuários resolvem o mesmo problema, e então implementar primeiro o mínimo necessário para ver a reação Em vez de criar uma “funcionalidade floco de neve” usada por uma única pessoa, o importante é adotar uma abordagem estratégica para criar algo útil para muita gente Dói remover uma funcionalidade em que você investiu algumas horas, mas é muito pior remover algo em que você investiu meses Publique primeiro, pense em escala depois A primeira versão do OnlineOrNot foi lançada rapidamente, sem otimização de arquitetura Na prática, havia um bug que limitava o sistema a processar cerca de 100 checks, e quando algo dava errado, a UI mostrava apenas “Error!”, em um estado bastante inacabado Mesmo assim, o autor preferiu ser criticado por uma UI incompleta a perder tempo criando funcionalidades desnecessárias Como não há garantia de que milhares de usuários chegarão desde o primeiro dia, validar rápido era mais importante Como solução temporária, ele fez upgrade do banco de dados para um plano superior e aumentou a capacidade de checks Em poucas horas, refatorou a estrutura para suportar milhões de checks e também melhorou a tela de erro Manter um programa de early access No começo do desenvolvimento, a maioria dos usuários é relativamente tolerante com funcionalidades incompletas Com o tempo, mais usuários passam a esperar um produto mais maduro Para resolver isso, foi adicionada uma checkbox em cada conta de usuário para “participar do programa de early access” quem participa testa primeiro as funcionalidades mais novas, ainda não finalizadas, e fornece feedback Isso funcionou bem como uma forma de equilibrar testes e feedback Introduza o teste grátis o mais cedo possível Hoje em dia é comum ouvir o conselho de que “plano gratuito é difícil demais de acertar, então melhor não fazer” Mas no início, o plano gratuito ajudou bastante no boca a boca e na aquisição de usuários O lado ruim é que, se o plano gratuito for muito diferente do pago, você precisa dar um jeito de as pessoas experimentarem as boas funcionalidades Só 11 meses depois do início ele adicionou, no onboarding, a pergunta “você quer começar um teste grátis?” na prática, isso queria dizer: “Você quer testar as funcionalidades boas por 14 dias e decidir, ou prefere usar por meses uma versão limitada e acabar decepcionado?” Depois, ele passou a testar oferecer teste grátis por padrão para todos os usuários e só esse experimento fez a taxa de crescimento mensal mais que dobrar Conclusão: a mensagem “este é um serviço pago; para continuar usando as boas funcionalidades, precisamos das suas informações de pagamento” é muito mais eficaz para o negócio do que “este é um serviço gratuito; talvez fique pago se você usar bastante” A documentação é parte do produto Antigamente era comum ouvir que “desenvolvedores não leem documentação”, mas isso é completamente falso Alguns dos clientes ideais elogiaram a documentação do OnlineOrNot, e isso levou o autor a investir nela com mais foco Ele também construiu a documentação da API por conta própria para ter controle total da experiência do usuário Observando o comportamento com ferramentas de product analytics, percebeu-se que: Quando o usuário encontra um problema na UI, consulta a documentação e descobre a funcionalidade, ele continua usando o produto Quando não encontra a informação que queria, ele não cria checks e vai embora A qualidade da documentação está diretamente ligada à retenção de usuários Projete o produto pensando no mobile Ao contrário do que muita gente imagina, usuários de SaaS B2B também começam o trabalho pelo smartphone Na prática, cerca de 50% de todos os usuários começam a usar o produto no mobile criam uma conta, registram algumas páginas e depois voltam no PC para conferir Nos primeiros 6 meses, o produto não foi pensado para mobile, e a maioria dos usuários móveis abandonava Depois de introduzir uma UI responsiva, a retenção de usuários mobile aumentou visivelmente Pergunte diretamente ao usuário de onde ele veio Uma das mudanças de código mais valiosas introduzidas no meio do primeiro ano foi adicionar no cadastro a pergunta “onde você conheceu o OnlineOrNot?” Entender os canais de aquisição é extremamente importante para maximizar a eficiência do marketing Existem dezenas de canais de marketing, mas os recursos para focar neles são limitados Quando você identifica um canal que funciona bem, deve investir nele com foco e continuar até a resposta diminuir Não usar ferramentas de analytics invasivas No início, ele adotou rastreamento de sessão e ferramentas de análise de funil, como muitos produtos SaaS fazem, mas a efetividade foi baixa Isso pode ser útil para equipes grandes, mas em serviços pequenos há um risco alto de interpretar resultados aleatórios como se significassem algo Como fundador solo com apenas 2 horas livres todas as manhãs, foi mais eficiente ouvir diretamente um grupo de usuários de confiança (inner-circle) do que tentar analisar grandes volumes de dados Ele recebia feedback mais intuitivo sobre funcionalidades e problemas e melhorava o produto com base nessa percepção Converse com potenciais clientes mesmo sem ter a funcionalidade Um dia, um CTO perguntou se o produto suportava uma determinada funcionalidade A princípio, a ideia era encerrar com um “desculpe, ainda não temos isso”, mas por curiosidade, ele perguntou qual problema a empresa estava enfrentando e o que queria resolver também consultou usuários do inner-circle para saber se enfrentavam o mesmo problema e compartilhou ideias sobre como a funcionalidade poderia ser desenhada Como resultado, esse CTO virou cliente pagante no dia seguinte e continua sendo cliente até hoje E essa funcionalidade acabou sendo útil também para outros usuários Gasta-se mais tempo construindo a plataforma do que resolvendo o problema Nos últimos 4 anos, mais da metade do tempo de desenvolvimento foi gasto construindo a plataforma SaaS o objetivo original, “verificar se um site caiu e enviar alertas”, era só uma parte disso Na prática, foram necessárias funcionalidades como: vários métodos de autenticação e gestão de usuários trial, onboarding tarefas repetitivas de banco de dados, gestão de equipes, cobrança de faturas e-mails de ciclo de vida, entre outras Parte disso foi terceirizada com serviços como Stripe, mas muitas partes ainda precisaram ser feitas manualmente ou personalizadas, então acabaram sendo implementadas internamente Precificação é realmente difícil Se o preço for alto demais, as expectativas sobem ou a pessoa nem chega a se cadastrar Se o preço for baixo demais, um usuário que paga $9 pode exigir que o app inteiro seja adaptado ao gosto dele Solução: clientes difíceis recebem reembolso e seguem seu caminho o preço sobe, e você segue em frente especialmente no começo, conforme o produto ganha mais funcionalidades, experimentar continuamente com preços é essencial Não fique obcecado só com MRR MRR (Monthly Recurring Revenue) pode ser uma métrica inadequada para medir o desempenho do negócio O que você fez semanas ou meses atrás impacta o MRR de agora, então é difícil medir efeitos em tempo real Em alguns produtos SaaS, pode levar mais de 60 dias entre o cadastro e o pagamento real Por isso, é preciso acompanhar outras métricas para entender se o produto está sendo usado de fato e se está entregando valor por exemplo: número de imagens geradas, formulários enviados e outros indicadores de sucesso baseados em comportamento Nunca ofereça “ilimitado” Sempre vai existir um usuário whale que vai espremer ao máximo qualquer oferta “ilimitada” Ex.: um cliente pagando apenas $250/mês e consumindo uma quantidade absurda de recursos Se a unidade que você oferece de forma ilimitada gera custo, você inevitavelmente sai no prejuízo Esse conselho também vale para lifetime deals se você promete uso vitalício por $100, pode acabar recebendo pedidos de novas funcionalidades por anos e, se usou um marketplace de terceiros, talvez receba só 30% desse valor No fim, isso atrai menos clientes reais e mais pessoas atrás de ganho de curto prazo, que ainda ficam presas por muito tempo Recursos pagos precisam de rate limit Se você usa APIs pagas, como IA, SMS ou envio de e-mail, limitar o uso é obrigatório “Mas se o cliente paga, ele não deveria poder usar sem limite?” → pode haver exceções, mas na maioria dos casos isso cria risco de explosão de custos ou de receber rótulo de spam do fornecedor Exemplo real: um servidor hospedando centenas de sites WordPress teve erro por falta de RAM como resultado, milhares de alertas por SMS foram enviados automaticamente, gerando um custo alto Se um cliente realmente precisa de uso em grande escala, ele vai entrar em contato diretamente Não tente explicar tudo em uma única página “Se você tenta dizer tudo para todo mundo, acaba não dizendo nada para ninguém” Isso se aplica especialmente ao copywriting de landing pages À medida que o OnlineOrNot ganhava funcionalidades, mais explicações foram sendo adicionadas à landing page principal, e isso deixou a mensagem confusa e reduziu a compreensão dos usuários ex.: notificações no Slack foram a segunda funcionalidade criada, mas muita gente nem sabia que ela existia Solução: criar landing pages separadas para cada funcionalidade Principal: https://onlineornot.com/ Monitoramento de uptime: https://onlineornot.com/website-monitoring Monitoramento de API: https://onlineornot.com/api-monitoring Status pages: https://onlineornot.com/status-pages Monitoramento de cron jobs: https://onlineornot.com/cron-job-monitoring Em cada uma delas, é possível usar espaço suficiente para explicar a funcionalidade com clareza Aumentar tráfego é difícil; melhorar conversão dá para fazer agora Chamar atenção na internet é um jogo de longo prazo e muito lento mesmo com marketing de conteúdo de qualidade e consistência, pode levar meses ou anos para sair de 1 ou 2 visitantes e chegar a centenas Não é fácil aumentar o tráfego em si Em compensação, é possível mudar imediatamente o comportamento de quem já chegou por exemplo, adicionar login com OAuth ao formulário de cadastro é uma melhoria que você pode aplicar hoje para elevar a conversão Concorrentes não são tão importantes assim O motivo de quase não haver menção a concorrentes neste texto é que, na prática, eles não têm um impacto tão grande Claro, você precisa ter o básico para entrar no radar dos clientes, mas o verdadeiro concorrente é o usuário nem saber que o seu produto existe Mais do que funcionalidades, os principais fatores competitivos são visibilidade e acessibilidade

(maxrozen.com)

74 pontos por xguru 2025-04-14 | 4 comentários | Compartilhar no WhatsApp

O OnlineOrNot, criado por Max Rozen, começou em um mercado onde já existiam mais de 200 produtos concorrentes
No início, muitos produtos eram difíceis de usar, e depois inúmeros concorrentes surgiram e desapareceram rapidamente
Alguns concorrentes receberam investimento de VC e foram adquiridos por grandes empresas, e a experiência do usuário foi piorando cada vez mais
O OnlineOrNot tem como objetivo ser um negócio sustentável no longo prazo, financiado com recursos próprios
O autor ainda mantém um emprego em tempo integral enquanto continua desenvolvendo seu SaaS de forma consistente
Ele escreve uma retrospectiva todos os anos, e algumas lições aprendidas no passado acabaram se mostrando erradas com o tempo

Princípios que não mudaram

Ao longo dos anos, aprendi muita coisa sobre administrar um negócio, mas ainda existem princípios centrais que continuam os mesmos

Investir 2 horas em cada dia útil

Mesmo antes de começar o OnlineOrNot, eu já dedicava 2 horas todas as manhãs, antes do trabalho, a projetos pessoais
Usei esse tempo para concluir centenas de textos, um livro e vários projetos de software
Mais importante do que quanto você investe por dia é o esforço consistente, todos os dias
Para garantir esse tempo, eu acordava 2 horas mais cedo e ajustava minha rotina

Não fazer outros side projects

Como diz o ditado, “quem persegue dois coelhos não pega nenhum”, então foquei em uma coisa só
Algumas pessoas excepcionais conseguem fazer vários projetos darem certo, mas eu reconheço que não sou assim
Considerei que o trecho de $0 até $500 de MRR é o mais difícil e que não vale a pena repeti-lo várias vezes
Preferi focar em um modelo que já funciona, e escolhi meu marketing com a mesma lógica

A prioridade é resolver a dor do cliente

Quando um usuário se cadastra, envio um e-mail automático perguntando: “Por que você se cadastrou?”
Leio todos os e-mails e respondo pessoalmente, e isso se tornou a principal fonte de insights para melhorar o produto
Entender o que incomoda os usuários e realmente resolver isso

Repetir e melhorar com persistência

Se eu não consigo colocar algo em produção em até 2 horas, reduzo o escopo e publico primeiro uma versão menor
Nem sempre dá para acertar exatamente as 2 horas, mas prefiro lançar rapidamente uma versão inicial e expandir depois
Se eu tento construir tudo antes de publicar, acabo perdendo motivação e foco
Concluir funcionalidades gradualmente por trás de feature flags é muito mais eficaz

Lições aprendidas

Ler poucos livros e começar a fazer logo

No começo, li dezenas de livros de negócios para cometer menos erros
Mas no fim percebi que aprender errando na prática é o jeito mais eficaz
Ex.: apareceu na capa do Hacker News e recebeu 6.000 visitas, mas só um número de um dígito chegou de fato até o app
Só no formulário de cadastro havia 75% de abandono → adicionar uma única opção de login com OAuth reduziu isso para 50%
Se eu começasse de novo, leria apenas estes três livros e partiria para a execução:
- The Mom Test (Rob Fitzpatrick)
- Deploy Empathy (Michele Hansen)
- Badass: Making Users Awesome (Kathy Sierra)
- Se precisar de mais detalhes práticos sobre operar um SaaS, eu também recomendaria The SaaS Playbook (Rob Walling)

Antes de vender assinatura, resolva o problema

O objetivo de um SaaS não é vender assinaturas, e sim resolver a dor do cliente
Em vez de pensar “se eu continuar criando funcionalidades, uma hora as pessoas vão usar”, é preciso mudar para “vamos resolver um problema irritante no trabalho do usuário”
SaaS é apenas uma forma de resolver problemas; também é possível fazer isso com screencasts, documentação, textos, livros, workshops, exemplos de código e outras abordagens

Construa pequeno e publique com frequência

Usuários sugerem ideias de funcionalidades, mas na prática quase nunca as usam
Quem está começando um SaaS tende a ficar tão feliz só por alguém conversar com ele que acaba implementando qualquer funcionalidade sem pensar muito
É melhor perguntar como a pessoa pretende usar aquilo e investigar como outros usuários resolvem o mesmo problema, e então
- implementar primeiro o mínimo necessário para ver a reação
Em vez de criar uma “funcionalidade floco de neve” usada por uma única pessoa, o importante é adotar uma abordagem estratégica para criar algo útil para muita gente
Dói remover uma funcionalidade em que você investiu algumas horas, mas é muito pior remover algo em que você investiu meses

Publique primeiro, pense em escala depois

A primeira versão do OnlineOrNot foi lançada rapidamente, sem otimização de arquitetura
Na prática, havia um bug que limitava o sistema a processar cerca de 100 checks, e
- quando algo dava errado, a UI mostrava apenas “Error!”, em um estado bastante inacabado
Mesmo assim, o autor preferiu ser criticado por uma UI incompleta a perder tempo criando funcionalidades desnecessárias
Como não há garantia de que milhares de usuários chegarão desde o primeiro dia, validar rápido era mais importante
Como solução temporária, ele fez upgrade do banco de dados para um plano superior e aumentou a capacidade de checks
Em poucas horas, refatorou a estrutura para suportar milhões de checks e também melhorou a tela de erro

Manter um programa de early access

No começo do desenvolvimento, a maioria dos usuários é relativamente tolerante com funcionalidades incompletas
Com o tempo, mais usuários passam a esperar um produto mais maduro
Para resolver isso, foi adicionada uma checkbox em cada conta de usuário para “participar do programa de early access”
- quem participa testa primeiro as funcionalidades mais novas, ainda não finalizadas, e fornece feedback
Isso funcionou bem como uma forma de equilibrar testes e feedback

Introduza o teste grátis o mais cedo possível

Hoje em dia é comum ouvir o conselho de que “plano gratuito é difícil demais de acertar, então melhor não fazer”
Mas no início, o plano gratuito ajudou bastante no boca a boca e na aquisição de usuários
O lado ruim é que, se o plano gratuito for muito diferente do pago, você precisa dar um jeito de as pessoas experimentarem as boas funcionalidades
Só 11 meses depois do início ele adicionou, no onboarding, a pergunta “você quer começar um teste grátis?”
- na prática, isso queria dizer:
  
  “Você quer testar as funcionalidades boas por 14 dias e decidir, ou prefere usar por meses uma versão limitada e acabar decepcionado?”
Depois, ele passou a testar oferecer teste grátis por padrão para todos os usuários e
- só esse experimento fez a taxa de crescimento mensal mais que dobrar
Conclusão:
- a mensagem “este é um serviço pago; para continuar usando as boas funcionalidades, precisamos das suas informações de pagamento”
- é muito mais eficaz para o negócio do que “este é um serviço gratuito; talvez fique pago se você usar bastante”

A documentação é parte do produto

Antigamente era comum ouvir que “desenvolvedores não leem documentação”, mas isso é completamente falso
Alguns dos clientes ideais elogiaram a documentação do OnlineOrNot, e isso levou o autor a investir nela com mais foco
Ele também construiu a documentação da API por conta própria para ter controle total da experiência do usuário
Observando o comportamento com ferramentas de product analytics, percebeu-se que:
1. Quando o usuário encontra um problema na UI, consulta a documentação e descobre a funcionalidade, ele continua usando o produto
2. Quando não encontra a informação que queria, ele não cria checks e vai embora
A qualidade da documentação está diretamente ligada à retenção de usuários

Projete o produto pensando no mobile

Ao contrário do que muita gente imagina, usuários de SaaS B2B também começam o trabalho pelo smartphone
Na prática, cerca de 50% de todos os usuários começam a usar o produto no mobile
- criam uma conta, registram algumas páginas e depois voltam no PC para conferir
Nos primeiros 6 meses, o produto não foi pensado para mobile, e a maioria dos usuários móveis abandonava
Depois de introduzir uma UI responsiva, a retenção de usuários mobile aumentou visivelmente

Pergunte diretamente ao usuário de onde ele veio

Uma das mudanças de código mais valiosas introduzidas no meio do primeiro ano foi
- adicionar no cadastro a pergunta “onde você conheceu o OnlineOrNot?”
Entender os canais de aquisição é extremamente importante para maximizar a eficiência do marketing
Existem dezenas de canais de marketing, mas os recursos para focar neles são limitados
Quando você identifica um canal que funciona bem, deve investir nele com foco e continuar até a resposta diminuir

Não usar ferramentas de analytics invasivas

No início, ele adotou rastreamento de sessão e ferramentas de análise de funil, como muitos produtos SaaS fazem, mas a efetividade foi baixa
Isso pode ser útil para equipes grandes, mas em serviços pequenos há um risco alto de interpretar resultados aleatórios como se significassem algo
Como fundador solo com apenas 2 horas livres todas as manhãs,
- foi mais eficiente ouvir diretamente um grupo de usuários de confiança (inner-circle) do que tentar analisar grandes volumes de dados
Ele recebia feedback mais intuitivo sobre funcionalidades e problemas e melhorava o produto com base nessa percepção

Converse com potenciais clientes mesmo sem ter a funcionalidade

Um dia, um CTO perguntou se o produto suportava uma determinada funcionalidade
A princípio, a ideia era encerrar com um “desculpe, ainda não temos isso”, mas
- por curiosidade, ele perguntou qual problema a empresa estava enfrentando e o que queria resolver
- também consultou usuários do inner-circle para saber se enfrentavam o mesmo problema
- e compartilhou ideias sobre como a funcionalidade poderia ser desenhada
Como resultado, esse CTO virou cliente pagante no dia seguinte e continua sendo cliente até hoje
E essa funcionalidade acabou sendo útil também para outros usuários

Gasta-se mais tempo construindo a plataforma do que resolvendo o problema

Nos últimos 4 anos, mais da metade do tempo de desenvolvimento foi gasto construindo a plataforma SaaS
- o objetivo original, “verificar se um site caiu e enviar alertas”, era só uma parte disso
Na prática, foram necessárias funcionalidades como:
- vários métodos de autenticação e gestão de usuários
- trial, onboarding
- tarefas repetitivas de banco de dados, gestão de equipes, cobrança de faturas
- e-mails de ciclo de vida, entre outras
Parte disso foi terceirizada com serviços como Stripe, mas
- muitas partes ainda precisaram ser feitas manualmente ou personalizadas, então acabaram sendo implementadas internamente

Precificação é realmente difícil

Se o preço for alto demais, as expectativas sobem ou a pessoa nem chega a se cadastrar
Se o preço for baixo demais, um usuário que paga $9 pode exigir que o app inteiro seja adaptado ao gosto dele
Solução:
- clientes difíceis recebem reembolso e seguem seu caminho
- o preço sobe, e você segue em frente
- especialmente no começo, conforme o produto ganha mais funcionalidades, experimentar continuamente com preços é essencial

Não fique obcecado só com MRR

MRR (Monthly Recurring Revenue) pode ser uma métrica inadequada para medir o desempenho do negócio
O que você fez semanas ou meses atrás impacta o MRR de agora, então é difícil medir efeitos em tempo real
Em alguns produtos SaaS, pode levar mais de 60 dias entre o cadastro e o pagamento real
Por isso, é preciso acompanhar outras métricas para entender se o produto está sendo usado de fato e se está entregando valor
- por exemplo: número de imagens geradas, formulários enviados e outros indicadores de sucesso baseados em comportamento

Nunca ofereça “ilimitado”

Sempre vai existir um usuário whale que vai espremer ao máximo qualquer oferta “ilimitada”
Ex.: um cliente pagando apenas $250/mês e consumindo uma quantidade absurda de recursos
Se a unidade que você oferece de forma ilimitada gera custo, você inevitavelmente sai no prejuízo
Esse conselho também vale para lifetime deals
- se você promete uso vitalício por $100, pode acabar recebendo pedidos de novas funcionalidades por anos
- e, se usou um marketplace de terceiros, talvez receba só 30% desse valor
No fim, isso atrai menos clientes reais e mais pessoas atrás de ganho de curto prazo, que ainda ficam presas por muito tempo

Recursos pagos precisam de rate limit

Se você usa APIs pagas, como IA, SMS ou envio de e-mail, limitar o uso é obrigatório
“Mas se o cliente paga, ele não deveria poder usar sem limite?” → pode haver exceções, mas
- na maioria dos casos isso cria risco de explosão de custos ou de receber rótulo de spam do fornecedor
Exemplo real:
- um servidor hospedando centenas de sites WordPress teve erro por falta de RAM
- como resultado, milhares de alertas por SMS foram enviados automaticamente, gerando um custo alto
Se um cliente realmente precisa de uso em grande escala, ele vai entrar em contato diretamente

Não tente explicar tudo em uma única página

“Se você tenta dizer tudo para todo mundo, acaba não dizendo nada para ninguém”

Isso se aplica especialmente ao copywriting de landing pages
À medida que o OnlineOrNot ganhava funcionalidades, mais explicações foram sendo adicionadas à landing page principal, e isso
- deixou a mensagem confusa e reduziu a compreensão dos usuários
- ex.: notificações no Slack foram a segunda funcionalidade criada, mas muita gente nem sabia que ela existia
Solução: criar landing pages separadas para cada funcionalidade
- Principal: https://onlineornot.com/
- Monitoramento de uptime: https://onlineornot.com/website-monitoring
- Monitoramento de API: https://onlineornot.com/api-monitoring
- Status pages: https://onlineornot.com/status-pages
- Monitoramento de cron jobs: https://onlineornot.com/cron-job-monitoring
Em cada uma delas, é possível usar espaço suficiente para explicar a funcionalidade com clareza

Aumentar tráfego é difícil; melhorar conversão dá para fazer agora

Chamar atenção na internet é um jogo de longo prazo e muito lento
- mesmo com marketing de conteúdo de qualidade e consistência, pode levar meses ou anos para sair de 1 ou 2 visitantes e chegar a centenas
Não é fácil aumentar o tráfego em si
Em compensação, é possível mudar imediatamente o comportamento de quem já chegou
- por exemplo, adicionar login com OAuth ao formulário de cadastro é uma melhoria que você pode aplicar hoje para elevar a conversão

Concorrentes não são tão importantes assim

O motivo de quase não haver menção a concorrentes neste texto é que, na prática, eles não têm um impacto tão grande
Claro, você precisa ter o básico para entrar no radar dos clientes, mas
- o verdadeiro concorrente é o usuário nem saber que o seu produto existe
Mais do que funcionalidades, os principais fatores competitivos são visibilidade e acessibilidade

4 comentários

thenewseason 2025-04-22

Do ponto de vista de quem opera um serviço, me identifico muito com muita coisa.
Eu também já desenvolvi reduzindo minhas horas de sono, mas minha saúde piorou..

O que me deixa curioso para quem passou por algo parecido é se esse tipo de investimento de tempo é possível enquanto se cria os filhos.
Como o tempo de deslocamento, o tempo passado na empresa e o tempo em casa com as crianças ocupam quase a maior parte do dia, para criar e operar um serviço assim acaba sendo necessário abrir mão de outra coisa, e espero que isso não seja a família ou a saúde..

tsboard 2025-04-15

É realmente um texto com muito a aprender. Usar 2 horas toda manhã para escrever e ainda concluir vários projetos...!

ethanhur 2025-04-14

É um texto com muito a aprender. No fim das contas, não podemos esquecer que SaaS também é um produto que o cliente contrata para resolver um problema.

xguru 2025-04-14

O que aprendi ao operar um SaaS sozinho por 1 ano
Já se passaram 3 anos, haha. Compare as mudanças no conteúdo enquanto lê!