Você quer lançar um SaaS fintech em público, mas trava na primeira decisão: o que abrir, o que esconder e como atrair contribuidores sem virar suporte gratuito. A AbacatePay resolveu parte disso publicando um arquivo de documentação para modelos de linguagem e transformando cada pendência do front em issue no repositório. O resto do trabalho continua sendo código.
O que a live revelou sobre o SaaS fintech em público da AbacatePay
A live de junho de 2025 mostrou a AbacatePay, uma plataforma brasileira de pagamentos para desenvolvedores, iniciando o Abacatinho, seu chatbot de suporte de código aberto, enquanto respondia dúvidas de integração ao vivo. O modelo de SaaS fintech em público aparece menos como estratégia de marketing e mais como método de trabalho: desenho no Figma, código no editor, issues criadas no fim da sessão.
A empresa tinha cerca de seis meses de operação na data da transmissão. O apresentador descreve uma equipe fixa de seis pessoas e um grupo maior de colaboradores de código aberto que contribuíram com o projeto. Esse tamanho reduzido explica por que a decisão de abrir o código não veio de um departamento de estratégia, e sim da necessidade de escalar o suporte sem contratar.
O projeto transmitido era o front end de um chatbot, e não o núcleo de pagamentos. A distinção importa: a empresa abriu a interface do produto de suporte, manteve fora da live o banco de dados e a camada de cobrança. Quem quer copiar o modelo precisa definir esse limite antes de publicar o primeiro repositório.
A stack real por trás da AbacatePay
A AbacatePay usa TypeScript, Tailwind, Next.js no front end, Fastify e Node.js no back end, MongoDB como banco e BullMQ para filas, segundo a descrição feita pelo próprio apresentador durante a transmissão. A combinação prioriza velocidade de entrega sobre padronização corporativa.
O modelo adotado é o de monolito modular, citado na live como arquitetura defendida pela equipe. Em vez de distribuir serviços desde o primeiro dia, o time mantém um único deploy com módulos separados por domínio. Para uma fintech iniciante, isso reduz o custo operacional de observar logs e transações em vários sistemas ao mesmo tempo.
O front do Abacatinho nasceu em Next.js, o framework React para produção mantido pela Vercel, com componentes construídos sobre Radix UI e as diretrizes visuais do shadcn/ui. Durante a gravação, o apresentador apagou partes desse estilo e reescreveu a tela inicial com Tailwind puro, para deixar o layout mais próximo do Figma do designer.
O editor usado na transmissão é o Cursor, IDE baseada no VS Code com recursos de sugestão de código. A ferramenta aparece concluindo trechos de classes Tailwind e de componentes React, o que o apresentador chama de produtividade e não de substituição do trabalho de front end.
Documentação para modelos de linguagem: o diferencial que a live expôs
A AbacatePay mantém um endereço de documentação pensado para modelos de linguagem, que a equipe chama de llms.txt, com instruções para que assistentes de IA entendam como integrar o produto. Esse é o elemento de informação mais concreto da live para quem constrói SaaS fintech em público.
O arquivo descreve o guia como material para auxiliar modelos de linguagem e desenvolvedores a integrar com a API da empresa. Na prática, um modelo com busca na web pode ler o endereço e devolver o exemplo de criação de cobrança em Node sem que o usuário abra a documentação tradicional. O apresentador demonstra esse fluxo ao vivo em um navegador com IA integrada.
O mesmo raciocínio aparece no Abacatinho. O chatbot foi treinado com a documentação da empresa e responde dentro do Discord do produto quando alguém abre um ticket com perguntas como integrar a API em Node. A limitação é conhecida: nem todo cliente usa Discord, o que motivou a criação da versão web.
Como o chatbot foi treinado e por que ele vive dentro do Discord
O Abacatinho foi construído a partir da documentação interna da AbacatePay e de um ajuste fino feito com uma ferramenta de código aberto da comunidade de desenvolvedores, citada na live como desenvolvida por um colaborador. O método é mais simples do que parece: reunir o texto que já existe e torná-lo consultável.
O apresentador descreve a facilidade como consequência direta da qualidade da documentação existente. Uma empresa que não tem documentação organizada não consegue treinar um assistente confiável, porque o modelo vai completar lacunas com invenção. Esse é o ponto de estrangulamento real para qualquer SaaS fintech em público que queira repetir a ideia.
A escolha do Discord como primeiro canal tem lógica de custo. O produto já tinha comunidade ali, e o bot respondia dentro do fluxo em que o cliente abria ticket. Quando o volume de perguntas cresceu, a equipe passou a migrar o atendimento para um chat no site, aproveitando o mesmo material de treinamento.
O que separa um produto aberto de um core financeiro fechado
A live deixa claro que o acesso aberto ao código cobre o front end e a API do chatbot, não o gateway de pagamentos. O apresentador comenta, em tom de brincadeira, que uma fintech não pode ter nem 1% de código gerado por IA, o que sinaliza o nível de cautela com a parte regulada.
Abrir o código de uma ferramenta de suporte gera confiança e contribuição sem expor lógica de cobrança, antifraude ou conciliação. Quem planeja um SaaS fintech em público pode aplicar a mesma divisão: abrir a camada que se beneficia de contribuição externa e manter privado o que envolve dinheiro de terceiros.
O repositório ainda estava no começo durante a transmissão, sem README completo e com poucos componentes. O apresentador criou issues para orientar contribuições posteriores, o que transforma a abertura em convite concreto e não em vitrine vazia.
O caminho burocrático para criar um gateway de pagamento no Brasil
Criar um gateway de pagamento no Brasil exige mais do que conectar uma API: é preciso ter empresa constituída, relacionamento com provedores e acesso às interfaces dos bancos, segundo a resposta dada na live a quem perguntou como começar. O apresentador descreve o processo como predominantemente burocrático.
A experiência da própria empresa ilustra o custo evitado. Segundo o relato, a equipe não comprou uma solução de marca branca e construiu a parte técnica do zero, o que poupou alguns milhares de reais em licenciamento. O número não foi detalhado nem auditado, então serve como indicação de ordem de grandeza e não como orçamento.
A consequência prática para quem pensa em SaaS fintech em público é escolher com cuidado o que será construído internamente. Banco, antifraude e liquidação exigem parceiros e conformidade; interface, documentação e suporte podem ser abertos e iterados com a comunidade.
O que copiar da live no seu próprio projeto
A live sugere um roteiro reprodutível para transformar uma sessão de código em material útil: escrever a documentação antes do assistente, publicar um arquivo pensado para modelos de linguagem, abrir apenas o componente que se beneficia de contribuição e registrar o que falta em issues.
O caminho abaixo segue a ordem em que os artefatos apareceram na transmissão. Ele não exige equipe grande, mas exige disciplina para que a abertura não vire uma pasta vazia no GitHub.
- Documente a API em texto simples, com exemplos de chamada em pelo menos uma linguagem que seu público usa, antes de qualquer projeto de chatbot.
- Publique um arquivo de instruções para modelos de linguagem no domínio principal e teste você mesmo se um assistente consegue responder a uma pergunta básica com base nele.
- Escolha um componente isolado, como o front de suporte, e torne-o público com licença clara e README com instruções de execução.
- Converta cada pendência conhecida em issue pequena e específica, capaz de ser resolvida em uma sessão de trabalho.
- Grave a sessão inicial, mesmo que imperfeita, porque o vídeo se torna o tutorial que a documentação escrita não consegue reproduzir.
Comparando os caminhos de abertura de um SaaS fintech
Três formatos aparecem com frequência em equipes pequenas de software financeiro: construir tudo internamente, abrir o código de suporte e manter o núcleo fechado, ou terceirizar a camada regulada por meio de um provedor. Cada formato troca velocidade por controle em pontos diferentes.
A tabela abaixo resume as diferenças observadas na live e nos documentos públicos das soluções citadas. Ela não mede desempenho nem custo real, apenas o escopo de cada escolha.
| Caminho | O que fica sob seu controle | Esforço inicial | Risco principal |
|---|---|---|---|
| Gateway próprio | Infraestrutura, contrato com bancos, produto | Alto, com exigência de empresa e conformidade | Burocracia e custo de licenciamento |
| Suporte aberto com core fechado | Experiência do cliente e documentação | Médio | Expor informação sensível por descuido |
| Provedor terceirizado | Produto e integração | Baixo | Dependência de preço e roadmap do parceiro |
Referências externas de experiência de desenvolvedor citadas na live incluem Stripe, plataforma de pagamentos com forte documentação pública. A comparação serve para orientar escopo, não para afirmar qual modelo é superior em todos os contextos.
Perguntas frequentes
- O que é o Abacatinho da AbacatePay? É um chatbot de suporte construído com base na documentação da própria empresa, usado inicialmente dentro do Discord para responder dúvidas de integração. A versão web teve o código publicado como projeto aberto, com front em Next.js e uma API separada para receber contribuições.
- A live de junho de 2025 mostrou o gateway de pagamentos sendo aberto? Não. O material aberto é o front end do chatbot e a API correspondente, segundo o que foi transmitido. O núcleo de cobrança e a camada de banco de dados ficaram fora da sessão e não foram publicados.
- Qual é a stack usada pela AbacatePay segundo a própria equipe? A descrição feita na transmissão inclui TypeScript, Tailwind, Next.js, Fastify, Node.js, MongoDB e BullMQ. A arquitetura adotada é de monolito modular, com módulos separados dentro de um único deploy.
- Como um chatbot de suporte é treinado na prática? O caminho mostrado consiste em reunir a documentação existente, organizá-la em texto legível e usar esse material para orientar o modelo. A qualidade da documentação define o resultado, porque lacunas no texto viram respostas inventadas.
- Por que abrir só o atendimento e manter o core fechado? Porque o atendimento ganha com contribuição externa e não expõe lógica de dinheiro, enquanto a cobrança envolve conformidade, antifraude e conciliação. A separação reduz risco regulatório sem abandonar o modelo transparente.
- Um SaaS fintech em público precisa de uma equipe grande? Não. A operação citada na live tinha cerca de seis pessoas fixas e contava com colaboradores voluntários em projetos abertos. O gargalo maior é documentação consistente, não volume de pessoal.
- O que é um arquivo de documentação para modelos de linguagem? É um documento em texto simples, publicado no site da empresa, que explica como integrar o produto e serve de referência para assistentes de IA. Ele reduz a dependência de leitura completa da documentação tradicional por parte de quem está integrando.
Onde acompanhar esse tipo de discussão
Comunidades brasileiras de desenvolvimento discutem esse modelo em canais abertos, e criadores como Gustavo Dev Doido abordam TypeScript e arquitetura de aplicações em conteúdo próprio. A Crazystack Typescript aparece como referência de estudo para quem quer aprofundar a base de TypeScript antes de encarar um monolito modular.
Materiais da Crazystack e do Bootcamp do Dev Doido tratam da construção de aplicações de ponta a ponta, um complemento útil para quem acompanhou a live e quer implementar algo parecido. Vale separar o que é estudo de stack do que é decisão de negócio: nenhum curso resolve a burocracia de um gateway.
Transforme o que você já gravou em texto
A live da AbacatePay mostrou que o conhecimento de uma equipe costuma existir antes do artigo e antes do vídeo: está na documentação, nos tickets, nas respostas repetidas. O que falta é o formato que faça esse material circular fora do Discord e do chat de suporte.
Se você tem explicações, entrevistas ou aulas gravadas em vídeo no YouTube, esse conteúdo pode virar um artigo estruturado com o Skala Blog. O fluxo é direto: você cola a URL do vídeo, a transcrição é gerada e o texto é montado a partir dela, pronto para revisão.