Executando verificação de segurança...
-11
williants
3 min de leitura ·

Eu tentei fazer um SaaS pra barbearia. Acabei criando tudo, menos o próprio SaaS.

Eu tive uma ideia de SaaS pra barbearias. Sim, mais um SaaS de agenda, controle, financeiro, aquele combo clássico.

Eu como dev, estava super hypado nessa onda de SaaS.
Peguei meu tempo livre à noite, abri o VSCode, montei o projeto todo no detalhe.
Frontend em React, backend em Node.js, arquitetura limpa, domain, application, adapter.

E aí começou a parte amarga da história.

Antes de tocar na primeira linha de código que realmente resolvia o problema da barbearia, eu percebi que precisava montar todo o pedaço universal que todo SaaS precisa, mas que não tem nada a ver com o core do negócio.

Meu MVP “perfeito” acabou incluindo:

  • autenticação completa
  • autorização por papéis e permissões
  • cadastro de usuários, donos, barbeiros
  • integração com Stripe, plano mensal, anual, free trial
  • sincronização de assinatura
  • dashboard administrativo
  • acompanhamento de uso de features
  • métricas financeiras (MRR, LTV, churn…)

Ou seja:
eu tava fazendo de tudo, menos o produto da barbearia.

A barbearia em si?
O fluxo de agendamento?
O controle do dia a dia?
O que realmente faria diferença pra alguém?

Ficou pra depois. Sempre pra depois.
E o pior: eu não havia experiência de como implementar metade dessas coisas.

Como validar free trial de verdade?
Como sincronizar mudanças de plano no Stripe?
Como bloquear um usuário se o pagamento falha?
Como limitar feature por plano sem gambiarra?
Como fazer isso tudo funcionar num contexto multi-tenant?

Eu entrei naquele looping clássico do desenvolvedor:
“Só vou arrumar isso aqui e depois começo o core…”
“Só mais essa parte de auth…”
“Só terminar o painel admin…”

Quando acordei, tinham se passado uns 2 meses.
E o projeto continuava sem resolver nada da barbearia.

Como era um projeto tocado no tempo extra de noite, fim de semana, quando sobrava energia demorou ainda mais.
Eu sentia que estava sempre “começando”, nunca avançando.
Até que o desânimo venceu.
Simples assim.

Um MVP que eu queria que fosse “perfeito” acabou virando um MVP que nunca viu a luz do dia.

E aí veio a reflexão:

  • Todo SaaS tem autenticação.
  • Todo SaaS tem trial.
  • Todo SaaS tem plano.
  • Todo SaaS precisa validar uso e limites.
  • Todo SaaS tem regras repetidas, e todo dev implementa tudo do zero.

É muita energia gasta em coisas que ninguém vê, ninguém valoriza e que não é o core do negócio.

Foi aí que eu pensei:
“Por que cada dev precisa perder meses implementando a mesma coisa?”

A verdade é que a parte “chata” e repetitiva de um SaaS deveria vir pronta.

  • autenticação e autorização
  • multi-tenant
  • integração com Stripe/Pagar.me/MP
  • sincronização de planos com o usuario/empresa
  • limites de uso de features
  • métricas reais de SaaS (MRR, LTV, churn, etc.)

Imagina ligar isso tudo por API?
Conectar, configurar e partir direto pro core?

Sem gastar 2, 3, 6 meses reconstruindo o mesmo boilerplate pela milésima vez.

Essa é a ideia que estou explorando agora.
Nada fechado, nada definido, fase bem inicial mesmo, conversando com devs, entendendo se essa dor é só minha ou de mais gente.

Se isso também faz sentido pra você, ou se já passou por algo parecido, deixei um form pra coletar feedback e entender o cenário. Sem compromisso nenhum.

https://forms.gle/XTUaPmeNYRYLUh2g7

Carregando publicação patrocinada...
2
RenatoNogueira

Eu mesmo, passei horas em um SaaS para profissionais de educação física (personal), com avaliação, agendamento, criação de treinos e um monte de coisas que todo profissional precisa em uma só aplicação... Usando PHP+phpCake par organizar o MVC. Ainda somente na minha máquina.

1
1
ChaosEngineer

Pois é, estou trabalhando no meu software há aproximadamente dois anos. Tenho certeza de que o time-to-market do produto está muito longe do ideal, mas acabou fazendo sentido por conta das especificidades.

