SaaS para iniciantes: como avaliar se a ideia é tecnicamente e economicamente viável

Software por assinatura parece atraente pela receita recorrente, mas essa mesma recorrência cria obrigações permanentes: disponibilidade, suporte, backup, atualização de segurança e conformidade. Antes de construir, vale examinar se a ideia sustenta o custo de existir todos os meses. Este artigo trata dos pontos técnicos e econômicos que determinam essa viabilidade.

A pergunta econômica antes da técnica

Um SaaS sobrevive quando a receita por cliente ao longo do tempo supera, com folga, o custo de adquiri-lo e servi-lo. Três números respondem se isso é plausível: preço mensal, taxa de cancelamento e custo de aquisição.

Modelo simplificado (números ilustrativos)

Preço mensal por cliente ................... R$ 149
Cancelamento mensal (churn) ................ 4%
Permanência média = 1 / 0,04 ............... 25 meses
Receita por cliente na permanência ......... R$ 3.725

Custo de servir por cliente/mês ............ R$ 22 (infra + suporte)
Margem bruta por cliente na permanência .... R$ 3.175

Custo de aquisição (CAC) ................... R$ 900
Relação margem / CAC ....................... 3,5x  (referência comum: > 3x)
Meses para recuperar o CAC ................. ~7

Leitura: com churn de 8% ao mês, a permanência cai para 12,5 meses e a
relação vai a ~1,7x — o mesmo produto deixa de fechar a conta.

Multi-tenant: a decisão de arquitetura mais cara de reverter

Multi-tenancy define como os dados de clientes diferentes convivem no sistema. A escolha afeta custo, isolamento, complexidade de migração e capacidade de atender exigências de clientes maiores.

Para começar, o modelo compartilhado com identificador de tenant costuma ser suficiente, desde que o isolamento seja garantido no banco, e não apenas na aplicação. Filtrar por tenant somente no código é frágil: uma consulta esquecida vaza dados entre clientes.

-- Isolamento aplicado pelo banco com Row Level Security
create table projetos (
  id uuid primary key default gen_random_uuid(),
  tenant_id uuid not null,
  nome text not null,
  criado_em timestamptz not null default now()
);

create index on projetos (tenant_id, criado_em desc);

grant select, insert, update, delete on public.projetos to authenticated;
grant all on public.projetos to service_role;

alter table projetos enable row level security;

create policy "tenant isola projetos"
on projetos
for all
to authenticated
using (tenant_id = (auth.jwt() ->> 'tenant_id')::uuid)
with check (tenant_id = (auth.jwt() ->> 'tenant_id')::uuid);

Precificação: cobrar por quê?

A métrica de cobrança deve crescer junto com o valor percebido pelo cliente. Cobrar por assento em um produto usado por uma pessoa só limita a receita; cobrar por volume em um produto com uso irregular gera contas imprevisíveis e reclamação.

• Três planos costumam funcionar melhor do que cinco; excesso de opções trava a decisão.
• Ofereça plano anual com desconto: melhora o caixa e reduz cancelamento.
• Deixe claro o que acontece ao ultrapassar o limite do plano — bloqueio, cobrança extra ou aviso.
• Aumente preço para novos clientes e mantenha condições para os antigos por um período; isso reduz atrito.

O custo escondido de operar um SaaS

Cartão recusado é uma causa silenciosa de perda de receita. Implemente nova tentativa automática, aviso ao cliente e período de tolerância antes de suspender o acesso; recuperar uma assinatura ativa é muito mais barato do que conquistar um cliente novo.

Escopo do primeiro lançamento

O primeiro release precisa de um núcleo pequeno, mas completo do ponto de vista operacional. Faltar cobrança ou exportação de dados transforma cada cliente novo em trabalho manual.

1. Cadastro com verificação de e-mail e criação automática do tenant.
2. A funcionalidade central, funcionando de forma confiável, sem variações opcionais.
3. Cobrança recorrente integrada, com upgrade e cancelamento autônomos.
4. Exportação dos dados do cliente em formato aberto.
5. Registro de eventos e erros com identificação de tenant, para dar suporte sem adivinhação.
6. Página de status ou canal para comunicar indisponibilidade.

Sinais precoces de que a ideia se sustenta

• Clientes usam o produto sem lembrete, em intervalos compatíveis com a rotina que ele resolve.
• Pedidos de funcionalidade se concentram em torno do mesmo fluxo, indicando problema bem escolhido.
• Cancelamentos são por motivo externo (fechou a empresa) e não por "não vi valor".
• Alguém indica o produto espontaneamente para outra pessoa do mesmo segmento.
• O suporte discute uso avançado, não dúvidas básicas de navegação.

Conclusão

Viabilidade de SaaS é a interseção entre um problema recorrente e uma conta que fecha. Modele preço, churn e custo de aquisição antes de construir, escolha o modelo de multi-tenancy adequado ao seu estágio com isolamento garantido no banco, e trate cobrança, backup e suporte como parte do produto. A recorrência recompensa disciplina operacional muito mais do que quantidade de funcionalidades.

Perguntas frequentes

Fontes consultadas

• Stripe Docs — Billing e assinaturas
• PostgreSQL Docs — Row Security Policies
• ANPD — Direitos do titular na LGPD