As 14 dores de criar um sistema de billing próprio

• Sistemas de pagamento e faturamento são essenciais para monetização, mas são sistemas centrais complexos que envolvem finanças, produto, suporte ao cliente, jurídico, compliance e vendas, então até uma falha pequena pode virar um grande problema operacional
• Empresas em estágio inicial ou times de novos produtos tendem a ver billing como um problema de engenharia e acabam tentando construir por conta própria, mas na prática as opções se dividem entre solução própria, third-party ou híbrida
• Um sistema de billing real precisa lidar ao mesmo tempo com idempotência, tratamento de datas, medição de uso, impostos, reembolsos, hierarquias de clientes, contratos customizados, mudanças de preço e reconhecimento de receita
• Alguns problemas, depois de resolvidos uma vez, ficam estáveis, mas regras tributárias, erros de clientes, correções manuais e exigências de faturas por país continuam crescendo conforme a empresa expande e se globaliza
• É mais seguro focar nas atualizações de uso específicas do produto e nos eventos do ciclo de vida do cliente, e deixar assinatura, cobrança, contabilidade e reconhecimento de receita para sistemas prontos de billing e ERP sempre que possível

---

Por que billing não é uma funcionalidade simples

• Sistemas de pagamento e faturamento são indispensáveis para que o negócio gere receita
• Quando tudo funciona normalmente, eles passam despercebidos, mas na prática são um sistema-polvo que toca várias áreas e funções ao mesmo tempo
  • finanças
  • produto
  • experiência do usuário
  • suporte ao cliente
  • clientes
  • jurídico
  • compliance
  • vendas
• Se uma parte quebra, os problemas podem se espalhar rapidamente para as áreas conectadas, e isso acontece com frequência na prática
• Se a empresa não consegue cobrar sua receita de forma legal e correta, os problemas que os operadores do negócio precisam administrar aumentam muito

Três padrões de implementação

• Sistemas de billing normalmente seguem três abordagens
  • construir internamente
  • sistema third-party completo
  • híbrido entre solução própria e third-party
• Empresas em estágio inicial ou times começando um novo produto tendem a querer fazer isso sozinhos porque têm engenheiros e querem manter tudo simples
• Quando billing é visto como “um problema de colocar um arquivo de cobrança no S3 e um trabalho CRON buscar e processar o pagamento”, ele acaba sendo interpretado erroneamente apenas como um problema de engenharia
• Assim como não se implementa segurança ou tratamento de datas do zero, também é melhor não construir billing inteiro por conta própria desde o início
• O melhor sistema de billing é aquele que você nunca precisou construir totalmente sozinho

As 14 dores de um sistema de billing próprio

• Idempotência

  • Toda solicitação de cobrança e captura de pagamento precisa ser única e idempotente
  • Esse problema aparece quando há retries por limite de API ou quando se aumenta o número de instâncias do sistema de pagamento
  • Se isso não for tratado corretamente, surge o risco de cobrança duplicada

• Tratamento de datas

  • É preciso decidir se a cobrança será feita a cada 30 dias ou todo mês com base na data de assinatura
  • Também é necessário lidar com condições como ano bissexto e fuso horário

• Cálculo proporcional e saldo residual

  • É preciso decidir se o cálculo proporcional vale só para upgrade ou também para downgrade
  • Há opções como reembolso, crédito, ignorar a diferença ou bloquear upgrade e downgrade

• Medição de uso

  • A forma de calcular uso pode variar de dezenas de maneiras
  • Ela pode mudar por tipo de cliente ou ser alterada com frequência

• Formato de fatura

  • Quando se opera em um único país, isso pode parecer simples
  • Ao expandir, é preciso lidar não só com sales tax, mas também com VAT, GST e encargos adicionais por país
  • Pode ser necessário manter templates separados para cada mercado

Complexidade crescente em B2B e expansão global

