Como criar um SaaS: plano, custos e erros

O que é um SaaS, em palavras simples

SaaS (do inglês software as a service, «software como serviço») é um serviço que as pessoas usam no navegador ou numa aplicação e que pagam por subscrição: ao mês ou ao ano. Não vende o programa uma única vez, vende acesso contínuo. Exemplos do dia a dia: contabilidade online, sistema de marcações, plataforma de envio de newsletters. O cliente não instala nada nem precisa de servidores; para si, a receita passa a ser regular.

É importante distinguir um SaaS de um site comum com área de cliente. O site fala do seu serviço; o SaaS é o próprio serviço: a pessoa entra, faz o trabalho dentro do sistema e paga pela possibilidade de o fazer. Por isso, um SaaS tem sempre quatro partes obrigatórias: login e áreas de utilizador, planos com pagamento, os primeiros passos do novo cliente e um painel do proprietário onde se vê quantos clientes e quanto dinheiro há.

Quando um SaaS é uma boa ideia

• Tem uma tarefa repetitiva pela qual as pessoas já pagam, em dinheiro ou em tempo: à mão, em folhas de cálculo, através de um prestador.
• Percebe quem é exatamente o cliente e o que o irrita nas soluções existentes.
• O produto pode ser vendido a muitos clientes sem adaptação individual a cada um.

Quando não precisa de um SaaS

Se quer automatizar processos apenas dentro da sua empresa, o que precisa não é de um SaaS, mas de um sistema interno ou de um CRM. Se o serviço é, no fundo, consultoria e cada cliente é único, ninguém pagará uma subscrição de software. Nesses casos, o mais honesto é começar por uma versão mínima do produto (MVP) ou decidir se precisa mesmo de um sistema de gestão próprio.

Como criar um SaaS: etapas da ideia aos primeiros clientes

Segue-se a ordem que funciona para a maioria dos serviços. É também a forma como conduzimos os projetos: o cliente vê oito passos claros e, por dentro, corre um ciclo completo de engenharia.

1. Descrever o cliente e o problema. Uma frase: «Para quem fazemos o quê e em vez de quê». Se a frase não sai, ainda é cedo para escrever código. Fale com cinco a dez clientes potenciais e pergunte como resolvem o problema hoje e quanto gastam com isso.
2. Escolher a primeira versão mínima. Só entra o que é indispensável para o cliente obter resultado. O resto vai para a lista «mais tarde». Explicámos em detalhe o que é um MVP no artigo MVP: o que é e quanto custa lançar.
3. Desenhar o mapa do produto. Que perfis existem (cliente, colaborador dele, você), que páginas e dados, o que se liga a quê, que serviços ligamos (pagamento, e-mail, verificação do cliente). Isto é a sessão de arquitetura, de que falamos mais abaixo.
4. Mostrar o design e montar a base. Login, áreas de utilizador, perfis, administração, e-mails. Qualquer serviço precisa disto, por isso esta parte já a temos pronta e não a escrevemos de raiz.
5. Acrescentar planos, pagamento e os primeiros passos do cliente. É aqui que o produto passa a ser um SaaS: a pessoa regista-se, escolhe um plano, paga e recebe acesso sem a sua intervenção.
6. Testar e lançar para os primeiros clientes. Testes, segurança, ecrãs de telemóvel, pagamentos e e-mails de teste. Lançamento para 5–20 clientes reais, e não para «toda a gente de uma vez».
7. Olhar para os dados e decidir. Quem chegou ao pagamento, quem saiu e porquê. Só depois decide o que desenvolver.

Não salte os passos 1–2. Os erros mais caros num SaaS não acontecem no código, mas no facto de a equipa construir um serviço que ninguém pediu. O site do serviço e a página de planos são mais simples de fazer à parte, como uma landing page, para começar a recolher pedidos antes de o produto estar pronto.

Quanto custa desenvolver um SaaS

Não é honesto indicar o preço exato de um SaaS antes de descrever o produto: depende do número de perfis, pagamentos, ligações a outros sistemas e de o serviço atender «empresas com os seus próprios espaços» ou pessoas individuais. Por isso, vendemos os sistemas complexos através de uma sessão de arquitetura de €3 500 (2–3 semanas). O resultado é o mapa do produto, o orçamento e o plano da primeira versão. O valor é descontado no projeto e o mapa fica consigo em qualquer caso, mesmo que decida fazer o produto sem nós.

Como se forma o preço connosco

O total desde €44 900 (base de €17 900 mais modo SaaS de €27 000, com planos e pagamento das empresas já incluídos) é uma referência para um serviço cujos clientes são empresas com equipas. Se os seus clientes forem pessoas individuais, o modo «muitas empresas» não é necessário e a base mais subscrições sai desde €24 800 (a plataforma e as subscrições juntam-se num só pacote «Subscrições e clube»). A diferença é grande, por isso a primeira pergunta da sessão é sempre a mesma: quem paga, uma pessoa ou uma empresa.

