A venda que me ensinou a dizer não para o cliente

Durante muito tempo eu achei que ser um bom fornecedor significava tentar atender ao máximo aquilo que o cliente pedia.

Hoje penso diferente.

Algumas das melhores decisões que tomei em vendas nos últimos anos foram justamente aquelas em que tive coragem de dizer:

Se precisa ser dessa maneira, talvez a Alphacode não seja a empresa certa para fazer esse projeto.

Mas eu não aprendi isso em um livro de vendas. Aprendi errando.

Os primeiros sinais estavam na primeira reunião

No começo de 2020, recebemos um contato que me deixou particularmente animado.

Era uma rede de restaurantes que eu admirava muito. Gostava da marca, do posicionamento e, principalmente, da qualidade dos produtos. Eles estavam crescendo e queriam construir um aplicativo para melhorar a experiência dos clientes.

Para mim, havia ainda um componente estratégico importante. Pouco tempo antes, tínhamos conquistado nosso primeiro grande cliente de Food, depois de uma concorrência que durou praticamente todo o ano de 2018. Eu começava a enxergar naquele mercado uma oportunidade enorme para a Alphacode.

Quando essa segunda grande marca chegou espontaneamente até nós, pensei que talvez estivéssemos começando a construir alguma coisa ali.

E eu queria muito aquele projeto. Talvez até mais do que deveria.

O cliente já tinha estudado bastante o que havíamos desenvolvido anteriormente. Mas rapidamente percebi uma diferença importante entre os dois projetos.

No nosso primeiro grande projeto de Food, a conversa girava muito em torno do negócio. Precisávamos vender, colocar o delivery no ar e fazer aquilo funcionar.

Nesse novo projeto, desde as primeiras conversas, o foco era diferente. Falávamos muito sobre design, experiência, animações, transições de tela e detalhes visuais.

Não havia nada de errado nisso. Uma boa experiência é parte fundamental de qualquer produto digital.

O que começou a me incomodar foi perceber que estávamos discutindo tudo aquilo antes de termos uma conversa suficientemente profunda sobre a pergunta principal:

O que esse aplicativo precisa produzir para o negócio?

Mesmo assim, naquele momento eu não confrontei essa visão. Dei espaço ao cliente.

Quando o cliente começou a escolher a tecnologia

Na época, nós tínhamos bastante experiência utilizando Ionic. Não era a tecnologia mais sofisticada do mundo, mas conhecíamos profundamente aquela stack.

Sabíamos suas limitações, tínhamos equipe, projetos reais rodando e conseguíamos entregar com velocidade e custo competitivo.

O cliente, entretanto, não gostava de alguns aspectos da experiência que tinha visto em outros aplicativos desenvolvidos daquela maneira, principalmente animações e transições.

Por isso, colocou uma condição para avançarmos: o aplicativo deveria ser desenvolvido em Flutter.

Hoje Flutter é uma tecnologia absolutamente estabelecida no desenvolvimento mobile. Mas estou falando do começo de 2020.

Era uma tecnologia relativamente nova, com documentação ainda limitada em alguns pontos e um ecossistema muito menor. E havia outro detalhe ainda mais importante: a Alphacode nunca tinha desenvolvido um projeto em Flutter.

Eu sabia que estávamos saindo da nossa especialidade. E aceitei.

Por que eu aceitei?

Essa talvez seja a parte mais importante dessa história.

Não foi porque eu acreditasse tecnicamente que aquela era necessariamente a melhor decisão. Aceitei porque queria o cliente.

Eu queria crescer naquele segmento. Tínhamos conquistado nossa primeira grande rede de Food e aquela seria a segunda. Era uma marca que eu admirava. Para mim, naquele momento, conquistar aquele logo tinha um valor estratégico enorme.

Deixei a vontade de fechar a venda falar mais alto do que a nossa convicção técnica.

E pagamos o preço por isso.

O problema não foi apenas tecnológico

Logo começaram a aparecer dificuldades.

Encontrávamos obstáculos técnicos para os quais ainda havia pouca documentação. Coisas que nossa equipe resolveria rapidamente dentro de uma tecnologia que dominava exigiam investigação, tentativa e erro.

O projeto começou a se estender. E quanto mais ele se estendia, mais problemas apareciam. A estabilidade também sofreu.

Só que o efeito mais importante não aconteceu dentro do código. Aconteceu no negócio.

O cliente começou a perder confiança para colocar toda a força naquele novo canal. O aplicativo entrou em uma espécie de soft launch infinito. Estava lá, funcionava, mas nunca recebia toda a energia que um novo canal digital precisa para ganhar relevância.

E então apareceu um ciclo que, depois de tantos anos trabalhando com produtos digitais, aprendi a temer:

  • o cliente não colocava energia porque o canal ainda não vendia;
  • o canal não vendia porque o cliente não colocava energia;
  • quanto menos vendia, menor era a disposição para investir;
  • quanto menor era o investimento, menos chance o canal tinha de vender.

Apesar de termos desenvolvido e colocado aquele produto no mercado, eu nunca o considerei um case de sucesso da Alphacode.

Entregar software e gerar resultado são duas coisas muito diferentes.

O aprendizado apareceu no cliente seguinte

Algum tempo depois, estávamos negociando com outro grande grupo de restaurantes. Era uma oportunidade ainda maior.

