Quando um SaaS oferece vários planos, é tentador resolver cada diferença com uma condição no código: se o cliente tem o plano avançado, mostrar esta opção; caso contrário, ocultá-la. Essa abordagem funciona no início, mas se torna frágil quando surgem mudanças de assinatura, complementos, testes temporários e exceções comerciais. A pergunta deixa de ser qual botão mostrar e passa a ser quais capacidades uma conta tem, quem pode usá-las e em quais condições.
Um modelo claro separa as decisões comerciais das regras aplicadas pelo produto. Assim, fica mais fácil alterar a oferta, testar uma transição e manter um comportamento coerente na interface, na API e nas tarefas internas. Este guia apresenta critérios para projetar esse modelo e identificar quando o atual precisa ser simplificado.
O plano não deve ser uma regra direta da aplicação
Um plano é uma forma de apresentar e vender uma oferta. Ele pode agrupar capacidades e limites, mas não deve se tornar a única fonte de verdade para decidir cada operação. Se a aplicação perguntar repetidamente se uma conta pertence ao plano «Pro», a lógica ficará vinculada a nomes comerciais que podem mudar, mesmo que a capacidade continue existindo.
É melhor traduzir a assinatura em um conjunto explícito de direitos efetivos. Por exemplo, uma conta pode ter a exportação habilitada, um número máximo de projetos e acesso a uma integração. O produto avalia esses direitos, e não o rótulo de marketing. Dessa forma, mudar o nome ou a composição de um plano não exige revisar todas as partes da aplicação que mencionam esse plano.
Esse desacoplamento também facilita ofertas fora do padrão. Duas contas com planos diferentes podem compartilhar uma capacidade; uma conta pode ter um complemento contratado, mesmo tendo o mesmo plano que outra. A solução não é acrescentar mais ramificações condicionais, mas representar explicitamente o resultado de que o produto precisa.
Separe funcionalidades, limites e permissões
Antes de escolher uma arquitetura, diferencie quatro conceitos que costumam ser confundidos:
- Plano: oferta comercial atribuída a uma conta, com condições e período de vigência.
- Funcionalidade habilitada: capacidade disponível para a conta, como exportar dados ou usar uma integração.
- Limite de uso: quantidade máxima ou cota aplicável a um recurso, como usuários, projetos ou armazenamento.
- Permissão: ação que uma pessoa específica pode executar na conta, de acordo com sua função ou configuração.
Uma funcionalidade pode estar incluída na assinatura e, ainda assim, não ser permitida a todos os usuários. No sentido inverso, alguém pode ter permissão para gerenciar projetos, mas a conta pode ter atingido o limite. Por isso, autorizar uma operação pode exigir a verificação do direito da conta, da permissão individual e do estado do recurso.
Defina também o significado de cada limite. «Até 10 projetos» pode se referir a projetos ativos, criados durante um período ou existentes no total. Esclareça quando o contador é reiniciado, o que acontece quando o máximo é atingido e como tratar dados que já excedem o limite após uma mudança de plano. Se essas regras ficarem implícitas, a equipe acabará tomando decisões diferentes nas telas e nos processos.
Onde representar as regras
O local adequado depende da complexidade e de quem precisa alterar a oferta. Para um produto com poucos planos e mudanças pouco frequentes, uma configuração versionada junto com a aplicação pode ser suficiente. É uma opção simples de revisar e testar, desde que as regras não sejam repetidas em muitos lugares.
Quando a equipe de negócios precisa ajustar a composição dos planos sem implantar código, pode fazer sentido armazenar o catálogo e as atribuições em uma fonte de dados administrável. Isso traz novas responsabilidades: controlar quem edita a configuração, validar as mudanças e manter um histórico que permita explicar quais regras estavam em vigor em determinada data. A edição dinâmica não é vantajosa se qualquer alteração puder deixar contas em estados incoerentes.
Uma terceira opção é o sistema de assinaturas registrar produtos, períodos e complementos, enquanto o produto mantém uma representação interna dos direitos efetivos. Não é recomendável que cada tela consulte diretamente o sistema de faturamento: além de acoplar componentes, isso pode gerar resultados diferentes em caso de atrasos ou falhas de sincronização. Defina qual é a fonte de verdade para cada dado e como a outra fonte será atualizada.
Em qualquer uma dessas alternativas, evite implementar o mesmo significado de forma independente na interface, na API e nos processos em segundo plano. Centralize a avaliação de acesso em uma camada reutilizável e documente seu contrato. A interface pode antecipar ao usuário que uma opção está indisponível, mas a API deve validar a operação novamente; ocultar um controle não constitui autorização.
Modele mudanças, transições e complementos
Uma assinatura muda com o tempo. Pode haver uma data futura de vigência, um período de teste, uma renovação pendente ou um cancelamento programado. Armazene o estado e as datas relevantes e defina quais direitos se aplicam antes e depois do momento da transição. Evite basear a decisão apenas em um rótulo atual se a conta já tiver uma mudança acordada para uma data futura.
Para cada mudança de plano, responda explicitamente:
- Quando a mudança será aplicada: imediatamente, no fim do período ou em uma data acordada?
- O que acontece com os recursos que excedem o novo limite?
- A criação de itens será bloqueada, outras ações serão restringidas ou será necessária alguma intervenção?
- Como o estado será comunicado ao administrador da conta?
Não exclua nem altere dados automaticamente como reação genérica a uma redução de plano. Decida quais ações serão restringidas e como a operação normal poderá ser retomada. Para uma funcionalidade contratada separadamente, represente o complemento como um direito independente, com sua própria vigência quando aplicável; assim, não será necessário criar um novo plano para cada combinação.
Exceções por cliente: explícitas, limitadas e revisáveis
Exceções podem ser legítimas: um projeto-piloto, uma compensação ou uma necessidade contratual. O risco surge quando elas são implementadas como condições especiais espalhadas pelo código ou como alterações manuais sem responsável nem data de revisão.
Registre cada exceção com o cliente ou a conta afetada, a capacidade ou o limite alterado, o motivo, quem a aprovou e seu período de vigência. Se for temporária, defina desde o início como ela expirará e qual comportamento será adotado após o vencimento. Uma exceção sem data pode se tornar parte permanente do produto sem que ninguém se lembre do motivo.
Antes de adicionar outra exceção, verifique se ela revela uma necessidade mais ampla do produto. Se várias contas precisam do mesmo complemento, pode ser melhor oferecê-lo como uma opção. Se uma regra depender de uma obrigação contratual, mantenha-a identificável e separada da lógica geral. O objetivo é permitir que a equipe explique e revise o estado de uma conta sem procurar condições dispersas.
Testes, diagnóstico e migração
Teste não apenas a atribuição inicial, mas também as mudanças de estado e seus efeitos. No mínimo, cubra uma capacidade habilitada e outra indisponível, um limite imediatamente antes e depois de ser atingido, uma mudança de plano pendente, um complemento que vence e uma exceção expirada. Verifique a mesma decisão na interface, na API e nos processos internos que criam ou alteram recursos.
Registre informações suficientes para diagnosticar por que uma operação foi permitida ou recusada: conta, direito avaliado, limite relevante e resultado. Evite incluir dados sensíveis desnecessários. A mensagem compreensível para o usuário pode ser diferente do detalhe técnico, mas ambas devem corresponder à mesma decisão efetiva.
Há sinais de que o modelo precisa ser revisto: muitas verificações pelo nome do plano, divergências entre telas e API, exceções sem responsável, limites cujo significado ninguém consegue definir ou mudanças comerciais que exigem editar várias áreas do produto. Para migrar, primeiro faça um inventário das regras existentes; depois, defina direitos e limites com nomes estáveis, centralize a avaliação e compare seus resultados com o comportamento atual em casos representativos. Faça a migração por etapas e mantenha um mecanismo para detectar diferenças antes de remover a lógica antiga.
A decisão prática é modelar o que o produto permite, não o nome que a equipe de vendas dá a cada oferta. Planos e faturamento podem mudar; as capacidades efetivas, os limites e as permissões precisam continuar compreensíveis, verificáveis e coerentes em todos os pontos de acesso.