• Hierarquias complexas de clientes

  • Clientes B2B, em especial, podem querer gerenciar relações de cobrança envolvendo subsidiárias e parceiros
  • É preciso uma forma de agregar o uso ao pagador real
  • Essas exigências muitas vezes só aparecem depois do crescimento e da expansão
  • Se a entidade legal do cliente ou o local de uso forem diferentes, os impostos podem mudar
  • Pode haver obrigação legal de separar cobrança e invoice
  • As regras relacionadas podem mudar a cada poucos meses

• Cobrança e prevenção de churn

  • É preciso decidir em que momento desistir de tentar cobrar novamente
  • Quando ocorre um chargeback, é preciso decidir se a conta será encerrada, suspensa ou reembolsada

• Pausa e retomada

  • Quando o cliente pausa a assinatura, é preciso decidir qual nível de acesso continuará permitido

• Créditos e reembolsos

  • Se você só faz reembolso integral, o cenário é relativamente simples
  • Quando surgem erros parciais, pode ser necessário escolher entre reembolso parcial e crédito na loja
  • Também é preciso decidir separadamente se os créditos expiram ou não

Impostos, contratos e erro humano

• Tratamento tributário

  • Só o fato de itens diferentes terem alíquotas diferentes já traz complexidade
  • Em escala global, alíquotas e regras tributárias mudam com frequência

• Contratos customizados

  • Se a empresa opera apenas com PLG, isso pode não ser um problema
  • Quando começa a fechar contratos, exceções e condições especiais que não se encaixam nas premissas existentes aparecem rapidamente

• Erro humano

  • Clientes cometem erros, e isso exige correções posteriores
  • Dentro da empresa também é possível configurar errado os dados do cliente e precisar corrigir depois
  • Emitir créditos e reemitir faturas consome muito tempo
  • Mudanças nas informações legais do cliente também precisam ser tratadas
    • endereço
    • VAT ID etc.

• Mudanças seletivas de preço

  • Mudanças de preço muitas vezes não se aplicam a todos os clientes
  • Quando valem só para novos clientes, é preciso manter versões diferentes de preço para honrar contratos antigos

• Reconhecimento de receita e receita acumulada

  • As regras de reconhecimento de receita do IFRS-15 têm uma especificação em PDF de 64 páginas
  • Se você também fizer por conta própria a integração customizada com ERP, a complexidade aumenta ainda mais

Problemas que acabam uma vez e problemas que continuam crescendo

• Alguns problemas mudam com muito mais frequência do que parece, enquanto outros quase nunca precisam ser revisitados depois de resolvidos uma vez
• Idempotência é um exemplo de problema de engenharia que, uma vez resolvido, raramente precisa ser mexido de novo
• Regras tributárias mudam com frequência no mundo todo
  • Quanto mais países a empresa atende, mais legislações fiscais precisa acompanhar
• Erros de clientes acontecem de forma relativamente constante
  • E ganham escala conforme a empresa cresce
  • Exigindo mais suporte ao cliente e mais correções manuais
• No começo, billing parece um problema de engenharia, mas na prática ele está enraizado em um espaço de problemas complexo que até profissionais experientes do setor têm dificuldade de dominar

Áreas que não precisam ser construídas do zero

• É melhor delegar para sistemas externos o maior número possível de problemas de billing
• A recomendação é comprar o máximo possível de soluções prontas
• Boa parte da área de assinatura e cobrança pode ser tratada por sistemas de billing
  • Solvimon
  • Orb
  • Lago
• Reconhecimento de receita e contabilidade devem ficar, de preferência, com recursos já existentes no ERP em uso ou em outros sistemas
• O time de produto deve focar apenas nas partes específicas do produto, como atualizações de uso e eventos básicos do ciclo de vida do cliente

[GN⁺]

Opiniões no Hacker News