O que não está incluído no preço

O domínio e os serviços de terceiros são pagos por si diretamente; não aplicamos margem. No arranque, a infraestrutura pode custar €0: alojamento, base de dados e e-mail usam planos gratuitos. Mas têm limites: por exemplo, na base de dados gratuita o projeto «adormece» após uma semana sem atividade, e o serviço de e-mail limita o número de mensagens. Quando o serviço ultrapassar os limites, dizemos-lhe com antecedência que plano é necessário e quanto custa. A comissão do sistema de pagamentos é cobrada pelo próprio sistema.

Como comparar corretamente as propostas dos estúdios no seu país, leia no artigo como escolher um estúdio web sem se enganar: percebe logo quem só dá o preço depois de «falarmos numa chamada» e quem mostra o que está incluído.

Modelos de preços de SaaS: como ganhar dinheiro com subscrições

O modelo de preços é a regra pela qual o cliente paga. Tem de ser escolhido antes do desenvolvimento, porque dele dependem os planos, a faturação (o cálculo e a cobrança dos pagamentos) e até a estrutura dos dados. As principais opções:

• Subscrição fixa. Um plano, um preço por mês. É o mais fácil de explicar e de lançar. Serve quando todos os clientes usam o serviço de forma semelhante.
• Planos por níveis. Por exemplo, «Início», «Equipa», «Empresa», com conjuntos diferentes de funções e limites. É o esquema mais comum: o cliente escolhe por si o que quer pagar.
• Pagamento por utilizador. O preço multiplica-se pelo número de colaboradores do cliente. A receita cresce com o cliente, mas os clientes podem poupar adicionando menos pessoas.
• Pagamento por utilização. Paga-se pelo volume: pedidos, e-mails, verificações, gigabytes. É justo para o cliente, mas a receita é mais difícil de prever.
• Combinação. Uma base por subscrição mais um suplemento pelo volume acima do limite.

Como escolher o modelo

Pergunte a si próprio pelo que o cliente está realmente disposto a pagar e o que cresce nele quando cresce o benefício. Se o benefício depende do número de colaboradores, cobre por utilizador. Se depende do número de operações, cobre por utilização. Se não for claro, comece com dois ou três planos e uma verificação: qual deles é o mais escolhido. Numa faturação bem feita, é possível alterar os planos sem refazer o serviço.

Calcule a receita mês a mês

A calculadora abaixo mostra como se forma a receita por subscrição (MRR, receita mensal recorrente): quantos clientes angaria por mês, quantos saem e quando o serviço recupera o investimento no desenvolvimento. Os números são pressupostos seus, não uma previsão: use o que aprendeu nas conversas com clientes. O erro mais frequente está na taxa de saída: mesmo uma pequena percentagem de clientes a sair por mês adia de forma notória o retorno do investimento.

De que é feito um SaaS: o que tem de existir desde o primeiro dia

Há coisas que são baratas de prever no início e muito caras de refazer depois. Não se trata de sofisticação, mas de alicerces.

Separação dos dados dos clientes

Se os seus clientes são empresas, um único serviço atende muitos e os dados de cada um têm de estar isolados. Chama-se a isto arquitetura multi-inquilino (tenant significa «inquilino», isto é, um cliente-empresa). Em palavras simples: cada um vê apenas o que é seu. Na nossa stack, resolve-se com regras na base de dados (RLS) e prevê-se desde o primeiro dia. O isolamento de clientes é um dos temas centrais do guia «Well-Architected» da Amazon Web Services para SaaS (ligação na lista de fontes, no fim): é uma tarefa de arquitetura própria, e não um efeito secundário do login.

Faturação

Planos, cobranças automáticas, faturas, códigos promocionais, o que acontece em caso de falta de pagamento. O sistema de pagamentos trata de receber o dinheiro, mas a lógica de «que plano, o que está disponível, quando renovar» tem de ser construída no produto. O contrato com o sistema de pagamentos é celebrado por si; nós configuramos a integração.

Os primeiros passos do novo cliente

O onboarding (a introdução ao serviço) decide se a pessoa se torna um cliente pagante. Um caminho curto entre o registo e o primeiro resultado vale mais do que dez funções adicionais.

Painel do proprietário

Quantos clientes, quem paga, quem saiu, quanto dinheiro por mês. Sem isto, gere o serviço às cegas. Para os cálculos, vai precisar precisamente da informação que introduz na calculadora acima.

Segurança e e-mails

Proteção dos formulários contra spam, autenticação de dois fatores para a sua equipa, cópias de segurança da base de dados, e-mails enviados a partir do seu domínio. É o padrão, não uma opção.