Durante uma das reuniões, a gerente responsável pelo projeto colocou uma condição parecida. Ela queria que o aplicativo fosse desenvolvido em React Native.

A situação era curiosamente familiar: uma grande marca, um projeto que eu queria muito e uma tecnologia que, naquele momento, não fazia parte da especialidade da Alphacode.

Só que dessa vez eu tinha uma experiência anterior na bagagem.

Parei a reunião e disse, em essência:

Se a utilização de React Native for uma condição para o projeto, eu acho que não faz sentido vocês avançarem com a Alphacode.

Pode parecer estranho para um vendedor dizer isso. Eu estava diante de um cliente enorme e basicamente dizia que preferia perder o contrato a aceitar uma condição que não considerava adequada para nós.

O cliente não estava contratando a Alphacode para concordar com ele. Estava contratando nossa experiência.

Um especialista precisa saber dizer não

Existe uma tentação muito grande em vendas de tecnologia de responder sempre: “Sim, conseguimos fazer.”

  • Quer React Native? Fazemos.
  • Quer Flutter? Fazemos.
  • Quer determinada arquitetura? Fazemos.
  • Quer trabalhar daquela maneira? Fazemos.

No curto prazo, essa postura pode ajudar a fechar contratos. Mas existe uma diferença enorme entre ser uma empresa capaz de executar determinada tecnologia e ser realmente especialista naquilo que está propondo.

Quando um cliente contrata uma empresa especializada, ele não está comprando apenas horas de programação. Está comprando também os erros que aquela empresa já cometeu, os projetos que deram certo, os que deram errado, as decisões técnicas que já precisaram ser revistas e os problemas de produção enfrentados de madrugada.

Parte da responsabilidade de um especialista é justamente impedir que o cliente tome determinadas decisões, mesmo quando ele está convicto delas.

Isso não significa arrogância. Também não significa que o fornecedor sempre está certo. Significa ter coragem de colocar sua experiência na mesa, inclusive quando isso coloca a venda em risco.

Algumas vendas você precisa estar disposto a perder

Curiosamente, aquela conversa no projeto seguinte não fez com que perdêssemos o cliente. Aconteceu o contrário. Avançamos, e aquele grupo acabou se tornando um dos grandes clientes da história da Alphacode.

Mas o principal aprendizado não é que dizer não ajuda a vender. Às vezes você vai dizer não e realmente vai perder o contrato.

O aprendizado que ficou para mim é outro: existem projetos que você só deveria aceitar se estiver disposto a defender aquilo em que acredita.

Eu queria tanto conquistar aquela segunda grande marca de Food que aceitei uma condição que contrariava aquilo que nossa experiência recomendava naquele momento.

O projeto aconteceu. O aplicativo foi entregue. O logo poderia perfeitamente estar em uma apresentação comercial nossa como mais um grande case.

Mas eu sei o que aconteceu nos bastidores. E talvez seja justamente por isso que considero essa experiência tão importante na minha trajetória.

Nem todo projeto que não se transforma em um grande case foi inútil. Alguns deles servem para construir algo muito mais valioso: experiência.

Experiência para reconhecer os sinais mais cedo, fazer perguntas melhores e, quando necessário, dizer não antes que a vontade de fechar uma venda fale mais alto do que a responsabilidade de entregar resultado.

A fila do caixa que ajudou a mudar a história da Alphacode

Muita gente me pergunta como a Alphacode conseguiu chegar a um ponto em que atendemos mais de 10 das 20 maiores redes de Food do Brasil.

A resposta não começa com um planejamento estratégico, uma campanha comercial ou uma decisão de criar uma vertical especializada em Food.

Começa em 2018.

E, curiosamente, passa pela fila do caixa de um supermercado.

Nosso primeiro grande desafio em Food

No início de 2018, a Alphacode foi convidada para participar de uma concorrência do Habib’s.

Naquele momento, éramos uma software house muito especializada no desenvolvimento de aplicativos e o Habib’s estava buscando um parceiro para construir seus novos canais digitais.

Era uma oportunidade enorme para nós.

O Habib’s já tinha uma das maiores operações de delivery do Brasil e estava entre as redes de maior relevância dentro do iFood naquele período.

Mas havia um pequeno detalhe:

Não éramos os únicos interessados.

Cerca de dez empresas participavam da concorrência.

Foram meses de reuniões, conversas, apresentações e etapas de seleção.

Até que chegamos à última semana de 2018.

Restavam três fornecedores.

Eu queria apresentar por último

Quando chegou a etapa final, fiz um pedido.

Queria ser o último dos três fornecedores a apresentar.

Não foi por acaso.

Eu acreditava que, apresentando por último, conseguiria deixar a impressão mais recente na cabeça dos decisores e, principalmente, sentir melhor como eles estavam reagindo à nossa proposta.

A reunião aconteceu em uma sexta-feira à tarde.

Entre as pessoas presentes estava Mauro Saraiva, CEO do Habib’s naquela época.

Nossa apresentação durou mais de duas horas.

Foi uma ótima reunião.

Saí de lá com aquela sensação de que tínhamos feito tudo o que podíamos fazer.

Agora não estava mais nas nossas mãos.

Eles nos disseram que tomariam uma decisão até segunda-feira.

Fui para casa esperar.

No domingo, minha esposa pediu pão

Dois dias depois aconteceu uma daquelas coincidências que, se alguém colocasse em um roteiro, talvez parecesse forçado demais.