• É um bom texto para quem precisa tomar decisões sobre cobrança, mas não tem muita experiência, e também é útil como referência para quem já tem experiência
  Ainda assim, eu ri bastante da frase “não dá para jogar os arquivos a serem cobrados no S3 e deixar uma tarefa CRON coletar os pagamentos?”. Na cabeça de um engenheiro, isso não é uma boa ideia em praticamente nenhuma situação
  Uma decisão de arquitetura de cobrança de que gosto é separar ao máximo, no sistema, cobrança e permissões. Se for uma assinatura pré-paga, funciona bem guardar na própria permissão apenas a data de expiração e os detalhes das permissões concedidas durante o período ativo, enquanto o sistema de cobrança armazena a assinatura e sincroniza com a parte de permissões quando necessário. Isso facilita a cobrança manual por uma pessoa, o debug e patch de problemas temporários, ou a integração com Stripe
  É claro que é preciso deixar espaço para expansão futura, mas essa decisão em si não costuma limitar muito o sistema. Não é uma ideia original minha, mas passei a gostar especialmente dela depois de tentar outras abordagens com menos sucesso

  • Pela minha experiência, engenheiros geralmente se dividem entre quem já lidou com sistemas de cobrança e quem não lidou
    Muitos problemas vêm da diferença entre pagamento e cobrança https://www.wingback.com/blog/saas-payment-vs-saas-billing. Ao conquistar os primeiros clientes, basta receber alguns pagamentos recorrentes, então é fácil começar com Stripe ou faturas manuais
    Mas, com o tempo, começam a aparecer cada vez mais clientes enterprise que precisam de permissões mais complexas, vários planos, proteção para clientes existentes e ciclos, condições e concessões de permissões de cobrança personalizados. Como cobrança muitas vezes não vira um foco técnico, pequenos hacks e recursos adicionais vão se acumulando e, no fim, viram uma bagunça que consome recursos de desenvolvimento de produto, desacelera vendas ou limita o que pode ser vendido
    A complexidade da cobrança tem muitas armadilhas e exceções escondidas, e hoje isso ficou ainda mais complexo porque a maioria dos planos inclui vários limites e componentes baseados em uso, e SaaS é vendido no mundo todo. Em empresas em estágio avançado, há até equipes de mais de 15 engenheiros dedicadas apenas a cobrança. Concordo que, se não for o núcleo do produto, você não deve criar seu próprio sistema de cobrança. Para contexto, sou CTO da Wingback, uma plataforma de cobrança para SaaS
  • Se o modelo de engenheiro pressuposto pelo lema “não faça você mesmo” é desse nível, então este texto teve o efeito oposto
    Agora fiquei com vontade de construir um sistema desses, e me sinto muito mais qualificado do que eu imaginava
  • Arnon também escreveu um bom texto justamente sobre essa separação entre cobrança e permissões
    https://arnon.dk/why-you-should-separate-your-billing-from-e...
  • Trabalhando nos últimos anos com empresas SaaS que usam a Warrant como solução de permissões de clientes, chegamos à mesma abordagem
    Os clientes armazenam permissões no nosso sistema e as verificam quando necessário; quando uma assinatura é renovada ou removida do lado do provedor de pagamentos, adicionam-se regras e permissões. Isso facilita trabalhar com um ou vários provedores de pagamento e também deixa clara a separação de responsabilidades. Compartilho também estes textos, que combinam mais com esse contexto: https://warrant.dev/use-cases/pricing-tiers-and-entitlements..., https://arnon.dk/why-you-should-separate-your-billing-from-e...
    Um sistema ideal de permissões deve ser dinâmico, ou seja, as regras devem ficar armazenadas no banco de dados; deve conseguir lidar com cenários pontuais, como clientes enterprise, e ter uma camada de políticas por cima. Por exemplo, ele deve conseguir dar suporte a praticamente todos os cenários, como plano Pro com até 5 assentos, plano Growth com determinado recurso até N vezes por dia, e assim por diante
    Uma UI que permita a pessoas não técnicas fazer alterações por cliente sem envolvimento da engenharia também é uma grande vantagem. Em funções anteriores de engenharia, isso sempre travava o time de desenvolvimento
  • A abordagem a que chegamos é parecida. Cobrança é apenas o mecanismo que calcula faturas; ela gerencia contas a receber acumulando, em um livro-razão, as faturas enviadas, os pagamentos recebidos e os ajustes
    Também há um conjunto de permissões, mas no meio existe um mecanismo de políticas que decide quando aplicar ou não aplicar essas permissões. O ponto central é que permissões não são um problema exclusivo de cobrança. O mecanismo de políticas é a cola que liga permissões a todo o resto, de modo que é possível conceder permissões a um executivo do maior cliente sem conectá-las à cobrança

