Executando verificação de segurança...
3

O dilema de criar dois SaaS ao mesmo tempo

Na iOHub, empresa onde sou co-fundador, sempre enfrentamos o mesmo problema: reuniões longas, cheias de desvios de assunto e decisões que acabavam se perdendo. Tentamos anotações manuais, ferramentas de transcrição, mas a sensação de desperdício de tempo continuava.

Essa dor constante me fez pensar: “Será que não existe uma forma melhor de conduzir reuniões?”
Foi aí que nasceu a ideia de um produto que eu gostaria de desenvolver: uma plataforma de reuniões online com IA no centro, para tirar o trabalho repetitivo do caminho e deixar o time focado apenas em uma coisa: tomar decisões.

Mas aí veio o dilema.
Eu já estava com um SaaS rodando na iOHub (o Bonchef). E se você acompanha a Y Combinator no Youtube você sabe que eles sempre repetem esse conselho: founders precisam ter foco, ou o risco é acabar não levando nenhum projeto pra frente. No papel, a escolha óbvia seria me dedicar apenas ao Bonchef. Mas, na prática, a dor que esse novo produto resolve é tão real que não consegui ignorar.

Hoje, sigo tocando os dois: Bonchef durante o dia na iOHub e esse novo projeto à noite. Talvez seja um erro, talvez não, mas com certeza será um aprendizado.

Finalizando

Queria ouvir da comunidade:

  • Vocês já tentaram tocar mais de um projeto ao mesmo tempo?
  • Até que ponto vale insistir em uma dor real, mesmo que isso signifique dividir energia?
Carregando publicação patrocinada...
2

Calma aí meu caro como diria o Yugi com Exódia: vamos por partes:


Primeiro ponto: SaaS não é um software, SaaS é uma empresa que gira em torno de um software, logo temos um primeiro ponto crítico aí, quantas empresas você tem?

Existem 2 formas de medir isso: Um SaaS grande divido em vários micro SaaS especializados da mesma área, podemos dizer que é uma só, se são cada uma com aspectos completamente diferentes... para cada nicho, uma no seu caso duas

Isso é importante porque num SaaS o que mais vai te custar tempo não é o S de "software" mas o S de "Service" é um erro comum que faz muita gente se desiludir (e se iludir com No-Code, Low-Code e agora com Vibe-Code)


Segundo ponto: Masoquistas existem, o que eu quero dizer com isso é que "identificar a dor" do seu público alvo não é o primeiro passo, sei que tudo que é coach na internet vende que é mas spoiler: não é, o real primeiro passo é "identificar uma dor que as pessoas querem ser curadas"


Terceiro ponto: Esse já é mais clássico, passando pelo filtro de achar uma dor "curável" é hora de ver se as pessoas estão dispostas a pagar o preço, sim, são assuntos diferentes, a pessoa pode querer curar uma dor de dente e ao mesmo tempo não estar disposta a arrancar o dente, e aqui não me refiro a dinheiro, mas a todo custo acessório, por exemplo, se o SaaS é uma IA que roda em nuvem, as pessoas estão dispostas a enviar dados confidenciais para treinamento e aperfeiçoamento? Mas vamos ser justos aqui IAs por definição são probabilistas, as pessoas estão dispostas a correr o risco? Se o SaaS é uma IA local, elas estão dispostas a bancar a infraestrutura?


Quarto ponto: Você da conta? Aqui não estou falando de manter 2 SaaS, mas de desenvolver o segundo, se no primeiro seu gasto era tempo e energia, aqui já envolve dinheiro, e porque? Ao se dedicar a mais uma solução, inevitavelmente você deixará as existentes e isso inevitavelmente diminuirá receita, ainda que não fique óbvio no gráfico, um erro muito comum que quase todo empresário iniciante comete é não tratar redução de crescimento para focar em áreas não correlatas como um tipo de gasto, em analise de viabilidade precisa entrar na conta, e no caso de SaaS, entra ainda a capacidade de entregar e manter o serviço


Quinto ponto: A sua percepção de preço x valor agregado bate com o dos cliente? A lendária frase no João Apolinário "produto tem preço, benefício tem valor" é muito distorcida por aí, por um motivo simples, ela tá simplificada, a completa é "produto tem percepção de preço, benefício percepção tem valor" o que muda é que agora é que fica evidente duas coisas:

  1. A necessidade de gerenciar expectativa, não adianta fazer seu cliente supervalorizar seu produto, isso só vai aumentar seu "churn" e vai por mim, você não quer isso
  2. Cuidado para você não supervalorizar a solução acreditando que ela entrega um valor que não entrega

Ok, se passou por todos os crivos é só gritar "obliterar" e você vence o jogo, mas se qualquer ponto falhar, é consideravelmente melhor seguir com o que você já tem, e desculpa a sinceridade mas saltar de um cardápio digital para isso:

