Há alguns anos, fui contratado por uma empresa espanhola com um mandato tão ambicioso quanto vago: “organizar a casa”. Em tese significou profissionalizar a equipe, adotar boas práticas e escalar a plataforma para novos mercados (Europa, México e Colômbia). Na prática, descobri um Frankenstein de código: ifs e elses em todos os lugares – na frente, atrás, nos aplicativos móveis e até na camada de infraestrutura – que respondiam a solicitações específicas de clientes específicos. Cada vez que abrimos um arquivo aparecia um comentário como este:
Imagine esse padrão repetido centenas de vezes. O resultado foi um sudoku de regras de negócios tão personalizado que nossa equipe de suporte ao cliente teve que memorizar centenas de combinações para resolver questões do dia a dia, e os desenvolvedores xingavam cada vez que tocavam em algum módulo por medo de quebrar “aquela coisa que o cliente D só usa em dias pares”.
A dispendiosa miragem da “grande conta”
É tentador – especialmente nos estágios iniciais – aceitar um recurso personalizado para fechar o “cliente dos sonhos”. Parece um acordo inofensivo: basta mais um ajuste e o faturamento sobe amanhã. Mas a realidade é um iceberg: o que o vendedor assina em meia hora transforma-se em meses – ou anos – de complexidade técnica, dívida de design e atrito operacional.
No meu caso, essa dinâmica virou rotina: vender primeiro, perguntar depois. Quando cheguei, a plataforma já incluía uma centena de comportamentos especiais, quase todos codificados. Essa “flexibilidade” gerou rendimento individual, sim, mas colectivamente foi um fardo que atrasou todo o roteiro.
Os mesmos vendedores que vendiam produtos “personalizados” foram os primeiros a dizer que nossa equipe de produto era muito lenta. Não os culpo, no final das contas isso foi um reflexo do ambiente em que se encontravam e da cultura que se formou na empresa.
Custos imediatos que não estão na planilha Excel:
Velocidade de desenvolvimento: qualquer nova funcionalidade tinha que ser testada em uma árvore infinita de casos. Fomos lentos não por falta de talento, mas pelo emaranhado de condicionais. Qualidade do suporte: os agentes tinham que lembrar quem tinha qual variante do processo de check-in, qual relatório específico cada um baixou... A integração de um novo colega pode levar meses. Atração e retenção de talentos: Ninguém está motivado a lutar contra códigos espaguete escritos para apagar incêndios. Cada fuga de engenheiros seniores aumentava a pressão sobre aqueles que resistiam. Escalabilidade internacional: lançar um novo país significava auditar todas as exceções para garantir que nenhuma entrasse em conflito com a legislação local. Muitas vezes o bloqueio não era técnico, mas sim de conformidade.
A armadilha do “cliente rei”
O problema não era apenas técnico, era cultural. As equipes de vendas e de experiência do cliente aprenderam que “o cliente tem sempre razão” significava “dizer sim a todos os caprichos”. Quando propus parar com essa dinâmica, muitos me viam como o vilão: “Como vamos dizer não a quem paga a conta?”
Aqui descobri o custo de capital social de retificar decisões erradas do passado. Convencer um cliente a desistir de seu atalho favorito é difícil; convencer ainda mais o gerente de conta que recebeu a comissão. Reuniões intermináveis, e-mails de “máxima urgência” e a sensação de que cada não estava desgastando o relacionamento. Porém, o risco de continuar o mesmo era muito maior: morrer de sucesso.
O roteiro para sair do labirinto
Bloquear novas customizações: A partir desse momento, por mais que um cliente nos pedisse algo, criamos uma feature padrão no produto, com parâmetros de configuração, sem ifs e elses no código. Mapeando o território: Construímos um inventário exaustivo de exceções: o que faziam, por que existiam, quantos usuários realmente as utilizavam e que receita geravam. Descobrimos que 80% dos casos especiais afetaram menos de 10% do faturamento*. Os dados foram fundamentais para despersonalizar a conversa: não foi “capricho de Marketing”, foi uma relação custo/benefício insustentável. Padrões de grupo: Começamos a conhecer e entrevistar esses clientes, para entender por que eles precisavam desses recursos e como os utilizavam. Defina uma política de produto: escrevemos um documento breve – e público – que ditava quando uma solicitação seria considerada “principal” (beneficia 80% dos clientes), “configurável” (resolvida com parâmetros disponíveis) ou “especial” (não abordada). Essa clareza aliviou a pressão das equipes de atendimento ao cliente. Negocie com transparência: Para cada cliente com dependências críticas desenhamos um plano de transição: datas específicas, suporte e, em alguns casos, recursos de substituição ainda melhores. Alguns foram embora, é verdade. Mas quem ficou ganhou um produto mais robusto e homogêneo. Comemore as negações: Reforçamos internamente a ideia de que dizer não também faz parte do valor que agregamos. Cada solicitação rejeitada economizou dezenas de horas futuras. Nós medimos e comunicamos.
Resultados (e cicatrizes)
Para ser totalmente honesto, não extinguimos todas as chamas, mas iniciamos a rota de evacuação adequada. Começamos com o mais crítico: refatorar o fluxo de checkout. A missão era clara: eliminar o código não escalável e construir uma base que nos permitisse vender em vários países sem sobrecarregar o fardo das personalizações legadas.
Durante meu tempo, separamos os principais serviços em novos microsserviços livres de IFs oportunistas e traçamos um mapa da dívida técnica com prioridades claras. Ainda levarão anos para terminar essa limpeza – eu sei disso e aceito isso – mas hoje eles estão se movendo na direção certa em vez de acumular remendos.
Sim, houve danos colaterais. Alguns clientes importantes saíram (nunca saberemos se por causa da nossa cruzada contra exceções ou por fatores externos), mas no final do ano o volume de negócios continuou a crescer e, o mais importante, sem voltar a vender uma única funcionalidade “customizada”. Agora a plataforma opera em diversos países com uma única base de código, e novos parceiros saltam diretamente para a versão padrão, sem negociações intermináveis ou promessas que comprometam o futuro.
A cicatriz que fiquei é clara: nos primeiros anos de vida de uma startup, dizer sim a um pedido exclusivo equivale a assinar uma hipoteca complexa a taxa variável. Os juros compostos disparam a cada nova exceção. Avalie cada concessão com um business case rigoroso, calcule o custo de oportunidade e decida com total consciência. E se você ainda concordar em customizar, faça-o sabendo exatamente quando e como irá desmontá-lo posteriormente. Às vezes, perder um cliente dói; Hipotecar sua escalabilidade, por outro lado, pode custar a empresa inteira.
Três aprendizados que compartilho com você
Escalar ≠ acumular: Escalar implica multiplicar os impactos com o mesmo esforço marginal, não adicionar patches. Se cada contrato acrescenta complexidade linear, sua “escala” é fictícia. O custo de oportunidade é real: cada semana gasta em um recurso exclusivo é uma semana que você não dedica a algo valioso para todos. Sempre avalie a Melhoria Total Endereçável, e não apenas o Valor de Vida do Cliente. A cultura deve apoiar o produto: sem uma estrutura explícita que proteja o não, as equipes de vendas acabarão por destruir a sua visão. O manifesto do produto não é burocracia: é o escudo que protege a sua estratégia.
Olhando para o futuro
Nós, startups, tendemos a glorificar a “centralização no cliente”, mas ser centrado no cliente não significa obedecê-los cegamente. Significa compreender problemas comuns e resolvê-los de forma elegante, replicável e sustentável. As empresas que vão longe são mais parecidas com uma ferrovia – mesma bitola para todos – do que com um protótipo de garagem.
Se hoje você está tentado a aceitar aquela “pequena” variação que parece ser a chave para sua próxima Série A, pergunte-se:
Estou apostando na renda imediata em detrimento de hipotecar minha capacidade de inovar amanhã?
Às vezes, perder um cliente é, na verdade, ganhar o futuro. E acredite: dizer não na hora certa foi a decisão mais lucrativa que tomamos naquela “casa” bagunçada. Espero que as cicatrizes dessas outras pessoas impeçam você de ter algumas das suas.
*O impacto no faturamento pode ser um pouco diferente (mas nessa magnitude de grandeza). Durante nossas análises chegamos a dados alarmantes. Grande parte do desenvolvimento ad-hoc não foi pago, ou seja, havia clientes importantes com algo customizado, mas a grande maioria eram clientes de baixo ticket.