Era domingo e minha esposa me pediu para ir ao supermercado comprar pão.

Fui ao Pão de Açúcar. Fiquei demorando além do normal…

E, na fila do caixa, encontrei justamente o Mauro.

Ele estava com a esposa e os filhos.

A reunião havia acontecido na sexta-feira. A decisão seria tomada na segunda.

E nós dois estávamos ali, por puro acaso, no mesmo supermercado.

Mas tinha mais.

Quando nos encontramos, ele estava conversando justamente sobre o aplicativo do Pão de Açúcar.

Ele me viu e comentou algo como:

“Olha, a gente estava falando disso ontem na reunião.”

Pronto.

Minha cabeça de vendedor entrou em ação novamente.

Começamos a conversar sobre aquilo e eu imediatamente conectei o que ele estava observando no aplicativo com a solução que tínhamos apresentado para o Habib’s.

Expliquei por que determinada situação não aconteceria no aplicativo deles, como tínhamos pensado aquele problema e como pretendíamos resolvê-lo.

A apresentação de sexta-feira, de certa maneira, continuou ali.

Sem PowerPoint.

Sem sala de reunião.

Na fila do pão.

Nos despedimos e fui para casa.

Na segunda-feira veio a resposta

Na segunda ou terça-feira, recebemos o contato:

A Alphacode havia vencido a concorrência.

Na época, eu não tinha como saber quanto aquele encontro no supermercado havia pesado na decisão.

Anos depois, porém, funcionários do próprio Habib’s me contaram uma história que nunca esqueci.

Naquela segunda-feira, Mauro chegou à empresa contando que havia me encontrado por acaso na fila do pão.

E comentou que aquilo devia ser algum tipo de sinal de que deveriam fazer o projeto com a gente.

Sempre achei essa história fantástica.

Mas seria muito injusto com tudo o que aconteceu antes e depois dizer que ganhamos o Habib’s porque encontrei o CEO no supermercado.

A sorte nos colocou na mesma fila.

Todo o resto precisou ser construído.

Ganhar a concorrência era apenas o começo

Pouco depois da vitória, fomos para uma reunião de briefing para definir o projeto.

Existia um roadmap de mais de um ano de evolução dos canais digitais.

Só que Mauro colocou um desafio na mesa.

Teríamos 60 dias para colocar a primeira fase no ar.

O objetivo inicial era lançar a experiência de delivery, que naquele momento ainda nem teria pagamento online.

A lógica era bastante clara.

Primeiro precisávamos provar que conseguíamos entregar.

Se aquela primeira etapa funcionasse, continuaríamos evoluindo o restante do roadmap.

Aceitamos.

Entregamos.

E aqueles 60 dias acabaram se transformando em uma relação de mais de cinco anos.

Com o tempo, além do Habib’s, passamos a cuidar também de outras marcas do grupo, como Ragazzo e Tendal Grill.

Mais importante do que isso, começamos a acumular um conhecimento sobre Food Tech que seria determinante para a história da Alphacode nos anos seguintes.

Sorte ajuda. Estar preparado ajuda muito mais.

Eu acredito muito em planejamento.

Acredito em processo.

Acredito em preparação.

Passei praticamente um ano trabalhando naquela concorrência.

Até a escolha de apresentar por último entre os três finalistas foi pensada.

Mas empreender também me ensinou que existe uma parte da nossa trajetória que simplesmente não controlamos.

Eu jamais poderia colocar em um plano comercial:

“Domingo: encontrar o CEO do Habib’s por acaso no supermercado.”

Foi sorte? Foi Deus?

E não tenho problema algum em reconhecer isso.

A questão é que a sorte sozinha não teria sido suficiente.

Se não tivéssemos passado meses estudando aquele projeto, provavelmente eu não teria conseguido transformar uma conversa casual no supermercado em uma continuação natural da reunião de sexta-feira.

Se não tivéssemos uma boa proposta, não estaríamos entre os três finalistas.

E se nosso time não tivesse entregado aquela primeira etapa em 60 dias, provavelmente aquela relação teria terminado poucos meses depois.

A fila do pão pode ter nos ajudado a ganhar o contrato.

Mas foram os 60 dias seguintes que começaram a construir nossa reputação em Food.

Hoje, quando olho para trás e vejo a Alphacode trabalhando com mais de 10 das 20 maiores redes de alimentação do Brasil, é curioso pensar em alguns dos pequenos acontecimentos que ajudaram a construir essa trajetória.

Grandes histórias empresariais raramente são uma linha reta.

Elas são feitas de competência, relacionamento, insistência, decisões, erros, oportunidades e, de vez em quando, algumas coincidências difíceis de explicar.

No nosso caso, uma delas aconteceu em um domingo de 2018.

Na fila do caixa.

Squads + agentes de IA: como usamos funcionários digitais para dobrar produtividade

Depois de testar dezenas de ferramentas genéricas de automação, chegamos a um modelo simples: squads humanos continuam cuidando da estratégia, enquanto agentes de inteligência artificial assumem as rotinas que travam o dia a dia. O resultado é um time focado no que gera valor e funcionários digitais trabalhando 24/7 sem perder o contexto.

Onde os agentes entram