uma plataforma de reuniões online com IA no centro, para tirar o trabalho repetitivo do caminho e deixar o time focado apenas em uma coisa: tomar decisões.

Parece muito arriscado, assumindo que consiga passar pelo crivo 2, como planeja ter uma estrutura privada pra isso, um único cliente exigiria custos absurdos com 4 a 5 dígitos/mês SE usar uma solução privada, consumir APIs além de aumentar o preço (citado no ponto 3) que o cliente teria que se dispor a pagar, aumentaria o custo operacional drenando sua margem de lucro

1

Muito bons os pontos que você trouxe, obrigado por compartilhar.
Alguns desses erros, inclusive, já cometi no meu primeiro SaaS.

No caso do Bonchef, que construí junto com meus dois sócios dentro da iOHub, estavamos tão focado em desenvolver rápido que deixamos de validar hipóteses importantes no início. Não criamos uma waitlist, não conversamos com potenciais clientes antes, e isso custou tempo e energia depois. Além disso, nosso MVP inicialmente era muito grande e demorou muito tempo para ser desenvolvido, o que quase chegou a nos falir.

A Amora nasce em um contexto diferente: é um projeto pessoal, paralelo, que estou tocando sozinho. E talvez justamente por carregar sozinho essa responsabilidade, estou tentando agir de outra forma.
Antes de me afundar em linhas de código sem saber onde vou parar, comecei pelo básico: criar uma página de waitlist (se interessar entre na waitlist), conversar com pessoas que vivem dores parecidas (ouvindo atentamente suas críticas ao projeto) e, aos poucos, construir um MVP só para validar se essa ideia faz sentido além do meu caso específico.

Sei que pular de um cardápio digital para uma plataforma de reuniões com IA é um salto enorme, e sim, arriscado. Mas dessa vez quero aprender errando pequeno: validando rápido, entendendo custos na prática e descobrindo se alguém estaria disposto a pagar por isso.

Ainda é cedo para dizer se a Amora vai se tornar algo real. Pode ser que não. Mas, de qualquer forma, sei que essa jornada já vai me render aprendizados que não tive no primeiro SaaS, e, com sorte, conexões valiosas com pessoas que compartilham das mesmas dores.

2

Meus 2 cents,

Uma das habilidades que caracterizam um empreendedor de sucesso eh a capacidade de delegar.

Voce pode fazer o operacional no inicio (alias, isso eh bem comum) - mas para qualquer projeto pegar tracao o ideal eh se cercar de pessoas que consigam tocar a operacao no dia-a-dia enquanto voce acompanha/corrige/determina as decisoes estrategicas/rumos que o projeto toma (p.ex. pivotar ao notar novas variaveis que influenciam o negocio).

Se voce toma para si toda a responsabilidade gerencial e operacional, provavelmente esta pavimentando uma estrada de sucesso para o burnout (e provavel fracasso do projeto).

Infelizmente os profissionais de tecnologia tem uma tendencia bem forte de "eu sou o projeto". Novamente, no inicio ate pode ser - mas se voce nao lancar as bases para que o projeto ande sozinho, fudeu.

Sobre as suas duvidas:

  1. Tocar mais de um projeto

Claro que vale - se voce respeitar os pontos colocados: voce dar o "start" mas poe o quanto antes alguem para fazer o dia-a-dia (marketing, vendas, suporte, pos-venda, desenvolvimento de funcionalidades conforme clareia a visao do ICP).

Tem gente que da conta de fazer tudo sozinho ? Sim, eh possivel - mas nao eh trivial.

  1. Vale a pena insistir ?

Se voce tem certeza do mercado a ser atendido - claro. Mas nao se trata de dividir energia, mas dividir responsabilidades. Eu sei que eh tentador criar um MVP de milhoes e faturar tudo sozinho, mas como diz o ditado: "Sozinho vou mais rápido, mas juntos vamos mais longe".

Nao esquece de compartilhar sobre como evoluiu teu negocio.

Saude e Sucesso !

1

Pra ser sincero, ainda não tenho certeza de nada kkkkk.
E é justamente por isso que estou compartilhando a Amora desde tão cedo em comunidades como essa, ouvindo críticas e feedbacks de quem já passou por situações parecidas.

No meu primeiro SaaS, o Bonchef, eu cometi o erro clássico de acreditar demais na minha própria visão e validar de menos. Resultado: gastei tempo e energia em coisas que não eram prioridade. Dessa vez, quero fazer diferente. Estou tentando reduzir o risco ao máximo: validando hipóteses rápido, conversando com potenciais usuários e buscando entender se essa dor realmente existe, e, mais importante, se alguém estaria disposto a pagar para resolvê-la.

