O Sinalio começou com uma tarefa repetida no WhatsApp
Uma tarefa repetida nas conversas com clientes de parceiros deu origem ao Sinalio. Conto como foi nosso primeiro mês produtivo, do MVP à busca por quem queira experimentar.
Atualizado em
Antes de existir um widget, uma base de conhecimento ou um roadmap público, havia uma tarefa repetida nos grupos de WhatsApp dos SaaS de parceiros: voltar às conversas com clientes B2B, lembrar quem tinha pedido cada funcionalidade e avisar que ela finalmente estava em produção. Foi desse trabalho que surgiu a ideia do Sinalio.
No começo, eu pensava nos SaaS de alguns parceiros comerciais. Eles tinham clientes fazendo pedidos, desenvolvimento acontecendo e mudanças chegando ao produto. Depois da entrega, alguém ainda precisava ligar os pontos: encontrar a conversa, recuperar o pedido e escrever algo como “olha, aquela funcionalidade que vocês queriam muito já está disponível”.
Eu não queria que toda entrega exigisse essa rodada manual pelos grupos. Às vezes o contato parecia forçado, feito só para transmitir uma informação que poderia estar acessível no próprio sistema. Há clientes e situações em que uma conversa próxima faz toda a diferença. Esse atendimento continua tendo valor. Mas nem toda novidade precisa virar uma mensagem individual.
Esse foi o ponto de partida do nosso primeiro mês produtivo. Não começamos com todas as partes que o Sinalio tem hoje. Elas foram aparecendo conforme uma pergunta puxava a próxima.
Primeiro, precisávamos contar o que tinha sido entregue
Desenvolvemos o Sinalio para facilitar a comunicação entre quem constrói o software e quem usa. A necessidade inicial era bastante direta: avisar que uma mudança tinha chegado ao sistema.
Incluímos o envio de e-mails aos clientes e criamos duas formas de apresentar as novidades. Uma fica dentro do produto, por meio do widget. A outra é uma página pública do Sinalio, para a qual o próprio sistema pode direcionar as pessoas.
Isso dava um lugar à informação que antes dependia de alguém reencontrar a conversa certa. A pessoa poderia descobrir a entrega enquanto usava o produto ou consultar a página de novidades. O contato humano continuava disponível quando a situação pedia mais contexto, uma explicação ou uma conversa de verdade.
Então veio uma pergunta que o anúncio, sozinho, não respondia: “E agora? Será que o pessoal gostou?”
Cada entrega deixou outra pergunta aberta
Foi assim que a coleta de feedback entrou no produto. Já tínhamos uma forma de comunicar a mudança. Precisávamos também de um caminho para ouvir quem tinha usado aquilo.
Depois apareceu a documentação. Uma novidade pode avisar que determinada funcionalidade existe, mas nem sempre consegue explicar seu funcionamento com a precisão necessária. Pensamos que, se estávamos entregando recursos, deveríamos oferecer também uma forma de documentar como usá-los. Daí surgiu a base de conhecimento.
O roadmap público veio de outra pergunta recorrente. Alguns usuários dos SaaS atendidos pelos nossos clientes queriam saber o que aconteceria com os pedidos que ainda não tinham sido entregues: “E aquela outra funcionalidade? Vai sair ou não vai dar?”
Havia uma diferença importante entre contar o que já estava pronto e dar visibilidade ao que ainda estava sendo considerado. Essa pergunta levou à ideia do roadmap.
Vendo a sequência agora, consigo contar a evolução do produto pelas conversas que a provocaram: precisamos avisar que entregamos; precisamos ouvir a reação; precisamos explicar como funciona; precisamos dar visibilidade aos próximos passos. Foi assim que chegamos ao MVP dessas funcionalidades ao longo deste mês de trabalho.
Também tivemos que pensar em como apresentar tudo isso sem sobrecarregar quem estava começando. Hoje, os recursos estão disponíveis em todos os planos, e cada equipe escolhe quais quer usar naquele momento. A navegação dos recursos ainda não utilizados não fica aparecendo. Quem precisa começar só com novidades não tem que apresentar todas as outras áreas de uma vez.
Eu achei que trazer pessoas para o site seria mais fácil
Depois de entregar esse MVP, começamos a explorar formas de fazer o Sinalio ser conhecido. Vieram o blog, Instagram, X, LinkedIn e os cadastros no TrustMRR e no ListaMRR.
Estamos trabalhando no SEO para que founders de diferentes países consigam encontrar o produto. Essa é uma parte do trabalho que ainda está em construção, e minha expectativa inicial foi otimista demais: eu pensava que atrair pessoas para o site seria muito mais fácil.
Está sendo um desafio diário, com avanços aos poucos. O trabalho mais direto tem acontecido quando vou até empresas e apresento a ferramenta: “Tenho um produto que faz isso e aquilo. Vocês gostariam de testar para ver se ajuda na comunicação com seus clientes?”
Essa abordagem exige explicar o Sinalio para uma empresa concreta, no contexto dela. É um trabalho diferente de preparar uma página ou publicar um artigo. Ainda estamos fazendo os dois: tentando ser encontrados e procurando ativamente quem pode se beneficiar do que construímos.
Quero trazer essa parte para o blog também. Até aqui, publicamos bastante sobre feedback, novidades e o uso dessas ferramentas. Agora, quero compartilhar a experiência de construir o próprio Sinalio, inclusive quando o trabalho não rende uma nova funcionalidade para mostrar.
Os agentes entraram no trabalho de escrever
Outra coisa que fez diferença neste primeiro mês foi o MCP, pelo qual integramos o Sinalio ao ChatGPT e ao Claude. No nosso uso, poder delegar a redação e depois revisar o texto foi essencial.
Conseguimos fornecer aos agentes o contexto das mudanças do código, vindo de ferramentas como Azure DevOps, GitHub, GitLab ou Bitbucket. Com esse material, eles podem ajudar a transformar o que foi desenvolvido em uma explicação para quem usa o sistema. O Sinalio entra como o canal para levar essa comunicação ao usuário.
A experiência tem sido muito boa para preparar textos a partir desse contexto. Eu reviso o resultado para conferir se ele diz o que realmente foi entregue e se a pessoa vai entender. É uma combinação que faz sentido no nosso trabalho: o agente ajuda a escrever, e nós decidimos o que está pronto para chegar ao usuário.
Um começo que quero mostrar de perto
Quero transformar o Sinalio em um projeto construído em público. Este texto é um começo: contar de onde veio a ideia, como o escopo cresceu e o que estamos encontrando ao tentar levar o produto para mais gente.
Já criei o perfil @mllrdev no X, e o Sinalio está no TrustMRR e no ListaMRR. Quero usar esses espaços e o blog para compartilhar as decisões e o trabalho por trás do produto.
Nossa ambição é fazer do Sinalio uma conexão cada vez mais completa entre desenvolvimento e comunicação. Até o fim de 2026, nossa meta é concluir integrações com as principais ferramentas de repositório de código, gestão de demandas e canais como Teams, Discord e Slack. Esse é o objetivo que estamos perseguindo para a próxima etapa do produto.
Queremos reunir essa conexão com duas escolhas que já fazem parte do Sinalio: recursos disponíveis em todos os planos e liberdade para ativar apenas o que a equipe precisa agora. Temos uma visão grande para o produto, sem exigir que cada cliente adote tudo de uma vez.
Ainda estou indo até empresas, apresentando o Sinalio e convidando pessoas a experimentar. Ao mesmo tempo, estamos construindo o que queremos que ele se torne. Quero mostrar esse caminho de perto: as entregas, as decisões e o trabalho para levar nossa ambição adiante.
