Doze semanas do zero ao deploy de um SaaS multi-tenant — um sistema onde cada cliente opera no próprio ambiente, com dados isolados, dentro da mesma aplicação. Não foi sorte, e também não foi sem tropeço. Aqui vão as escolhas que aceleraram e os erros que evitamos.
As 3 escolhas que aceleraram
- Multi-tenant com isolamento no banco, desde o primeiro dia. Decidir cedo como os dados de cada cliente ficam separados evita reescrever metade do sistema depois. Tratamos isolamento como fundação, não como ajuste futuro.
- Autenticação e permissão resolvidas antes da primeira tela. Quem vê o quê é a espinha do produto. Deixar isso pro fim significa remendar cada página depois. Resolvido na base, todo o resto herda de graça.
- Um único modelo de dados, pensado pra crescer. Em vez de tabela por cliente, uma estrutura que escala com filtro por tenant. Menos código repetido, menos lugar pra bug se esconder.
Os 5 erros que evitamos
- Generalizar cedo demais. É tentador construir pro "qualquer caso". Construímos pro caso real que tínhamos na frente, e abstraímos só quando o segundo cliente mostrou o que de fato variava.
- Tela bonita sem fluxo. UX não é cor de botão — é o caminho até a tarefa concluída. Mapeamos o fluxo principal antes de pensar em estética.
- Adiar o deploy. Subir cedo, mesmo incompleto, expõe os problemas reais de produção enquanto ainda dá pra mudar barato.
- Ignorar o estado vazio. A primeira tela que o cliente vê é a vazia, sem dado nenhum. Tratar isso bem muda a primeira impressão inteira.
- Achar que performance é problema de depois. Algumas decisões de banco custam caro pra reverter. Pensar em volume desde cedo evita o retrabalho mais doloroso.
O que ficou de lição
Velocidade não vem de pular etapas. Vem de acertar a ordem delas.
Doze semanas funcionaram porque o que era fundação — dados, acesso, fluxo — foi resolvido primeiro. O que era ajuste ficou pro ajuste. Inverter essa ordem é o que faz projeto de três meses virar projeto de um ano.