Mapeamos todas as tarefas repetitivas que consumiam horas de talento sênior e priorizamos as que traziam mais fricção:

  • Montagem de propostas comerciais, com dados que já estão dentro do CRM.
  • Follow-ups e cadências de contato, sempre com contexto atualizado.
  • Conciliação de tickets, logs e health-checks do app.
  • Consolidação de dashboards operacionais que precisam nascer no começo do dia.

Quando os agentes assumem esse volume, o squad volta para discovery, priorização e relacionamento com o cliente.

Nosso modelo operacional em 5 passos

  1. Mapear tarefas repetitivas — tudo o que consome tempo e não exige julgamento humano.
  2. Priorizar pelo impacto — começamos com as rotinas que destravam receita ou liberam ciclos de engenharia.
  3. Desenhar o protocolo — cada agente recebe propósito, integrações, linguagem e limites muito claros.
  4. Treinar e monitorar — ambiente controlado, logs completos e humanos aprovando as primeiras execuções.
  5. Escalar com segurança — só abrimos novas funções quando a anterior já está com métricas e alertas configurados.

O que já aceleramos na Alphacode

  • +70% de velocidade para montar propostas comerciais porque os agentes puxam dados, aplicam templates e entregam a versão inicial pronta para revisão.
  • Follow-ups muito mais assertivos: o agente lê o histórico, monta o contexto e dispara o contato certo, encurtando o ciclo de fechamento.
  • +37% de throughput no backlog do app ao tirar do squad o trabalho braçal de tickets e relatórios.
  • -45% no tempo de resposta a incidentes, porque o agente monitora sinais vitais e inicia o playbook antes do time acordar.

Governança primeiro, hype depois

Funcionário digital só opera com:

  • Logs e trilhas de auditoria.
  • Responsáveis claros para intervir a qualquer momento.
  • Feature flags para ligar e desligar a função em segundos.
  • Limites de dados e integrações homologadas pela engenharia e pelo jurídico.

Sem controle não existe agente confiável — e a conta volta para o squad humano.

Quer rodar isso no seu canal?

Estou abrindo agenda para um diagnóstico rápido. Em 90 minutos mapeamos onde os agentes entram, definimos responsáveis e entregamos um roteiro de 30 dias. Comenta AGENTE no Instagram ou me chama direto no WhatsApp +55 11 98908-4278.

Como nasceu a plataforma de pricing que desenvolvemos para a Unilever

Alguns projetos marcam a trajetória de uma empresa.

Não apenas pelo tamanho do cliente, mas pela complexidade do desafio e pelo impacto que a solução pode gerar dentro da organização.

Um desses projetos para nós na Alphacode foi o desenvolvimento de uma plataforma estratégica de pricing para a Unilever.

O início da conversa

Como acontece em muitos projetos corporativos, tudo começou com uma conversa sobre um problema aparentemente simples.

A empresa precisava evoluir seu processo de planejamento de preços e projeção de receita, que envolvia uma série de variáveis comerciais e financeiras.

Margens, impostos, promoções, descontos, custos logísticos, metas de vendas e posicionamento de mercado — tudo isso precisa ser considerado quando grandes marcas definem sua estratégia de preço.

Em empresas globais como a Unilever, essas decisões não podem ser baseadas apenas em intuição. Elas precisam ser sustentadas por dados, modelos de análise e simulações de cenários.

O desafio real

O grande desafio era estruturar um ambiente que permitisse analisar essas variáveis de forma integrada.

Parte dessas análises ainda era realizada com planilhas e processos distribuídos entre diferentes áreas.

Isso funcionava, mas criava alguns problemas clássicos:

  • dificuldade de consolidar dados
  • alto esforço manual
  • pouca visibilidade integrada
  • limitações na simulação de cenários

O objetivo do projeto era transformar esse processo em uma plataforma estruturada de apoio à decisão.

Construindo a solução

A Alphacode foi responsável por projetar e desenvolver uma solução tecnológica capaz de centralizar dados e permitir simulações estratégicas de pricing.

Mais do que construir um sistema, o projeto exigiu uma compreensão profunda das regras de negócio envolvidas na formação de preços.

A plataforma foi desenhada para:

  • centralizar dados comerciais e financeiros
  • permitir simulação de diferentes cenários
  • avaliar impactos em margens e receita
  • apoiar o planejamento estratégico de preços

A ferramenta passou a apoiar o planejamento de marcas relevantes do portfólio da companhia, como Hellmann’s e OMO.

Tecnologia como ferramenta de decisão

Uma coisa interessante nesse projeto é que ele mostra como tecnologia pode deixar de ser apenas um suporte operacional e passar a atuar diretamente na estratégia de negócios.

Quando sistemas são desenhados com base nas necessidades reais da empresa, eles ajudam líderes e equipes a tomarem decisões melhores.

No caso desse projeto, o objetivo nunca foi apenas substituir planilhas.

A ideia era criar um ambiente que ajudasse o negócio a simular cenários, avaliar impactos e tomar decisões com mais segurança.

O que aprendemos com esse projeto

Projetos como esse reforçam algo que sempre acreditamos na Alphacode: tecnologia faz mais diferença quando está conectada diretamente aos desafios estratégicos do negócio.

Mais do que desenvolver software, nosso papel muitas vezes é ajudar empresas a transformar processos complexos em plataformas que apoiam decisões importantes.

E é justamente esse tipo de projeto que mostra como engenharia de software pode se tornar uma alavanca real de negócio.

Equity, dívida ou híbrido? Como escolher o funding certo para sua fintech