Mas, contribuindo com o tópico, essa parte do "boilerplate" de infraestrutura pode ser desafiadora de se automatizar.

Por exemplo:
Como essa API garantiria que meu produto consiga 100% de aderência às necessidades arquiteturais? Se eu estiver trabalhando com EDA, existiria acesso a webhooks, ou integração com eventstreaming/mensageria, etc? Como isso se integra à minha infraestrutura?

Ou então como que eu garanto que não vou perder performance ou estabilidade? Qual seria o SLA dessas APIs? 99,999% de uptime? Qualquer falha poderia invabilizar a operação de uma corporação inteira.

1
felpfsf

O problema é que vc pensou como dev e não como produto. É o problema que acaba com muitos MVPs, ele acaba ficando inchado de tantas features e vc não consegue fechar ele para começar a validar. Pq esse é o ponto do MVP, um produto com as mínimas funcionalidades, construído rápido para validar a ideia.

Digo isso pq apanho demais, mas passei a fazer mais POCs esse ano e desenvolvi esse pensamento.

De resto, boa sorte com seu SaSS, é bem promissor

1
devopsvanilla

AWS SaaS Boost
https://github.com/awslabs/aws-saas-boost

vai te ajudar em todos esses requisitos e também na infra.

Você terá que ter uma infraestrutura robusta, confiável e que possa ser otimizada nos custos.

Vários casos de sucesso e AWS dá créditos significativos para startups

Há outras soluções de código-aberto, mas tem a infraestrutura e pela sua descrição não é o que pretende ter que se dedicar agora.

https://devopsvanilla.guru
Meus contatos e portifólio estão lá se quiser bater um papo.

Não gosto de formulários. Não vou preencher rsrs, odeio formulários e filas de todo jeito, até para ganhar dinheir.

1
lage

Estou neste dilema, tenho a ideia mas sem tempo ai nunca começo. Travo so de pensar no tanto de coisa que tenho de fazer antes de chegar no core que realmente seria o problema resolvido.

1
rafaelf

O bom é inimigo do ótimo, vi e participei de projetos com muito potencial por sempre precisar adicionar aquela feature que vai fazer toda a diferença e que nao pode nascer sem. Nisso o tempo vai passando e se for algo de momento, o timing já era.

1
igorbenav

Fiz um produto parecido com o que você tá descrevendo, o FastroAI.

Te adianto que o mercado de boilerplates tá bem saturado, tem vários aí no mercado fazendo exatamente as mesmas coisas (autenticação, pagamentos etc pra SaaS), até alguns open source muito bons. Se você quer se diferenciar minimamente nisso, precisa pegar um nicho específico.

Se você não tem um público de desenvolvedores que já te acompanha, é mais difícil ainda. Com mais de 13 mil seguidores no linkedin, projetos open source com mais de 500 mil downloads e quase 4 mil estrelas no github eu vendi só 1500 dólares em 2 meses.

1
Spitale

Existem frameworks e bootstrap projects que já te entregam tudo isso pronto.

O problema é que cada dev quer desenvolver as coisas "do seu jeito", por isso vão pelo caminho de escrever tudo!

1
1
Deiv

Vai por mim, você não ta no caminho errado não. Um software estável e escalável inicia-se dessa maneira. Você não tá so fazendo um SaaS, mas sim um carro-chefe pro seu negócio.

Desenvolva esse projeto pensando em abrir seu próprio negócio, mano. Faça dele um B2B.

Eu tô criando um ERP em Java. Muita coisa que tô fazendo não usa APIs ou frameworks modernos, só quando necessário. Isso me permite aprender muito mais sobre o Java do que eu já sei, melhorando minha percepção de resolução de problemas e criação de soluções mais robustas. Tô na mesma fase na qual você travou, e tá sendo muito legal! Porque aos poucos eu vou vendo sobre os internos das coisas, sabe? Vou vendo as coisas ganharem forma.

O ERP vai ser baseado em segurança absoluta. Vou tentar implementar o que for preciso na questão de segurança e autenticação. O restante, o front e backend do clientes vai ser construído em cima dessa infraestrutura de segurança.