Pode ser que no fim eu descubra que não vale a pena insistir. Mas se isso acontecer, prefiro que seja cedo, com aprendizados na bagagem, do que tarde demais.

Se quiser acompanhar esse processo (com acertos e tropeços), vou documentar tudo no meu Linkedin. 🚀

1

Eu não tenho experiência em ter dois projetos simultâneos, mas gostaria de dar minha opinião assim mesmo.
Você já colocou o foco como uma dificuldade que leva ao dilema, então já sabe que isso pode realmente ser uma pedra no sapato. Por isso mesmo nem vou falar sobre isso, mas sobre outra coisa anterior: simplicidade.
Será mesmo que você precisa criar esse SaaS agora? Você tem um que já deve dar algum nível de dificuldade de manter diariamente. Será que não seria mais interessante olhar pra essa dor e tentar resolver de modo um pouco mais analógico? Por exemplo, ao invés de ter uma reunião demorada com todos os problemas aue você apontou, por que não fazer uma reunião de pauta única que seja breve e seja direcionada para a resolução e decisão? É bem interessante a sua ideia, isso eu não posso negar, mas eu não faria ambos ao mesmo tempo.
Uma alternativa também seria você se juntar com outra pessoa, assim você poderia dividir a responsabilidade e foco para esse outro e poderia caminhar ambas ideias caso não quisesse mesmo engavetar momentaneamente

1

Entendo muito bem o seu ponto, e acho que você tem razão em dizer que existem formas mais simples de atacar esse problema, seja ter uma pauta única, limitar o tempo das reuniões ou até usar outras ferramentas similares já existentes.

Sou desenvolvedor, então minha reação instintiva quase sempre é tentar automatizar tudo. E muitas vezes preciso lutar contra isso para não cair no “overengineering”. Mas, nesse caso específico, essa dor me acompanha há anos. Já tentei soluções analógicas, já tentei processos internos, e mesmo assim a frustração de sair de uma reunião com a sensação de que nada foi registrado ou que boa parte do tempo foi perdido continuava.

Eu também percebi que, mais do que resolver um problema do meu time, eu tinha vontade de criar algo inovador nesse espaço. Sempre admirei founders que se lançam para resolver dores reais, e no fundo eu queria viver esse processo também, mesmo sabendo do risco, mesmo sabendo que talvez exista um jeito mais simples.

Talvez eu esteja errado, talvez fosse melhor esperar, ou talvez realmente seja melhor ter apenas um projeto. Mas acredito que essa é justamente a beleza de estar construindo algo: a incerteza. Prefiro aprender errando com algo que acredito do que ficar me perguntando “e se?”.

0
1

Eu estou passando por algo semelhante: fundando uma empresa de SaaS, trabalhando como consultor em uma scale up e fazendo doutorado. É sofrido, mas, dá pra fazer. Mas você precisa:

  1. Entender de forma clara de qual o seu papel, o que vc precisa entregar de fato em cada projeto e qual o esforço necessário;
  2. Ativar mecanismos de otimização que te permitam reduzir o esforço diário (AI, automação de processos, delegação, etc);
  3. Alocar seu tempo de maneira inteligente e gerir isso rigorosamente.
  4. Não deixar de reservar tempo pra espairecer um pouco.

Falando parece lógico e fácil ... mas é para os fortes kkkkk

0
1

De maneira bem geral:
1 - Empresa de SaaS:
- Procuro concentrar as principais atividades da semana na segunda-feira
- Nos demais dias depois das 18h

2 - Consultoria: demais dias da semana em horario comercial, exceto periodo da manha nas quartas feiras.

3 - Doutorado: fazendo apenas 1 credito: Procuro sempre estudar o conteudo dado no mesmo dia, mas normalmente transborda para os finais de semana

4 - Mentalidade AI-First

1

Não crie nenhum se a ideia não for original e realmente boa. SaaS já é um modelo de distribuição entrando em declínio pois o modelo seat-based se tornou insustentavel devido ao paradigma que as IAs trouxeram, cobrança por consumo. Aliado a isso, a facilidade em criar sistemas pequenos com IA impactam diretamente o faturamento de sistemas simples. Hoje a ideia precisa ser boa e precisa procurar um dos quase inexistentes nichos especificos, com poucos concorrentes, pois se for pensar em ERP, CRM, Robô de Whats e coisas do genero, existem milhares de concorrentes muito longe na frente.

1
1

Depende o que você teráde diferencial, pois hoje tem o Google meet que ja exatamente isso, permite que voce gerencie sua agenda de reuniões com ia focada. Ela faz a transcrição, faz a notificação da ata a todos, avisa a todos aobre incio, e muito mais, e o grande problema é que é grátis.