Módulos em vez de refazer: como fazer crescer o SaaS por partes

O principal erro ao encomendar um SaaS é tentar logo fazer «como os grandes». O orçamento vai para funções por validar e o lançamento adia-se por um ano. O esquema certo é outro: base mais módulos. Primeiro lança-se o núcleo, que resolve o problema principal, e as novas capacidades ligam-se como módulos separados quando os clientes mostram que são necessárias.

Em termos de dinheiro, é assim. Aplicação móvel, formação, clube e comunidade, níveis, programa de parceiros, administração avançada: cada módulo tem o seu preço e prazo. Compra apenas o que precisa agora. Se ligar três módulos ou mais, aplicamos um desconto de 10% sobre tudo. Não paga pelo que não usa e não refaz a base quando o produto cresce.

Porque é mais barato do que reescrever

Quando a base é feita com folga (perfis, permissões, gestão de clientes, pagamento, e-mails), um novo módulo liga-se a ela como uma peça de construção. Se, pelo contrário, se fez primeiro um «pequeno site para um único cenário», ao crescer é preciso refazer os dados, o login e as permissões: na prática, é um segundo projeto. Aplicámos esta abordagem em projetos numa plataforma de cursos, subscrições e clube; os exemplos estão reunidos na secção de casos.

Sobre o mesmo princípio aplicado a sites, leia o artigo construtor ou desenvolvimento à medida. E se planeia uma versão móvel, veja quanto custa desenvolver uma aplicação e se a precisa logo: muitas vezes, basta no início uma versão web que abre bem no telemóvel.

Erros comuns ao criar um SaaS

• Fazer tudo de uma vez. Vinte funções em vez de uma principal. Solução: MVP e lista «mais tarde».
• Não falar com clientes antes de desenvolver. Constrói o que lhe agrada a si. Solução: dez conversas e pré-registos numa landing page.
• Não prever o pagamento. «Por agora é grátis, depois acrescentamos» acaba em retrabalho. Solução: planos e faturação na primeira versão, nem que seja um só plano.
• Ignorar a taxa de saída. Angariar clientes é caro, retê-los é mais barato. Solução: ver quem sai e porquê desde o primeiro mês.
• Não ser dono do produto. O código fica com o prestador, o domínio na conta dele. Solução: repositório, domínio e serviços registados em seu nome; nós trabalhamos por convite.
• Prometer prazos aos clientes antes de serem conhecidos. O prazo da primeira versão indica-se no plano depois da sessão de arquitetura, e não antes.
• Esquecer o marketing. Mesmo um ótimo serviço não se encontra sozinho. Preveja orçamento e tempo para promoção, por exemplo SEO: funciona ao longo de meses, não de dias.

Se não tem a certeza de estar pronto para desenvolver o seu produto, faça o quiz rápido «Está pronto para desenvolver o seu produto?»: 17 perguntas, uma análise pessoal, os primeiros passos e desconto no desenvolvimento.

O que escolher na sua situação

Conselhos concretos por cenário:

• Se só tem uma ideia e nenhum cliente. Não encomende desenvolvimento. Faça primeiro uma landing page com a descrição e um formulário de pré-registo, fale com clientes e só depois avance para a sessão de arquitetura.
• Se já tem os primeiros clientes a pagar manualmente (fatura, transferência). Serve-lhe a sessão de arquitetura de €3 500 e, depois, a base com subscrições. Já sabe pelo que pagam, e isso é o essencial.
• Se os clientes são empresas com equipas. Precisa do modo SaaS com separação de dados e planos por utilizador; conte com desde €44 900 e um prazo a partir de três meses.
• Se os clientes são pessoas individuais. Basta a base com subscrições: é bastante mais barato e poderá acrescentar o modo «empresas» mais tarde, como módulo.
• Se o orçamento é inferior a €20 000. Faça um site simples com formulário e atenda os primeiros clientes manualmente. Também é uma forma de testar a procura. Para uma primeira validação de preço e procura, serve também uma landing page com quiz.
• Se já tem uma ferramenta interna. Descreva-a na sessão: muitas vezes, pode transformar-se em produto sem ser reescrita de raiz.

Em todos os casos, faça o quiz de preparação: mostra os pontos fracos em negócio, equipa, mercado e orçamento e sugere os primeiros passos. A escolha do fornecedor para um projeto destes é um tema grande à parte; reunimos uma lista de verificação no artigo como escolher um estúdio web. A abordagem em qualquer país é a mesma: primeiro o mapa do produto, depois o desenvolvimento.

Não se esqueça da vertente jurídica: os termos de utilização, a política de privacidade e o tratamento de dados pessoais (RGPD para clientes da UE) devem ser revistos pelo seu advogado. Fornecemos modelos, mas não pareceres jurídicos.