O que ninguém te conta depois que seu SaaS está pronto
Lançar um SaaS muda o tipo de problema que você precisa resolver. O código continua importando, mas agora usuários reais, dados, suporte, infraestrutura e decisões que não existiam durante o desenvolvimento entram em cena.
Construir um SaaS geralmente tem um momento de chegada muito claro.
O produto funciona. O deploy passa. O domínio aponta para o lugar certo. O primeiro usuário consegue criar uma conta e, finalmente, existe algo real para colocar na frente das pessoas.
É tentador olhar para esse momento como o fim do projeto. Na prática, é quando o projeto muda de natureza.
Durante o desenvolvimento, a maioria das perguntas é sobre o que precisa ser construído. Depois do lançamento, as perguntas passam a ser sobre o que está acontecendo.
- Quem está usando?
- Onde eles estão abandonando?
- Por que aquele pagamento falhou?
- Por que esta página está lenta?
- Essa funcionalidade realmente precisava existir?
E talvez a mais importante: o que devemos fazer agora?
Martin Fowler escreveu extensivamente sobre essa mudança em suas notas sobre arquitetura evolutiva - a ideia de que sistemas devem ser projetados para mudar, não para durar para sempre como foram construídos inicialmente.
O primeiro usuário muda tudo
Há uma grande diferença entre fazer uma aplicação funcionar e operar um produto do qual outras pessoas dependem para realizar algo.
No ambiente de desenvolvimento, você conhece os dados, os fluxos e as limitações do sistema. Quando o produto chega ao mundo real, essa previsibilidade desaparece rapidamente.
O usuário não conhece a arquitetura. Ele não sabe que uma determinada ação depende de três APIs diferentes. Ele não sabe que aquele botão dispara um webhook. Ele simplesmente tenta fazer o que precisa fazer. Como Kent Beck diz: "faça funcionar, faça certo, faça rápido" - mas depois do lançamento, a ordem frequentemente se inverte.
E quando algo dá errado, a percepção é simples:
"Não funcionou."
Este é o momento em que detalhes técnicos que pareciam secundários começam a importar.
Uma ação aparentemente simples pode percorrer várias partes do sistema:
| Ação do usuário | O que acontece nos bastidores |
|---|---|
| Criar uma conta | Validação, autenticação, banco de dados e e-mail |
| Fazer login | Sessão, cookies, tokens e permissões |
| Fazer um pagamento | Checkout, gateway, webhook e assinatura |
| Enviar um arquivo | Upload, armazenamento, processamento e CDN |
| Alterar uma configuração | API, banco de dados, cache e sincronização |
| Abrir uma página | API, queries, cache e múltiplos componentes |
Nada disso precisa ser complexo para o usuário. Na verdade, quanto melhor o produto, menos ele deve perceber essa complexidade. Mas alguém precisa lidar com ela.
O software começa a te contar o que está realmente acontecendo
Antes do lançamento, você trabalha principalmente com hipóteses. Depois do lançamento, você começa a trabalhar com evidências.
Uma funcionalidade que parecia essencial pode ser pouco usada. Uma tela que parecia óbvia pode ter uma taxa de abandono enorme. Um fluxo que passou em todos os testes pode começar a gerar erros quando recebe dados que ninguém imaginou durante o desenvolvimento.
É por isso que colocar um produto em produção importa tanto. Você finalmente consegue observar o sistema nas condições para as quais ele foi construído.
| Fonte | O que revela |
|---|---|
| Analytics | O que as pessoas realmente fazem |
| Logs | O que aconteceu tecnicamente |
| Tickets de suporte | Onde as pessoas estão com dificuldade |
| Rastreamento de erros | Onde o sistema está falhando |
| Dados de pagamento | Onde a conversão está sendo perdida |
| Feedback dos usuários | O que os usuários consideram importante |
| Métricas de performance | Onde a experiência está degradando |
O ponto não é coletar tudo. É conseguir responder às perguntas certas quando elas surgirem. Ferramentas como Sentry, Datadog, ou até um logger Winston bem estruturado podem fazer toda a diferença. O SRE Book do Google chama isso de diferença entre monitoramento e observabilidade - monitoramento te diz que algo está errado, observabilidade te diz por quê.
O problema de um bug não é só o bug
Um erro em produção é inevitável. O que muda completamente a situação é saber o que aconteceu.
Imagine receber uma mensagem de um cliente às 10:17:
"Tentei finalizar a assinatura e não funcionou."
Sem informações adicionais, alguém precisa começar a investigar. Qual usuário? Qual plano? Qual requisição? Qual foi a resposta da API? O pagamento chegou ao gateway Stripe? O webhook foi recebido? O banco de dados registrou a assinatura?
Quando existe observabilidade, a investigação começa com dados. Quando não existe, começa com tentativa e erro. Essa diferença pode transformar uma investigação de poucos minutos em uma de poucas horas.
É por isso que logs, métricas e monitoramento não são coisas que existem apenas para grandes empresas. Eles fazem parte da operação de qualquer produto que tenha usuários dependendo dele.
Você não precisa começar com infraestrutura massiva. Mas precisa existir uma forma de descobrir o que aconteceu.
O banco de dados também muda de comportamento
Um sistema com cinquenta usuários consegue esconder muita coisa.
Uma query mal otimizada pode parecer perfeitamente aceitável. Uma tabela sem o índice certo pode não causar nenhum problema perceptível. Uma estratégia de armazenamento pode parecer barata. Até os dados começarem a crescer.
O problema é que o crescimento não acontece só quando uma empresa chega a milhões de usuários. Às vezes algumas funcionalidades específicas já são suficientes para criar um gargalo:
- Uma tabela
eventspode crescer 10x mais rápido que a tabelausers - Uma query de busca usada em todas as páginas pode se tornar crítica
- Um dashboard que roda múltiplos
JOINstoda vez que abre pode começar a consumir recursos demais
A wiki do PostgreSQL sobre otimização de performance é um bom ponto de partida. Ferramentas como pg_stat_statements ou pgHero conseguem revelar queries lentas antes dos usuários.
O código que funcionava bem no primeiro mês pode ser exatamente o mesmo código que começa a causar problemas no sexto. É por isso que a arquitetura não deve ser tratada como uma decisão definitiva tomada no início do projeto. Ela precisa conseguir acompanhar o produto.
E então aparece algo que quase ninguém planeja: operações
Existe uma versão do software que funciona. E existe uma versão do software que alguém consegue manter. Essas são coisas diferentes.
Um SaaS em produção precisa de respostas para perguntas que tipicamente não aparecem no primeiro wireframe:
| Pergunta | Por que importa |
|---|---|
| Como sabemos que algo caiu? | Para descobrir antes do cliente |
| Como investigamos um erro? | Para reduzir o tempo de diagnóstico |
| Como fazemos rollback? | Para limitar o impacto de um deploy |
| Como recuperamos dados? | Para sobreviver a falhas |
| Quanto custa a infra? | Para controlar margens |
| Quem recebe um alerta? | Para não depender de uma pessoa |
| Como lançamos uma nova versão? | Para reduzir risco |
| E se um serviço externo falhar? | Para evitar que uma dependência derrube tudo |
Não significa que todo SaaS precisa de SRE de nível empresarial desde o dia um. Significa que essas perguntas existem mesmo quando você ainda não está preparado para respondê-las. A palestra de Charity Majors sobre observabilidade para startups é uma das melhores introduções para pensar nisso cedo.
O primeiro mês ensina mais que os seis anteriores
Esta é talvez uma das partes mais interessantes de construir produtos.
Por meses, uma equipe pode debater se uma determinada funcionalidade deve existir. Depois do lançamento, os usuários podem responder essa pergunta em poucos dias.
Às vezes a resposta é positiva. Às vezes ninguém usa. Às vezes os usuários usam, mas de uma maneira completamente diferente da imaginada. E isso é valioso.
Porque o produto deixa de ser baseado apenas no que a equipe acredita que deve acontecer. Ele começa a ser guiado pelo que realmente acontece.
Esse ciclo não exige uma configuração sofisticada. Exige prestar atenção.
Construir é só o começo
Um SaaS que chega à produção não é um produto acabado. É um produto que finalmente tem as condições para evoluir com base na realidade.
O código continua importante. A arquitetura continua importando. O design continua fazendo diferença.
Mas agora existe algo mais: pessoas usando o produto todos os dias, gerando dados, encontrando casos extremos e mostrando o que a equipe não conseguia ver durante o desenvolvimento.
A melhor versão do produto não é a que foi planejada. É a que aprende com o que realmente acontece.
Sobre a Bricks Studios
Construímos plataformas, apps e produtos digitais da arquitetura à produção. Se você está planejando o lançamento de um SaaS ou precisa de uma equipe para levar seu produto ao próximo nível, entre em contato.
Fontes
- Martin Fowler - Building Evolutionary Architectures
- Kent Beck - Make It Work, Make It Right, Make It Fast
- Google - Site Reliability Engineering Book
- Charity Majors - Observability Is a Many-Splendored Thing
- PostgreSQL Wiki - Performance Optimization
- Percona - MySQL Performance Tuning
- Sentry - Application Monitoring Platform
- Datadog - Infrastructure Monitoring
- pgHero - Performance Dashboard for PostgreSQL
- Winston - Node.js Logging Library
- Stripe - Payment Infrastructure