Toda fintech que cresce enfrenta a mesma pergunta em algum momento:

Qual é a melhor estrutura de capital para sustentar essa expansão?

Equity?
Dívida?
Ou uma combinação das duas?

A escolha errada pode limitar crescimento, comprometer governança ou até inviabilizar rodadas futuras. A escolha certa cria alavancagem estratégica e acelera o negócio de forma saudável.

Neste artigo, quero trazer uma visão prática sobre como pensar essa decisão.

Equity: crescer diluindo participação

Equity significa vender parte da empresa para captar recursos. É o caminho mais comum para startups em estágio inicial.

Vantagens do equity:

• Não gera obrigação de pagamento imediato
• Não pressiona fluxo de caixa
• Permite crescimento mesmo sem previsibilidade de receita
• Pode trazer investidores estratégicos

Desvantagens:

• Diluição societária
• Perda parcial de controle
• Pressão por crescimento acelerado
• Dependência de valuation

Equity faz sentido quando:

• A fintech ainda está validando modelo
• Não existe previsibilidade de caixa
• O risco do negócio é alto
• O objetivo é ganhar mercado rapidamente

Em estágios muito iniciais, dívida costuma ser inviável. O risco é elevado demais para credores.

Mas conforme a fintech amadurece, a equação muda.

2 – Dívida: crescer preservando participação

Dívida significa captar recursos com obrigação de pagamento futuro. Pode ser via debêntures, FIDC, crédito estruturado ou instrumentos privados.

Vantagens da dívida:

• Preserva participação societária
• Pode reduzir custo de capital
• Estrutura governança
• Aumenta disciplina financeira

Desvantagens:

• Pressiona fluxo de caixa
• Exige previsibilidade
• Requer estrutura jurídica e regulatória
• Pode impor covenants e restrições

Dívida faz sentido quando:

• Existe carteira performada
• Há previsibilidade de receita
• A inadimplência está controlada
• A fintech já possui governança organizada

Para fintechs de crédito, dívida estruturada não é apenas opção. É parte do modelo de negócio.

Mas aqui existe um ponto essencial.

Sem tecnologia sólida, não existe dívida saudável.

Controle de carteira, conciliação, monitoramento de risco, rastreabilidade de contratos. Tudo precisa estar organizado para sustentar funding estruturado.

3 – Modelo híbrido: combinando inteligência financeira

Muitas fintechs mais maduras adotam um modelo híbrido.

Captam equity para expansão estratégica e utilizam dívida para financiar carteira ou operação.

Esse modelo permite:

• Manter caixa saudável
• Preservar participação
• Reduzir custo médio de capital
• Otimizar retorno sobre patrimônio

O híbrido é sofisticado. Exige planejamento.

Não é apenas captar recursos. É desenhar arquitetura financeira.

A pergunta que quase ninguém faz

A maioria dos fundadores pergunta:

Qual instrumento está disponível?

Mas a pergunta correta é outra:

Qual instrumento está alinhado ao estágio da empresa e à sua estratégia de longo prazo?

Captação não é evento. É estratégia contínua.

Se a fintech cresce rápido demais com equity, pode se diluir excessivamente.

Se cresce com dívida antes da hora, pode quebrar por falta de caixa.

Se não planeja funding desde o início, cria gargalos estruturais.

Funding é arquitetura, não improviso

Fintech não é apenas tecnologia.

É tecnologia combinada com engenharia financeira.

A estrutura de capital precisa estar alinhada com:

• Modelo de receita
• Perfil de risco
• Horizonte de crescimento
• Governança
• Capacidade tecnológica

Vejo muitas fintechs investindo pesado em marketing e originação antes de estruturar funding adequadamente.

Isso quase sempre gera tensão.

Escalar crédito exige capital.
Escalar capital exige estrutura.
Estrutura exige planejamento.

O que considero saudável

De forma geral:

Estágio inicial
Equity é dominante.

Estágio de crescimento
Começa a combinar equity e dívida.

Estágio de maturidade
Dívida estruturada ganha protagonismo.

Não existe fórmula mágica.

Existe alinhamento entre estratégia, risco e estrutura.

E essa decisão não deve ser tomada apenas pelo financeiro.

Ela envolve tecnologia, jurídico, governança e visão de longo prazo.

No fim, a pergunta central não é se você vai usar equity ou dívida.

A pergunta é:

Sua estrutura de capital está preparada para o crescimento que você projeta?

Debêntures, FIDC e securitização: entendendo as opções de dívida para fintechs

Nos últimos anos, o mercado de fintechs amadureceu de forma significativa no Brasil. Se antes o foco era apenas crescer base de usuários, hoje a discussão é outra: como estruturar capital para escalar de forma sustentável?

É nesse contexto que entram instrumentos como debêntures, FIDC e securitização. Embora pareçam complexos à primeira vista, eles são, na prática, mecanismos estruturados para transformar recebíveis e previsibilidade de receita em capacidade de crescimento.

Neste artigo, explico de forma direta o que é cada um deles e quando fazem sentido para uma fintech.

1. Debêntures: dívida estruturada no mercado de capitais

Debêntures são títulos de dívida emitidos por empresas para captar recursos diretamente com investidores.

Na prática, a empresa “toma dinheiro emprestado” do mercado e se compromete a pagar juros e devolver o principal em determinado prazo.

