De dev para dev: Por que criei o Triglit?
Eu não acordei um dia e decidi: "Vou construir uma plataforma de automação B2B". A verdade é que criei o Triglit porque eu estava desesperado.
Se você lidera um time de tecnologia ou desenvolve produtos SaaS, provavelmente já sentiu na pele o dilema que enfrentei. Esta não é uma história sobre "visão de mercado", é uma história sobre a minha sobrevivência técnica.
O cenário: Um CRM, um cliente VIP e um problema
Tudo começou quando eu estava construindo o Spark, um CRM de mensageria para WhatsApp e Instagram. O produto estava crescendo, e a demanda dos meus usuários por flexibilidade explodiu.
Lembro claramente de um caso específico. Um lojista virou para mim e disse:
"Eu preciso criar um fluxo simples: quando um cliente com a tag 'VIP' me chamar no WhatsApp, quero disparar uma mensagem específica e notificar meu gerente imediatamente."
Parece simples, certo? Mas, tecnicamente, aquilo virou o meu pesadelo.
Para atender a esse pedido, eu precisava entregar poder de automação na mão do usuário final. Ele precisava configurar gatilhos ("Novo contato"), condições ("Tem tag VIP?") e ações ("Notificar Gerente").
Nesse momento, bati de frente com um dilema da automação em SaaS.
Tentativa 1: "Puxadinho" com ferramentas No-Code
Minha primeira reação lógica foi olhar para o mercado. Ferramentas como n8n e Make são incríveis para uso interno. Pensei comigo mesmo: "Por que não embarcar isso no meu produto?"
Foi aí que a realidade bateu.
Tentar fazer white-label dessas ferramentas foi como alugar uma Ferrari, mas ser proibido de abrir o capô.
-
Falta de Contexto: Elas não falavam a língua do meu negócio. O n8n não sabia o que era uma "Tag VIP" no banco de dados do Spark.
-
Experiência Fragmentada: Meu usuário sentia que estava saindo do software e entrando em outro. Parecia um anexo, um "puxadinho", e não uma feature nativa que eu tinha desenhado.
-
Custo Proibitivo: Quando olhei as licenças para uso embedded, a conta simplesmente não fechava para o meu modelo de negócio.
Tentativa 2: Construir em casa
Frustrado com as ferramentas externas, fiz o que todo engenheiro orgulhoso faz: "Deixa que eu construo".
Desenvolvi um motor de automação proprietário dentro do Spark. No começo? Foi mágico. Meus clientes amaram a liberdade de criar fluxos que faziam sentido para o dia a dia deles.
Mas a felicidade não durou muito. Conforme escalávamos, aquela feature virou um monstro que eu precisava alimentar.
-
Observabilidade zero: Quando o fluxo de um cliente falhava, eu não sabia onde nem porquê. Precisava mergulhar em logs do servidor para diagnosticar um erro simples.
-
Dreno de roadmap: Meus melhores engenheiros não estavam mais criando novas features de CRM. Eles estavam presos mantendo filas de execução, gerenciando retries e corrigindo bugs no motor de automação que inventei.
-
Dívida técnica: A solução que me deu agilidade no início tinha se tornado uma âncora que segurava a evolução do meu produto principal.
A revelação: Automação tem que ser core, não anexo
Foi nesse momento de dor — preso entre ferramentas externas caras/limitadas e um sistema interno impossível de manter — que tive o estalo.
Percebi que a automação para SaaS não pode ser genérica. Ela precisa ser parte da alma do produto.
O usuário não quer "usar uma ferramenta de automação". Ele quer usar o meu software de forma mais inteligente. Ele quer "superpoderes" dentro do universo que ele já conhece.
Procurei no mercado uma solução que me oferecesse:
-
Integração Transparente: O usuário final nunca deve saber que existe um fornecedor terceiro ali.
-
Conexão Nativa: A ferramenta precisa se plugar diretamente na minha arquitetura de eventos e banco de dados.
-
Inspiração na Stripe/Clerk: Eu queria para automação o que a Stripe fez para pagamentos — uma infraestrutura robusta, invisível e focada no desenvolvedor.
Não encontrei. Então, decidi construir.
Nasce o Triglit
O Triglit nasceu dessa lacuna. Ele não é apenas "mais uma ferramenta de automação". Ele é a infraestrutura que eu gostaria de ter tido quando estava construindo o Spark.
Construí o Triglit sobre três pilares para resolver as dores que vivi:
1. Multi-tenancy real
Diferente de adaptar ferramentas de uso interno, fiz o Triglit para SaaS. Eu sei como é crítico separar os dados e fluxos do Cliente A do Cliente B com segurança e eficiência, então garanti isso na arquitetura base.
2. A "Língua" do seu produto
Com o Triglit, você define os nós e gatilhos. Se o seu sistema tem "Tags", "Pedidos" ou "Contratos", a automação vai falar exatamente esses termos. Para o seu cliente, é 100% nativo.
3. Devolvo seu tempo
Eu cuido da "chatice" complexa: a fila de eventos, a garantia de entrega, os logs granulares de erro, a escalabilidade. Você foca apenas na lógica de negócio que diferencia o seu produto.
Convite
Hoje, olho para trás e vejo que aquela frustração com o Spark foi necessária. Ela me forçou a criar algo que agora está ajudando outros CTOs e PMs a não passarem pelo mesmo sufoco.
Acredito que a próxima onda de produtos digitais não será sobre quem tem mais features estáticas, mas sobre quem dá mais liberdade para o usuário criar.
Se você está cansado de manter "Frankensteins" de integração ou de perder noites debugando webhooks, eu convido você a conhecer o Triglit.
Não cometa os mesmos erros que eu cometi. Vamos construir o futuro da sua automação juntos.