• Anos atrás, criei o sistema de cobrança e contas a receber de uma pequena rede de farmácias, e as seguradoras às vezes enviavam cheques bem grandes sem nenhum aviso
  Mesmo sem termos cobrado nada, chegava pelo correio um cheque de 150 mil dólares e, só meses depois, eles percebiam o erro e pediam a devolução. Havia uma conta especial chamada magic money para colocar esse dinheiro. O mundo da cobrança é realmente um lugar insano

  • Seria uma conta de suspense, especialmente, neste caso, uma conta vinculada ao remetente. É o estado de “recebemos dinheiro desta entidade, mas ainda não sabemos por quê”
  • Fico curioso se, depois de certo tempo, existe um momento em que esse “magic money” passa legalmente a pertencer à empresa
  • Fico imaginando se o valor cobrado de outra entidade, por exemplo uma pessoa física, acabou chegando à seguradora, mas ninguém rastreou isso de volta, de modo que a dívida continuou nas contas dessas pessoas
    Será que apenas chamavam de magic money e deixavam a dívida nas contas individuais como estava?
  • Fico curioso por que eles descontavam ou depositavam esse cheque

• Acho que não é adequado abordar esse tema apenas pela dor de criar um sistema de cobrança por conta própria. Se muitas empresas querem seguir esse caminho, que sigam.
  Reconheço que sistemas de cobrança são muito complexos. Mas, se Chargebee, Solvimon, Stripe, Recurly, Orb, Metronome, Lago, Togai etc. têm esse conhecimento, também dá para reunir esse conhecimento em um só lugar.
  No fim, a resposta certa é a abordagem que funciona para você. Se for um SaaS baseado em assinatura, há uma solução adequada para isso; se for uma API baseada em uso, há uma solução de cobrança adequada para esse caso.
  Em vez de desencorajar a prática, dá para reunir em um só lugar conhecimento, abordagens, paradigmas, padrões de programação, boas práticas e melhores práticas. Também há exceções de empresas fora dos EUA ou da Europa que não podem usar soluções de cobrança como a Stripe. Por exemplo, se você é uma empresa da Venezuela e não consegue criar uma conta na Stripe, no fim terá de criar sua própria solução de cobrança e conectá-la à obscura API SOAP-XML de um gateway de pagamento local.
  Separadamente, “criar seu próprio sistema de cobrança” me parece parecido com “criar seu próprio SIEM” usando uma configuração Elastic + Grafana. Não recomendo, mas entendo por que tantos departamentos de segurança de TI acabam indo por esse caminho.

  • Este texto trata sistemas de cobrança de uma forma interessante. Alguns dos temas apresentados como problemas parecem ser coisas que deveriam ser repassadas a um contador ou a outro especialista que a empresa provavelmente já emprega.
    Sistemas de cobrança são menos complexos do que aquilo com que desenvolvedores costumam lidar. O texto retrata requisitos legais difíceis como obstáculos, mas, na prática, isso também significa que as especificações são fáceis de encontrar e bem documentadas. Há partes que mudam com frequência, mas essas partes também são bem rotuladas e explicadas.
    Concordo que há formas de cobrança adequadas para SaaS baseado em assinatura e para APIs baseadas em uso. A questão, porém, é se você vai permitir que o cliente transfira o ônus da responsabilidade, se a receita é importante o bastante para justificar a validação e se você consegue arcar com taxas ou perdas.