Para fintechs, esse instrumento costuma fazer sentido quando:

  • A empresa já possui governança estruturada
  • Tem previsibilidade de receita
  • Precisa captar volumes maiores
  • Quer diversificar fontes de funding além de bancos

A vantagem é acessar capital sem diluir participação societária.
O desafio está na estruturação, custos jurídicos e exigências regulatórias.

2. FIDC: transformando recebíveis em funding

O FIDC, Fundo de Investimento em Direitos Creditórios, é talvez o instrumento mais comum no universo de fintechs de crédito.

Funciona assim: a fintech origina créditos (empréstimos, antecipação de recebíveis, financiamento etc.) e cede esses direitos creditórios para um fundo. O fundo capta recursos com investidores e usa esse dinheiro para comprar esses recebíveis.

Ou seja, a fintech transforma crédito concedido em capital imediato para continuar operando.

É uma estrutura poderosa porque:

  • Permite alavancar a operação
  • Segrega risco
  • Cria camadas de cotas (sênior e subordinada)
  • Estrutura governança e controle de risco

Mas exige maturidade operacional, compliance robusto e tecnologia capaz de garantir rastreabilidade total da carteira.

3. Securitização: empacotando ativos financeiros

A securitização é o processo de transformar ativos financeiros, como recebíveis, em títulos negociáveis no mercado.

Pode ser feita por meio de uma securitizadora, que emite CRIs, CRAs ou outros títulos lastreados nos ativos da empresa.

Para fintechs, é uma alternativa interessante quando:

  • Existe volume relevante de ativos
  • Há padronização dos contratos
  • A carteira tem histórico e previsibilidade

É uma forma sofisticada de financiamento e pode reduzir custo de capital quando bem estruturada.

Qual faz mais sentido?

A resposta é: depende do estágio da fintech.

Startups muito iniciais dificilmente acessarão debêntures ou estruturas complexas.
Fintechs em estágio de crescimento, com carteira performada e governança organizada, já podem considerar FIDC.
Empresas mais maduras podem estruturar emissões mais sofisticadas.

O ponto central é que estrutura financeira e tecnologia caminham juntas.

Sem sistemas sólidos, rastreabilidade de dados, controle de inadimplência e arquitetura bem definida, nenhuma dessas estruturas para em pé.

Tenho visto muitas fintechs focarem apenas na originação e esquecerem que, para escalar de verdade, é preciso pensar funding desde o início.

Escalar crédito exige capital.
Escalar capital exige estrutura.
E estrutura exige tecnologia sólida.

Se você está estruturando ou repensando o modelo financeiro da sua fintech, vale olhar para essas alternativas com profundidade estratégica.

Warren Buffett vende Amazon e aumenta posição no New York Times. O jornalismo não morreu.

Recentemente, o mercado foi surpreendido por um movimento interessante:
Warren Buffett reduziu drasticamente sua posição em Amazon e aumentou sua participação no New York Times.

De um lado, uma das maiores empresas de tecnologia do mundo.
Do outro, um jornal fundado em 1851.

Se alguém dissesse há 15 anos que um investidor icônico diminuiria exposição em uma gigante tech para apostar em uma empresa de mídia tradicional, muitos chamariam de loucura.

Mas talvez essa não seja uma história sobre tecnologia versus jornalismo.

Talvez seja uma história sobre modelo de negócio.

O New York Times deixou de ser apenas um jornal há muito tempo.

Hoje é uma plataforma digital de conteúdo com:

• Milhões de assinantes digitais
• Receita recorrente previsível
• Produtos complementares como Games, Cooking e podcasts
• Forte base de dados própria
• Relacionamento direto com o consumidor

Enquanto muitos veículos sofreram com a queda do impresso, o Times investiu cedo e pesado na transformação digital.

Não foi uma adaptação superficial.
Foi uma reconstrução estrutural do modelo de receita.

E é exatamente isso que investidores como Buffett observam.

Ele não investe em “setores da moda”.
Ele investe em negócios com marca forte, poder de precificação, recorrência e vantagem competitiva sustentável.

A Amazon é extraordinária. Mas é um negócio de margens pressionadas, competição constante e alta exigência operacional.

O New York Times, por outro lado, construiu algo diferente: uma base de assinantes que pagam todo mês por um ativo intangível de altíssimo valor, credibilidade.

O jornalismo não morreu.
O modelo antigo é que morreu.

E aqui está a parte que mais me interessa.

Essa história não é sobre mídia.
É sobre transformação digital real.

Quantas empresas ainda dependem exclusivamente de intermediários?
Quantas estão reféns de marketplaces, redes sociais ou grandes plataformas?
Quantas ainda tratam tecnologia como custo e não como ativo estratégico?

O que o New York Times fez foi construir seu próprio canal, sua própria plataforma, sua própria recorrência.

Isso vale para restaurantes que criam canal próprio de delivery.
Vale para redes que criam sua fintech.
Vale para indústrias que constroem plataformas internas robustas.

Na Alphacode, é exatamente esse o trabalho que fazemos: ajudar empresas a sair da dependência e construir ativos digitais próprios.

Não é sobre “ter um app”.
É sobre estruturar um modelo digital que gera previsibilidade, dados e valor de longo prazo.

Buffett não está apostando no passado.
Ele está apostando em um modelo de negócio bem executado.

E talvez essa seja a verdadeira lição:

