Quanto custa transformar um sistema interno em SaaS?

Depende muito de como o sistema foi construído, mas costuma ser um projeto comparável a construir uma parte relevante do sistema de novo, não um ajuste. Os itens mais caros são isolamento de dados por cliente, painel de administração, cobrança recorrente e onboarding automático. Peça o orçamento separado por esses blocos para poder priorizar.

É melhor um banco de dados por cliente ou um banco compartilhado?

Banco compartilhado com identificador de cliente em cada tabela é mais barato de operar e escala melhor em número de clientes. Banco por cliente isola melhor e facilita exportar ou apagar um cliente inteiro, mas o custo de manutenção cresce a cada novo contrato. Para começar, compartilhado costuma ser a escolha mais sensata.

Posso vender para poucos clientes antes de virar SaaS de verdade?

Pode, e muitas vezes é o caminho certo. Instalar o sistema para dois ou três clientes com contrato de licença valida se existe demanda antes do investimento em multi-tenant. O risco é criar versões diferentes para cada cliente, o que torna a unificação futura muito mais cara.

Quero transformar meu sistema em SaaS: o que muda

Transformar um sistema interno em SaaS muda três coisas ao mesmo tempo: como os dados são separados, como o cliente entra sem você e como você cobra. O software em si costuma ser a parte menor. O que encarece é tudo que existia implicitamente porque só a sua empresa usava.

O que existia implícito e agora precisa ser explícito

Num sistema interno, muita coisa funciona porque você está por perto. Alguém pediu acesso, você criou o usuário. Um dado ficou errado, alguém abriu o banco e ajustou. Só existe uma empresa, então todo registro pertence a ela por definição.

Em SaaS, cada uma dessas suposições vira funcionalidade. E cada funcionalidade tem custo de construção e de manutenção.

Sistema interno	O que precisa virar no SaaS
Todo dado pertence à sua empresa	Cada registro tem dono, e nenhuma consulta pode vazar entre clientes
Você cria usuário no banco	Cliente cria e remove os próprios usuários, com perfis
Todo mundo vê tudo	Permissões por perfil, configuráveis pelo cliente
Sem limite de uso	Planos com limites de usuários, registros, armazenamento ou volume
Contrato e boleto fora do sistema	Assinatura, cobrança recorrente, inadimplência e bloqueio automático
Você treina pessoalmente	Cadastro, primeiro acesso e primeiros passos guiados pelo próprio produto
Você abre o banco quando dá problema	Painel administrativo interno, logs por cliente, suporte sem acesso direto
Ajuste é só rodar um update	Atualização atinge todos os clientes no mesmo momento
Backup informal	Rotina testada, com restauração por cliente

Se metade dessa coluna da direita não existe hoje, o projeto é maior do que parece.

Isolamento de dados é o item inegociável

O erro mais grave possível em SaaS é um cliente enxergar dado de outro. Não existe recuperação de reputação depois disso. Por isso o isolamento não pode depender de o desenvolvedor lembrar de filtrar em cada consulta.

O que caracteriza isolamento bem-feito:

O identificador do cliente entra na consulta por um mecanismo central, não em cada tela
Existe teste automatizado que tenta acessar dado de outro cliente e falha
Arquivos enviados também são separados, não só as tabelas
Relatórios, exportações e integrações respeitam a mesma regra
Logs registram qual cliente e qual usuário fez cada ação relevante

Banco por cliente ou banco compartilhado

As duas estratégias funcionam. A escolha depende de quantos clientes você espera e de quão sensível é o dado.

Critério	Banco compartilhado com coluna de cliente	Banco por cliente
Custo de infraestrutura	Baixo, cresce devagar	Cresce a cada cliente
Complexidade de código	Precisa de disciplina no filtro	Filtro natural, menos risco de vazar
Atualização de estrutura	Uma vez, atinge todos	Uma vez por banco, precisa de orquestração
Exportar ou apagar um cliente	Trabalhoso, exige varredura	Simples, é um banco inteiro
Cliente grande atrapalhando os outros	Risco real de um cliente pesado degradar todos	Isolado por natureza
Bom para	Muitos clientes pequenos e médios	Poucos clientes grandes, dado sensível, exigência contratual