• Uma coisa que este texto não aborda é venda por afiliados, que pode dar bastante trabalho dependendo de quão profundamente você a implementa.
  É um sistema que permite que outras pessoas recebam pagamentos baseados em comissão por vendas dentro da plataforma.
  Você precisa rastrear códigos de afiliado até a venda e o usuário, enviar pagamentos ao provedor de pagamento configurado pelo afiliado e, para fazer direito, também oferecer uma UI em que ele possa ver métricas de visitantes, taxas de conversão e histórico de pagamentos.
  Felizmente, dá para construir a maior parte disso de forma incremental. Basta associar um código único a um usuário e associar esse código a uma venda com uma taxa de comissão específica; o restante pode ser tratado manualmente ou omitido. Por exemplo, eu pago afiliados uma vez por mês via Zelle ou PayPal, e isso leva menos de 10 minutos. Não há frontend de rastreamento de conversões, e ninguém deixou de participar do programa de afiliados por causa disso.

• O que foi realmente impressionante foi a necessidade de fazer toda essa máquina de Rube Goldberg funcionar ao contrário.
  Você quer manter o “pedido” o mais estático possível, e a “fatura” ainda tem obrigações legais.
  Por exemplo, imagine que alguém comprou 5 unidades e recebeu um desconto, mas agora só quer 3, e havia um erro de digitação no nome e no endereço. Sem problema: você cancela a fatura, cria uma nova fatura pelo mesmo valor com o nome e o endereço corrigidos, espera a devolução chegar e ser inspecionada, então emite outro crédito e cria mais uma nova fatura.
  O envio de devolução fica em um estado ambíguo por um tempo, o cliente pede mais 5 unidades, uma chega quebrada e ele quer reembolso em vez de substituição. As datas de entrega foram divididas em duas, então o sistema não aplica o desconto para 5 ou mais unidades. Aquilo que no começo parecia simplesmente 2 pedidos se transforma rapidamente em inúmeras transações e documentos. O cliente também esqueceu a senha e criou uma nova conta com outro e-mail. Um ano depois, ao olhar os logs, fica difícil entender por que ele recebeu desconto se comprou apenas 3 unidades.