Não importa o setor.
Importa quem entende que tecnologia é infraestrutura estratégica.

O jornalismo não morreu.
Ele evoluiu.

A pergunta é: o seu negócio já evoluiu também?

Nova regulamentação do serviço de BAAS Banking as A Service do Banco Central.

Coletiva sobre a nova regulamentação do serviço de BAAS Banking as A Service do Banco Central.

Na minha opinião melhora demais o mercado por que fecha zonas cinza e deixa claro como podemos criar novos modelos de negócio.

Cédula de Crédito Bancário (CCB): como funciona e por que é essencial para operações de crédito

Se você já se sentiu perdido em meio a siglas como CDB, CDI, LCI ou LCA, não está sozinho. Na hora de financiar clientes ou captar recursos, existe uma modalidade que vem ganhando cada vez mais destaque: a Cédula de Crédito Bancário (CCB). Ela é um título de crédito que formaliza um empréstimo ou financiamento entre uma pessoa física ou jurídica e uma instituição financeira. A CCB representa uma promessa de pagamento e confere força jurídica ao contrato .

O que é uma Cédula de Crédito Bancário?

A CCB é um título de crédito emitido por pessoa física ou jurídica em favor de uma instituição financeira, decorrente de qualquer modalidade de operação de crédito . Em outras palavras, ela formaliza a dívida, define prazos e juros e estabelece garantias. Ela foi criada pela Lei nº 10.931/2004 e ganhou relevância no mercado de crédito por ser um instrumento simples, ágil e com força executiva: em caso de inadimplência, o credor pode cobrar a dívida diretamente, sem processos longos .

Principais características

  • Emissão física ou digital: a CCB pode ser emitida em papel ou de forma eletrônica, com assinatura digital, o que dá agilidade e segurança .

  • Garantias variadas: podem ser exigidas garantias reais (como imóvel ou veículo) ou fidejussórias (fiadores), mas há operações sem garantia formal .

  • Transferibilidade: o título pode ser cedido a terceiros, mesmo que não sejam instituições financeiras, desde que o credor original concorde .

  • Moeda nacional ou estrangeira: a CCB também pode ser usada em transações internacionais, o que aumenta a concorrência e reduz o custo do crédito .

  • Registro opcional: o documento pode ser registrado em entidades autorizadas, como a B3, garantindo transparência e facilitando a negociação do ativo .

Como funciona a emissão de uma CCB?

A emissão segue etapas simples:

  1. Análise de crédito – a instituição avalia o histórico do tomador e define se haverá exigência de aval ou garantia .

  2. Definição dos termos – valor emprestado, taxa de juros (fixa ou indexada), prazos e garantias .

  3. Formalização – a CCB deve conter elementos obrigatórios: identificação das partes, valor do crédito, taxa de juros, prazos de pagamento, condições de inadimplência e assinaturas .

  4. Registro e liberação – após a assinatura, a CCB pode ser registrada em cartório ou em entidades como a B3, e os recursos são liberados ao tomador .

Por ter valor probatório elevado, a CCB permite que a instituição financeira execute o contrato de forma rápida caso o devedor não pague . Assim, as taxas de juros costumam ser menores do que em contratos tradicionais.

Por que a CCB é essencial em operações de crédito?

A Cédula de Crédito Bancário tornou‑se indispensável para instituições financeiras e fintechs de crédito por vários motivos:

  • Segurança jurídica – o título reduz o risco para o credor e oferece segurança para negociar créditos no mercado .

  • Agilidade e simplicidade – a emissão é rápida e com menos burocracia, o que agiliza a liberação do dinheiro .

  • Versatilidade – a CCB serve para diversas modalidades de crédito, como pessoal, consignado, financiamento de veículos, microcrédito, crédito rural e imobiliário .

  • Transferibilidade – permite a cessão do título a terceiros e possibilita securitização e acesso a novos investidores .

  • Flexibilidade cambial – pode ser emitida em moeda estrangeira, permitindo operações internacionais .

Quando utilizar uma CCB?

Empresas e empreendedores podem usar a CCB em várias situações. Além dos empréstimos tradicionais, ela serve para:

  • Financiar investimentos – capital de giro, expansão, reformas ou compra de equipamentos.

  • Antecipar recebíveis – lojas ou marketplaces podem emitir CCBs lastreadas em contratos de vendas e cedê‑las a fundos, recebendo à vista.

  • Operações consignadas – professores, servidores ou aposentados podem contratar CCB consignada com taxas mais baixas .

Para cada uma dessas finalidades, a CCB se adapta às necessidades do tomador e do credor, desde pequenos empréstimos até grandes financiamentos .

CCB e fintechs de crédito

Para fintechs que operam crédito próprio, a CCB é o instrumento jurídico padrão para formalizar as operações de empréstimo. Ela oferece:

  • Integração via API com plataformas de registro, como a B3 .

  • Escalabilidade – é possível agrupar várias CCBs em um Certificado de Cédulas de Crédito Bancário (CCCB) e securitizar a carteira .

  • Conformidade regulatória – por ser prevista em lei, atende às exigências do Banco Central e facilita auditorias.

Plataformas como o MOSAICO Finance automatizam a emissão de CCBs, controlam parcelas e cobranças e fornecem relatórios em tempo real, evitando que a empresa crie toda a infraestrutura do zero.

Conclusão: por que adotar a Cédula de Crédito Bancário?

