Meu segundo SaaS começou com o código do primeiro: o que deu para reaproveitar e o que precisei reescrever

De onde veio a ideia

Quando reposicionei o Estoque Simples para almoxarifado, criei uma página para cada tipo de operação: clínicas, condomínios, escolas, obras e oficinas.

A página de oficinas trouxe uma conversa diferente das outras. Ninguém da oficina queria só saber quantas pastilhas de freio tinha na prateleira. Queriam saber para qual carro a peça foi, em qual ordem de serviço, e se o cliente já tinha aprovado o orçamento.

Estoque, para a oficina, é uma consequência. O centro do dia a dia é a ordem de serviço. Foi assim que nasceu o Oficina Simples: um sistema de gestão para oficinas mecânicas que começou, literalmente, como uma cópia do código do Estoque Simples.

O que veio pronto

Boa parte de um SaaS não tem nada a ver com o problema que ele resolve. Isso tudo veio de graça:

• Multi-tenant: cada oficina é uma empresa, e todo model de negócio é isolado por um escopo global. Ninguém enxerga dado de outra empresa, nem digitando a URL.
• Autenticação completa: verificação de e-mail, 2FA, troca de senha com confirmação e sessão protegida.
• Planos e cobrança recorrente: assinatura, troca de plano, webhook do gateway e o fluxo de teste grátis.
• LGPD: documentos legais versionados, aceite registrado, exportação de dados e canal para o titular.
• SEO e aquisição: landing compilada, páginas por público, sitemap, imagem de compartilhamento e domínio canônico.
• Modelo comercial: o mesmo desenho que já tinha validado. Teste de 14 dias com tudo, um plano grátis que funciona como piso e um Pro único.

Esse último ponto merece destaque. Quando o teste acaba ou um pagamento falha, a oficina cai para o grátis. Nunca é bloqueada. Essa regra custou semanas para ser desenhada no primeiro produto e no segundo veio em uma linha.

O que precisei reescrever

O domínio. E ele foi muito maior do que eu esperava.

A ordem de serviço é um processo, não um cadastro. Um produto no estoque tem quantidade e histórico. Uma OS tem estados: rascunho, orçamento enviado, aprovada, em execução, pronta, entregue. Cada transição dispara coisas diferentes: baixar peça, cobrar, avisar o cliente, calcular comissão.

O cliente final entrou no sistema. No Estoque Simples, só a equipe interna usava o painel. Na oficina, o dono do carro recebe o orçamento por um link, aprova pelo celular e acompanha o histórico do veículo num portal. São páginas públicas, acessadas por token, com limite de requisições e fora do índice do Google. Uma superfície de ataque que o primeiro produto simplesmente não tinha.

O fiscal virou obrigação. Almoxarifado interno não emite nota. Oficina emite nota de peça e de serviço, cada uma com regras próprias. Isso rendeu um módulo inteiro, e um post só para ele.

O custo que ninguém mostra: dois códigos

Fazer fork foi a decisão certa para começar rápido. Mas tem um custo que aparece já na primeira semana: toda correção na base comum precisa ser feita duas vezes.

Um exemplo concreto: implementei o redirecionamento para o domínio canônico no Estoque Simples. Dias depois, o mesmo middleware, com o mesmo teste, precisou ir para o Oficina Simples. Não é difícil, mas é fácil esquecer.

Considerei extrair a base para um pacote compartilhado e decidi não fazer agora. O motivo é simples: com dois produtos, ainda não sei o que é realmente comum e o que só parece comum. Abstrair cedo demais congela decisões que ainda vão mudar.

A regra que adotei:

• Dois produtos: fork, com uma lista viva das correções que precisam ser replicadas.
• Terceiro produto: aí sim, extrair o que os três usam do mesmo jeito.

O que eu faria igual de novo

1. Copiar a infraestrutura, não o domínio. Login, cobrança e LGPD são iguais em qualquer SaaS B2B. A forma como o cliente trabalha nunca é.
2. Manter os testes no fork. A suíte do primeiro produto pegou várias quebras quando comecei a mudar os models no segundo.
3. Reaproveitar o modelo comercial, mas validar de novo. O preço que faz sentido para um almoxarifado não é automaticamente o preço de uma oficina.

O segundo produto não saiu em metade do tempo do primeiro. Mas saiu sem refazer nenhuma das partes que eu já sabia fazer, e isso deixou toda a energia para a parte que importa: entender como uma oficina trabalha.