Criei um server de licenças DRM, no qual ele vai gerar licenças de uso de software, com dados específicos.
Montei todo um framework de serviços, contendo logging, segurança, redes...
O cliente é construído offline em cima desse sistema, fornecendo backup, cripto e descriptografia, autenticação, etc. O setor de segurança é bastante usado no entorno da rede, da comunicação com o servidor, porque a internet é o maior vetor de ataque que existe.
Tenho planos mensal, trimestral, semestral e anual, com descontos escalonados aplicados nos planos semestral e anual.
Além disso tenho pacotes de software (bundle), sendo eles adminOnly, all-in-one e admin+#op (uma licença de admin + X licenças de softwares operacionais)

Então assim, já montei minha estrutura. Se precisar de revisão eu vou lá e reviso, sabe?
Preparo os bastidores, o espetáculo, antes de apresentar ao público.

A parada é você ter visão de futuro. Eu tô fazendo meu ERP modular pra plugar a arquitetura dele em cada negócio (padaria, oficina, mini mercados...). Isso me permite expandir minha base de clientes.

Eu desejo abrir uma empresa e ter um produto desse porte, tentando ser competitivo no mercado. Acho que é por isso que não desanimo do processo interno, porque é ele que vai manter o negócio estável.
Tem que ter ambição, mano. A ambição, quando usada corretamente, te leva longe, expande sua mente, sabe?

Não desiste não. Essa dificuldade é o que vai manter seu sistema estável. Você fazendo isso, vai tá um passo a frente dos demais, que só pensam na grana.

E te falo mais, eu tô aprendendo sobre cysec pra fazer pentest e forensics no meu próprio projeto. Ou seja, eu ainda vou tentar violar minha própria arquitetura pra poder ver onde ela pode falhar pra que eu possa consertar kkk

É aquilo, se você não fizer hoje, alguém fará amanhã contra você. E independente do tamanho do seu negócio, você pode ter só 50, 100 clientes, mas ainda sim você tem dados. E isso é valioso e deve ser exaustivamente protegido.

Enfim maninho, espero que eu tenha agregado em algo aqui pra você. Boa sorte aí e vamos pra frente! 😃

1
0
williants
  • Autor
    Autor

Concordo contigo: frameworks como o Laravel realmente facilitam muito.
Autenticação, rotas, models, até uma camada de billing com o Cashier… tudo isso já ajuda bastante. Mas ainda assim não é 100% abstraído, principalmente quando falamos de SaaS real, com regras de negócio que todo SaaS precisa.Por exemplo:

Se o pagamento falhar no Stripe, o Laravel não persiste automaticamente no seu banco que aquela assinatura ficou “inativa” é apenas retornado via webhook. Ele também não bloqueia o acesso do usuário por você. Não tem sincronização automática entre “status no gateway” e “status dentro da sua regra de autorização”.

Em ambiente multi-tenant isso complica ainda mais — você precisa orquestrar empresas, usuários, permissões, planos, limites, upgrades/downgrades, etc. E além disso existe algo que nenhum framework entrega pronto:
limites de uso do plano.

Exemplo:
“Plano Premium pode usar a feature X 50 vezes por mês”.

Para isso você precisa:

  1. Criar uma tabela de uso da feature.
  2. Salvar cada evento de uso por usuario.
  3. Validar o uso antes de executar.
  4. Barrar se passar do limite.
  5. Sincronizar com o plano atual do usuário.
  6. Tratar upgrades/downgrades no meio do ciclo.
  7. Tratar trial e período proporcional.

Tudo isso é regra universal de SaaS, mas que cada dev acaba implementando do zero. A ideia que estou validando é justamente abstrair essa camada inteira:

gateway de pagamento (Stripe, Pagar.me, MP)
multi-tenant
autorização baseada no plano
limites de features
controle de uso automático
bloqueio automático quando falhar pagamento
webhooks tratados
dashboard financeiro e de uso
notificações automáticas quando está perto do limite (exemplo)

Assim o dev pode focar só no core do produto, não em toda a infraestrutura e regra repetida que não gera valor direto para o cliente final.

É quase como um “SaaS para criar SaaS”, mas com foco na camada mais chata, repetitiva e universal.

Se o Laravel já entrega 30%, a ideia é entregar os outros 70% que ninguém quer reinventar. Mas é claro: se pra você, que já tem experiência e desenvolve essa parte com rapidez, isso não é uma dor real, tudo bem também. De qualquer forma, se um dia precisar, estamos por aqui.

0
1