A CCB é mais do que um contrato; ela é a base que sustenta o crescimento do crédito privado no Brasil. Por ser flexível, juridicamente segura e fácil de emitir, tornou‑se a escolha natural para fintechs de crédito, bancos e empresas que desejam financiar clientes ou captar recursos. Se você pretende operar crédito de forma profissional, entender e utilizar a CCB é fundamental.

O que é uma SPSAV (Sociedade Prestadora de Serviços de Ativos Virtuais)?

O que é uma SPSAV – Desde a aprovação do Marco Legal das Criptomoedas (Lei nº 14.478/2022) o mercado brasileiro de ativos virtuais entrou em um processo de formalização. A lei estabeleceu que qualquer empresa que execute, em nome de terceiros, serviços como câmbio entre moedas e criptoativos, custódia, transferência ou intermediação de ativos virtuais se enquadra como prestadora de serviços de ativos virtuais . Em 2025 o Banco Central do Brasil (BCB) deu o passo seguinte: criou a figura da Sociedade Prestadora de Serviços de Ativos Virtuais (SPSAV) e detalhou suas obrigações, modalidades e processos de autorização.

O que é uma SPSAV?

Uma SPSAV é uma empresa registrada no Brasil, autorizada pelo BCB a operar serviços com ativos virtuais em nome de terceiros. Para atuar legalmente, a empresa deve integrar a expressão “Sociedade Prestadora de Serviços de Ativos Virtuais” no nome empresarial e atender a requisitos de capital, governança, segregação de ativos e controles internos . A lei determina que qualquer pessoa jurídica que realize ao menos um dos seguintes serviços de ativos virtuais deve buscar essa autorização:

  • Troca entre ativos virtuais e moeda nacional ou estrangeira;

  • Troca entre diferentes ativos virtuais;

  • Transferência de ativos virtuais;

  • Custódia ou administração de ativos virtuais ou das chaves que dão acesso a esses ativos;

  • Participação em serviços financeiros relacionados à emissão ou venda de ativos virtuais .

Modalidades de SPSAV

As resoluções do BCB (519, 520 e 521) criam três modalidades de operação, com escopos bem definidos :

  1. Intermediária – Pode subscrever emissões de ativos virtuais, comprar, vender e trocar criptoativos, gerir carteiras, atuar como agente fiduciário, realizar serviços de staking e operar com ativos virtuais no mercado de câmbio.

  2. Custodiante – Responsável pela guarda das chaves e pelo registro das posições dos clientes, garantindo que as movimentações sejam feitas conforme instruções dos titulares, tratando eventos incidentes (ex.: fork ou airdrop) e constituindo/retirando ônus sobre os ativos .

  3. Corretora – Combina as atividades das modalidades intermediária e custodiante .

Além das SPSAVs, bancos, corretoras de títulos e corretoras de câmbio podem, mediante autorização, prestar serviços nas modalidades intermediária e custodiante .

Regras e obrigações principais

  • Constituição e nome: devem ser sociedades limitadas ou anônimas, sediadas no Brasil e com administração local. Não podem ter apenas um sócio, e o nome empresarial precisa evidenciar sua condição de SPSAV .

  • Capital e governança: seguirão regras prudenciais de capital mínimo (ainda a serem definidas) e precisam ter, no mínimo, três administradores responsáveis perante o BC .

  • Segregação de ativos: os recursos e ativos virtuais dos clientes devem ser mantidos separados dos recursos da empresa. É obrigatório possuir políticas de segurança cibernética, controles internos robustos, gestão de riscos e práticas de prevenção à lavagem de dinheiro .

  • Autorização e mudanças societárias: além da autorização inicial, alterações como mudança de controle, fusão, cisão, aumento de capital ou alteração da modalidade exigem nova autorização do Banco Central .

  • Mercado de câmbio e capitais internacionais: operações como pagamentos e transferências internacionais com cripto, liquidação de obrigações de cartões no exterior e compra de ativos virtuais referenciados em moedas fiduciárias passam a ser tratadas como operações cambiais. Quando a contraparte não for instituição autorizada pelo BC, cada transação fica limitada a US$ 100 mil .

Por que isso importa?

A regulação das SPSAVs traz segurança jurídica para empresas, investidores e consumidores; inibe fraudes e pirâmides; e aproxima o mercado cripto do sistema financeiro tradicional . Ao exigir governança e controles robustos, o Brasil se alinha às melhores práticas internacionais e cria um ambiente favorável à inovação responsável em blockchain e finanças descentralizadas.

Diferença entre SPSAV e instituições financeiras tradicionais

Embora as SPSAVs sejam fiscalizadas pelo BC e tenham regras semelhantes às de instituições financeiras, seu escopo é limitado a ativos virtuais. Bancos, cooperativas e fintechs que atuam com crédito, depósitos ou investimentos seguem normas bancárias específicas; já as SPSAVs têm regulação própria e se sujeitam à Comissão de Valores Mobiliários (CVM) apenas quando lidam com tokens que configuram valores mobiliários .

O reconhecimento das SPSAVs e sua integração ao arcabouço regulatório marcam um divisor de águas no ecossistema de criptoativos no Brasil. Empresas que pretendem operar com ativos virtuais deverão se adequar a essa realidade, adotando boas práticas de compliance, segurança e transparência. Para investidores e consumidores, a novidade representa mais proteção e confiabilidade nas transações.