• Não sei se concordo com esse conselho. Metade dos recursos mencionados no texto pode nem ser necessária, e dá para construí-los de forma suficientemente gradual conforme o negócio cresce
  É preciso entender conceitos como faturas, créditos, período fiscal e alterações com cálculo proporcional. Mas esse conhecimento não é necessariamente um motivo para terceirizar ou comprar; é material para tomar melhor a decisão entre construir e comprar
  Para um SaaS, a única API externa necessária é um processador de cartão de crédito; se quiser caprichar, talvez duas. Claro que, depois do primeiro ano, vai surgir muito trabalho manual, o contador vai apontar erros idiotas e você também vai aprender bastante contabilidade
  Mesmo assim, se eu começasse um novo negócio hoje, compararia várias soluções, mas tenho certeza de que construir por conta própria não é tão assustador assim

  • Como alguém que já construiu e integrou sistemas de cobrança, isso soa como algo dito a partir de uma ignorância feliz
    Construir um sistema sempre parece fácil, e no primeiro dia de fato é fácil. Mas logo você estará gastando muito tempo explicando ao responsável financeiro por que os relatórios estão completamente bagunçados, e à equipe de suporte por que a fatura falhou, por que a assinatura cobrou o preço errado e várias situações de exceção cuja existência você nem sabia
    Depois, será preciso se adequar a regulamentações que mudaram, ou o gateway escolhido pode não dar suporte a uma região em que você está crescendo
    Antes de dizer “é só construir melhor”, lembre-se de que isso também é tempo. Tempo que não foi usado no produto, tempo que não foi usado para melhorar o modelo de preços e tempo gasto patinando em vez de fazer o negócio crescer
  • Seja qual for o caminho escolhido, primeiro converse com um contador para verificar quais informações precisam obrigatoriamente estar associadas aos pagamentos por exigência legal
    O resto você pode ignorar, mas, se depois não conseguir calcular impostos ou acabar violando leis de KYC, vai ser muito complicado
    Além disso, o fato de um sistema ser mais caro do que o esperado e ser usado por muitas empresas que parecem inteligentes não significa que ele sirva ao seu propósito. Muito menos garante que sirva especificamente ao que você quer. Comprar não significa que você possa deixar de pesquisar
  • O ponto central de um SaaS B2B é que o dinheiro vem de vendas caras e muito manuais, e essas vendas geram requisitos
    O objetivo de quem lida com esse tipo de cobrança é simples. É preciso oferecer opções adequadas para que a equipe de vendas consiga fechar contratos. Você precisa trabalhar com vendas para descobrir qual é a área “fácil de implementar e suficiente para fechar o contrato”
    Nunca é demais enfatizar isso. A equipe de vendas está de fato gerando receita. Não adianta ficar reclamando porque o sistema de cobrança não é perfeito. Pode ser chocante, mas, quando há uma relação comercial em jogo, às vezes é preciso arregaçar as mangas e fazer manualmente
    Faça da forma mais simples possível, mas o sistema precisa ser legível e compreensível para outras equipes da empresa e permitir ajustes manuais com facilidade mesmo quando a automação estiver rodando. Uns 80% do motivo pelo qual o Stripe parece bom de usar está nisso. Ajuste manual faz parte da vida e, em alguns negócios, mesmo que seja raro, uma hora será necessário
  • Ao expandir para vários países e moedas, estão subestimando o quanto até gerenciar preços de pacotes de assinaturas fica difícil
    Cálculo proporcional, cronogramas de cobrança diferentes, períodos de teste, testes de novos preços, preços por região, impostos por região, listagem de pacotes em várias moedas e implantação de novos preços de repente viram uma combinação de 6 moedas × X regiões × Y produtos × Z cronogramas de cobrança × L idiomas
    Some a isso adicionar novas assinaturas, mesclar planos de assinatura, encerrar planos antigos enquanto move os clientes suavemente para novos planos alternativos e se comunicar bem com eles. Se for SaaS, quase tudo precisa ser bem automatizado, self-service e testado; caso contrário, você vai morrer afogado em suporte ao cliente e churn
  • Isso pressupõe que existe tempo para construir por conta própria. Somos uma empresa de 35 funcionários, com 300 mil clientes de SaaS B2C de baixo preço, e estamos tão ocupados criando produto e corrigindo bugs que temos basicamente 0 minuto para expandir o sistema de cobrança ou implementar contratos personalizados
    A implantação de mudanças de preço pode levar de 3 dias a 2 meses, e lidar com os vestígios dos contratos personalizados do início é um pesadelo. Se não der para automatizar facilmente, não conseguimos fazer. Leva tempo demais
    Se tivéssemos baseado a cobrança em algo como os produtos mencionados aqui, provavelmente conseguiríamos lidar muito melhor com contratos personalizados por segmento de cliente e implantações de mudanças de preço

• Há 2 problemas que já enfrentei diretamente e que não foram tratados aqui
  O primeiro é o fechamento mensal e trimestral. O texto fala de razão contábil, mas, quando você começa a lidar com empresas listadas em bolsa que precisam reportar números, há momentos de fechamento rigorosos e tudo precisa acontecer sem atritos
  O segundo é a contabilidade de caixa em trânsito. Este texto pressupõe que o processador de pagamentos é 100% preciso e não tem problema algum. Quando você cresce o suficiente, precisa conseguir reconciliar todo o dinheiro que entrou na conta bancária com uma fatura ou item de cobrança específico. Também precisa encontrar faturas sem uma linha correspondente no extrato bancário e, no sentido inverso, lidar com casos em que entra dinheiro que não está vinculado a nenhum item de fatura. A capacidade de lidar com créditos em conta bancária que não estão ligados a uma fatura de cobrança também é importante
  Dá para dizer que tudo isso é problema do departamento contábil, mas é algo muito acoplado ao sistema, então as duas equipes precisam trabalhar juntas para garantir que não haja divergências entre os livros

  • Qualquer pessoa que já tenha tido algum contato com contabilidade perto de uma grande empresa de capital aberto provavelmente sentiu um arrepio só de ouvir fechamento mensal e trimestral
    Contadores de verdade precisam ficar repetidamente até meia-noite por causa do fechamento, e quem é de tecnologia ou negócios passa pela situação de precisar receber algo da contabilidade, mas, durante o período de fechamento, a equipe contábil parece ter desaparecido da face da Terra. É a mesma coisa quando você vive isso como membro da família
  • Se você não reconciliar depósitos bancários e itens de cobrança desde o início, não há esperança de acertar os impostos corretamente
    A contabilidade interna e a conta bancária vão se desalinhando aos poucos, e o contador não saberá por onde começar a procurar o problema