Existe um meio-termo comum: banco compartilhado para a maioria e banco dedicado para clientes que pagam por isso ou têm exigência de contrato. Só vale se o código for escrito desde o início prevendo os dois casos.

Planos, limites e cobrança recorrente

Plano não é só tabela de preços. Cada limite prometido precisa ser verificado pelo sistema, e cada verificação é código.

Perguntas que precisam de resposta antes de programar:

O que acontece quando o cliente ultrapassa o limite: bloqueia, avisa, cobra excedente?
Quem pode mudar de plano, e a mudança vale na hora ou no próximo ciclo?
Existe teste gratuito? Por quantos dias, e o que acontece com os dados no fim?
Como funciona o cancelamento, e por quanto tempo os dados ficam disponíveis depois?
O que acontece na inadimplência: bloqueio de acesso, modo somente leitura, prazo de tolerância?

Sobre cobrança, use um serviço de pagamento recorrente em vez de construir do zero. E lembre que emissão de nota fiscal, regime tributário do serviço e retenções têm implicação contábil real. Defina isso com um contador antes de anunciar preço, não depois.

Onboarding sem você na chamada

Enquanto cada cliente novo depender de uma reunião sua para começar a usar, você tem um serviço, não um produto. O onboarding é o que separa os dois.

O mínimo funcional:

Cadastro e primeiro acesso sem intervenção manual
Dados de exemplo ou assistente de configuração inicial
Importação das informações que o cliente já tem, normalmente em planilha
Um caminho claro até o primeiro resultado útil, que costuma ser a tela ou o relatório que motivou a compra
Central de ajuda e um canal de suporte com registro, não só WhatsApp pessoal

O que muda no seu negócio, e ninguém avisa

A parte técnica é previsível. A parte que surpreende empresários é a mudança na operação.

Atualização atinge todo mundo. Antes, você publicava e avisava três pessoas. Agora, um erro publicado às nove da manhã afeta todos os clientes ao mesmo tempo. Isso exige ambiente de testes, publicação controlada e capacidade de voltar atrás rápido.

Não dá mais para atender pedido específico. O cliente que paga bem pede um campo a mais na tela de pedido. Se você atende, criou uma versão diferente. Duas ou três dessas e a manutenção fica insustentável. A resposta madura é transformar o pedido em configuração opcional que serve para todos, ou recusar.

Suporte vira função, não favor. Com vinte clientes, dúvidas chegam todo dia. Sem canal registrado, prazo definido e alguém responsável, o suporte consome o tempo que deveria ser de desenvolvimento.

A receita muda de forma. Projeto entrega dinheiro em bloco. Assinatura entrega pouco por mês e demora a compensar o investimento. Faça essa conta antes, num cenário conservador de crescimento.

Sinais de que ainda não é hora

Nem todo sistema interno bom vira SaaS bom. Segure o projeto se:

O sistema resolve um processo muito particular da sua empresa, e você nunca viu outra empresa fazer igual
Nenhuma empresa de fora chegou a pedir para usar
Você ainda não conseguiu descrever em uma frase quem é o cliente e o que ele para de fazer ao adotar
O sistema atual só funciona porque você conhece os atalhos e as manias dele
Não existe orçamento para pelo menos um ano de manutenção depois do lançamento

Um teste barato antes de investir: tente vender para dois ou três clientes uma instalação separada do sistema atual, com contrato de licença e suporte. Se ninguém pagar, o SaaS também não seria comprado. Se pagarem, você aprende quais adaptações são realmente necessárias antes de escrever o multi-tenant.