Vibe coding versus SoftCS: a conta que ninguém mostra antes de você começar

Existe um tipo de conversa que virou rotina em qualquer time de produto nos últimos meses. Alguém abre o Lovable, o Cursor ou uma dessas ferramentas de vibe coding, descreve o que quer em linguagem natural e, em algumas horas, tem uma tela funcional na frente. A sensação é poderosa. E a pergunta que vem logo depois é quase inevitável: "se dá pra construir isso assim, por que a gente paga por uma plataforma de Customer Success pronta?"

É uma pergunta legítima. Vibe coding é uma tecnologia real, útil e que veio pra ficar. O problema não é a ferramenta. O problema é a conta que ninguém coloca na mesa antes de você tomar a decisão de construir em vez de contratar.

Este texto não vai falar de segurança, LGPD ou maturidade de código, que são os argumentos óbvios. Vai falar de dinheiro. Especificamente, de quanto custa, de verdade, chegar onde a SoftCS já está hoje. E de quanto custa continuar lá depois que a novidade passa.

O que "construir igual" realmente significa

Antes de estimar custo, vale alinhar o que estamos comparando. Uma plataforma de CS não é uma tela bonita com uma lista de clientes. O que a SoftCS entrega hoje é um conjunto de camadas que trabalham juntas:

Ingestão e unificação de dados de várias fontes: financeiro, tickets de suporte, reuniões, pulse do CSM, e-mails, uso de produto e planos de sucesso. Cada uma dessas fontes tem um formato próprio, uma API própria e um ritmo próprio de atualização.

Distribuição automática de carteira a partir do CRM, com regras de segmentação que decidem qual conta vai pra qual CSM no momento em que o negócio fecha.

Jornadas automatizadas que disparam a partir de eventos, acompanham a implantação e a retenção inicial por coorte, e ajustam o fluxo conforme o cliente avança.

Automações, playbooks e alertas de churn e upsell rodando sobre uma base de dados que precisa estar sempre atualizada e coerente.

Um dashboard de implantação e retenção que cruza tudo isso em métricas que fazem sentido pra quem toma decisão.

Quando alguém diz "eu construo isso com vibe coding", o que geralmente foi construído é a primeira camada: a tela. O resto continua invisível até você tentar colocar em produção.

A conta de construir: os primeiros três mil reais são só a entrada

Vamos aos números. Para chegar a um protótipo que se pareça com uma plataforma de CS de verdade, com as integrações principais funcionando e um mínimo de lógica de negócio por trás, você vai queimar uma quantidade significativa de tokens de LLM só no processo de construção.

Iterar em cima de integrações, depurar fluxos que quebram, reconstruir partes que o modelo gerou errado, testar cenários com dados reais: tudo isso consome tokens de forma acelerada. Uma estimativa conservadora para sair de uma tela isolada até algo que integra as fontes de dados principais e roda um fluxo ponta a ponta fica em torno de três mil reais só em tokens de construção. E esse é o número otimista, assumindo que você sabe o que está fazendo e não vai refazer o trabalho três vezes.

Repare que aqui a gente ainda está falando só de construir. Nada foi pra produção, ninguém depende disso ainda, nenhum dado de cliente real está passando por lá de forma contínua.

A parte que o Lovable não resolve sozinho

Aqui está o ponto que separa um protótipo de uma operação. Ferramentas de vibe coding são excelentes para gerar a camada de interface e uma lógica inicial. Elas não foram feitas para sustentar o que uma plataforma de CS precisa por baixo.

Para que os dados cheguem, se mantenham atualizados e alimentem os fluxos de forma confiável, você vai precisar de coisas que não saem prontas de um prompt:

Uma camada de workers rodando em background para buscar, transformar e sincronizar dados de cada integração no ritmo certo. Ticket que chega no suporte precisa refletir no health score sem você apertar um botão. Isso é processamento assíncrono, com fila, com tratamento de falha, com retry.

Uma camada de orquestração que coordena esses workers, decide a ordem das coisas, lida com dependências entre fontes e garante que o dado que chega numa jornada é o dado certo, no momento certo. Sem isso, você tem integrações soltas que funcionam no demo e quebram no primeiro volume real.