• Fico curioso para saber o que todo mundo usa para gerenciamento de permissões. Se usam um sistema de feature flags, um SaaS separado como o Stigg, ou se mantêm um sistema interno próprio.
  Vim ao HN esta manhã justamente porque escrevi um texto sobre usar feature flags para gerenciamento de permissões: https://prefab.cloud/blog/modeling-product-entitlements-with.... Também me inspirei no texto do Arnon sobre formatos de SKU.
  Feature flags não parecem o lugar perfeito para gerenciamento de permissões, mas, pela minha experiência, ao lidar com esse tipo de problema, muitas vezes foram a melhor ferramenta disponível. Gostaria de ouvir outras opiniões.

  • Nós usamos uma combinação de limites numéricos, por exemplo número diário de chamadas de API, e flags de produto em forma de array de tags.
    Esses limites e flags ficam vinculados a um “plano”, e o plano pode ser vinculado a uma conta. Quando combinamos planos, os valores numéricos ficam com o maior valor, e as tags são unidas como conjunto. Além disso, é possível sobrescrever ou adicionar valores por conta; então, se um cliente precisa do PlanX, mas com uma cota de API personalizada, basta sobrescrever diretamente esse único valor na conta.
    Podem chamar de antiquado, mas não vejo por que terceirizar isso para um terceiro.
  • Estamos criando agora uma solução para algo parecido com permissões de plano.
    A solução básica é possível com feature flags, mas permissões relacionadas a cobrança e preço, por exemplo a organização e a evolução de planos e edições, ficam complexas com o tempo por causa de muitos requisitos adjacentes. Basta pensar nas várias combinações de recursos, seats, estratégias baseadas em uso e medição, assinaturas de equipe, migração de planos, planos enterprise pontuais, clientes com várias assinaturas, períodos promocionais e assinaturas em camadas, agregação de uso, upsell automático etc.
    Como aparece no texto, dá para representar limites com flags que têm valores numéricos, mas a infraestrutura de rastreamento de uso ainda precisa ser implementada pelo próprio negócio. Em vez disso, imagine exportar esse uso para um serviço de permissões, e permissões baseadas em uso sendo atualizadas em tempo real também entre equipes. Além disso, outras permissões que dependem delas também poderiam ser atualizadas. Ao se aproximar ou ultrapassar um limite, é possível escolher entre um limite flexível, que permite continuar usando mas avisa a equipe de vendas, ou um limite rígido, que exibe uma orientação de upgrade.
    Assim como a ideia do texto original, nós funcionamos junto com soluções de cobrança existentes, em vez de recriar a cobrança. Estamos em bootstrap a partir de um exit anterior bem-sucedido e trabalhando com clientes iniciais; se alguém quiser apenas conversar sobre esse tema, pode entrar em contato em trent at planship.io.
  • Feature flags são um daqueles sistemas bonitos que têm exatamente expressividade suficiente para dar vontade de encaixá-las à força em tudo.
    Dá para construir tudo com feature flags: lançamentos beta, autenticação baseada em papéis, permissões de cobrança e até solicitações pontuais de clientes. As melhores feature flags também podem, opcionalmente, ter valores associados; então limites de planos de API também podem virar feature flags.
    Se isso é o melhor? Para cada caso de uso específico, provavelmente não. Mas, depois de criar uma vez, a tentação de usar em todo lugar é grande.
  • Acho que “permissões por feature flags” pode funcionar bem se for tratado de forma claramente diferente das feature flags que engenheiros normalmente usam, isto é, pequenas mudanças incrementais, testes, deploys e testes A/B.
    Permissões precisam estar claramente ligadas a funcionalidades visíveis ao cliente e, conceitualmente, são blocos de funcionalidade muito maiores. A dificuldade dessa abordagem é que ainda é preciso considerar muitos aspectos relacionados a cobrança. Tratamento de clientes inadimplentes, cobranças excedentes ao ultrapassar certos limites, vários modelos de preço para a mesma funcionalidade, zerar ou carregar contadores de uso ao mudar ou fazer upgrade de plano etc. acrescentam muita complexidade com o tempo.
    Por isso, na Wingback decidimos oferecer permissões de funcionalidades separadas, fortemente acopladas à cadeia de cobrança e à medição. Para contexto, eu sou o CTO. No fim, acho que ambas as abordagens podem funcionar bem, dependendo da complexidade dos planos e de quanto vocês já investiram em feature flags. Ter gating de funcionalidades para clientes torna muito mais fácil provisionar contas de clientes e oferecer pacotes personalizados.

• Tenho dificuldade em aceitar a estrutura geral do argumento “o sistema X é muito complexo, então não construa o seu; use uma solução pronta”.
  A solução geral para X pode ser extremamente difícil e complexa, mas o meu caso de uso precisa apenas de partes específicas dessa complexidade. Então posso criar uma solução própria que trate só da complexidade necessária, e ela pode ser muito mais simples que uma ferramenta pronta.
  Eu adoto completamente essa posição para data e hora. Na minha abordagem de data e hora, a biblioteca só precisa oferecer duas chamadas de função: uma que transforme o tempo epoch em uma string de horário no formato ISO em um fuso horário específico, e a função inversa. Não toco em nenhum outro código da biblioteca; o restante das manipulações de tempo eu trato no meu próprio código com base nessas duas funções.

  • Quando há dinheiro circulando em cobrança, a margem de tolerância a erro é muito estreita, e também há regulação.
    Desde o começo, é preciso entender o que se deve e não se deve fazer no tratamento de dados pessoais, ciclos e ciclo de vida de várias opções de cobrança, limites de reembolso, suporte a idempotência, gerenciamento razoável de transações de banco de dados com um modelo adequado à tarefa, emissão de invoices e exposição ao cliente.
    Nem tudo é necessário de uma vez, mas até a primeira implementação funcional precisa de pelo menos metade disso.

• Dá uma sensação de “14 dores de atravessar a rua e por que você deveria comprar e ler meu livro”.
  Muita gente acha que é uma boa ideia fechar os olhos e começar a andar, e acaba se machucando ou morrendo cedo demais.
  As regras para atravessar a rua variam de país para país, e até de cidade para cidade. Talvez você ainda não saiba, mas precisa olhar para os dois lados. Muitas pessoas morrem ou se ferem porque não sabem que são daltônicas e não conseguem distinguir vermelho de verde. Você olhou para os dois lados, mas olhou para cima? Na cidade, objetos caem de janelas; no campo, pássaros podem voar sobre a sua cabeça; e cada vez mais lixo espacial também está caindo na Terra. Objetos podem vir de várias direções.
  Não estou dizendo que este texto seja tão ruim assim, mas teria sido melhor se fosse estruturado como um texto de metodologia. Eu teria muito mais vontade de ler algo assim do que um texto construído de forma negativa.

  • Trabalho atualmente em uma equipe de cobrança. Não passei a maior parte da minha carreira em cobrança, mas este texto está correto.
    É o tipo ideal de projeto de brincadeira “quão difícil pode ser?”, o problema é que tudo isso é verdade.
    Há exemplos incontáveis, mas, se você abordar o problema do jeito errado, logo vai se deparar com a pergunta “quanto o cliente deve pagar?”, seguida de “por que cobramos este valor, e não outro?”. Se isso acontecer com frequência demais, a equipe financeira vai aparecer perguntando o que você fez para tornar pouco confiáveis os relatórios de operação da empresa — e até relatórios que determinam demissões.