Um banco de dados dimensionado para o volume e o tipo de consulta que uma operação de CS faz. Cruzar coorte de retenção, calcular cobertura de carteira, rodar alertas sobre a base inteira: isso não é carga de um banco de protótipo. Você vai precisar escalar para algo mais robusto, e banco robusto tem custo fixo mensal que não desaparece nos meses de pouco uso.

Nenhuma dessas três camadas é opcional. Elas são exatamente o que transforma "uma tela que mostra clientes" em "uma plataforma que orquestra Customer Success". E são exatamente o que o vibe coding não entrega sozinho.

O custo que não aparece na planilha: manutenção

Digamos que você construiu tudo. Integrações rodando, workers processando, orquestração de pé, banco aguentando. Ótimo. Agora vem a parte que dura pra sempre.

Integração quebra. APIs de terceiros mudam sem avisar. O provedor de tickets altera um campo, o CRM muda um endpoint, o formato de um dado financeiro vem diferente num mês. Cada uma dessas mudanças, que acontecem o tempo todo, quebra um pedaço do seu fluxo. E quando quebra, alguém precisa consertar antes que o dado errado contamine um health score e um CSM tome uma decisão baseada em informação furada.

Isso não é um evento pontual. É uma rotina. E aqui a conta fica clara, com dois caminhos possíveis, ambos caros:

No primeiro caminho, você contrata alguém dedicado a manter esse sistema de pé. Uma pessoa que entenda de integração, de dados, de orquestração e que esteja disponível quando algo quebra. No mercado brasileiro, esse perfil não custa menos de dez mil reais por mês pra empresa quando você soma tudo. Todo mês. Para manter funcionando algo que você já pode comprar pronto.

No segundo caminho, você não contrata ninguém novo e tira alguém que já está no time. Só que essa pessoa é justamente quem deveria estar construindo o seu produto, o seu core, aquilo que de fato diferencia o seu negócio no mercado. Cada hora que ela gasta consertando uma integração de CS é uma hora que ela não gasta no que só a sua empresa pode fazer. Esse custo não aparece numa fatura, mas é o mais caro dos dois, porque ele sai direto do seu diferencial competitivo.

A conta somada

Vamos juntar tudo, sem drama, só somando:

Três mil reais em tokens só para chegar a algo que integra as fontes principais e roda um fluxo. Custo fixo mensal de um banco dimensionado pra valer, mais a infraestrutura de workers e orquestração rodando o tempo todo. E, por cima disso, ou dez mil reais por mês numa contratação dedicada, ou o custo invisível e maior de desviar seu melhor time do seu próprio produto.

Tudo isso para chegar num lugar onde uma plataforma especializada já está. E aqui vale a comparação que uma Head de CS chamada Carolina faria: o cálculo não é "construir é mais barato que comprar". O cálculo é "quanto do meu time, do meu tempo e do meu dinheiro eu quero gastar mantendo uma engenharia de dados de CS de pé, quando esse nunca foi o meu negócio".

Onde cada escolha faz sentido

Nada disso é argumento contra vibe coding. Se o que você precisa é um protótipo interno, uma ferramenta pontual, um experimento que vai viver um mês, construir rápido é a escolha certa e mais barata. Vibe coding brilha exatamente aí.

O ponto muda quando você precisa de algo que roda em produção, com dados de clientes reais passando todo dia, sustentando decisões de renovação e expansão que valem receita de verdade. Aí você não está mais escolhendo entre construir e comprar uma tela. Está escolhendo entre montar e manter uma operação de engenharia de dados, ou usar uma que já existe e já resolveu esses problemas.

A SoftCS não é uma tela. É a camada de workers, a orquestração, o banco dimensionado e a manutenção contínua, tudo já resolvido e diluído no custo da plataforma, em vez de recair sobre o seu time. O trabalho de manter tudo isso de pé continua existindo. A pergunta é só se ele vai ser seu problema ou não.

Se a sua operação de CS já passou da fase de protótipo, faça a conta completa antes de decidir construir. Não a conta dos primeiros três mil reais. A conta dos próximos doze meses.