Esquema de banco de dados para planos e permissões que suporta upgrades e complementos

Por que planos e recursos ficam bagunçados rapidamente

Planos parecem simples numa página de preços: Basic, Pro, Enterprise. A confusão começa no momento em que você tenta transformar esses nomes em regras reais de acesso dentro do seu app.

Hardcoding de verificações de recursos (como if plan = Pro then allow X) funciona na primeira versão. Aí o preço muda. Um recurso sai do Pro e vai para o Basic, um novo complemento aparece, ou um acordo de vendas inclui um bundle personalizado. De repente você tem a mesma regra copiada em APIs, UI, apps móveis e jobs em segundo plano. Você altera um lugar e esquece outro. Usuários notam.

Um segundo problema é o tempo. Assinaturas não são um rótulo estático; elas mudam no meio do ciclo. Alguém faz upgrade hoje, faz downgrade no mês seguinte, pausa ou cancela com tempo pago restante. Se seu banco de dados só armazena “plano atual”, você perde a linha do tempo e não consegue responder perguntas básicas depois: o que eles tinham acesso na terça passada? Por que o suporte aprovou um reembolso?

Complementos pioram porque atravessam planos. Um add-on pode desbloquear assentos extras, remover um limite ou habilitar um recurso específico. Pessoas podem comprá-lo em qualquer plano, removê-lo depois ou mantê-lo após um downgrade. Se a regra está embutida no código, você acaba com uma pilha crescente de casos especiais.

Aqui estão as situações que normalmente quebram designs ingênuos:

• Upgrade no meio do ciclo: o acesso deve mudar imediatamente, a prorrogação da cobrança pode seguir regras diferentes.
• Downgrade agendado: o acesso pode permanecer “maior” até o fim do período pago.
• Grandfathering: clientes antigos mantêm um recurso que novos clientes não têm.
• Acordos personalizados: uma conta recebe o Recurso A mas não o Recurso B, mesmo compartilhando o mesmo nome de plano.
• Necessidade de auditoria: suporte, finanças ou compliance perguntam “o que exatamente estava habilitado e quando?”

O objetivo é simples: um modelo flexível de controle de acesso que acompanha mudanças de preço, sem reescrever a lógica de negócio a cada vez. Você quer um único lugar para perguntar “eles podem fazer isso?” e um rastro no banco de dados que explique a resposta.

Ao final deste artigo, você terá um padrão de esquema que pode copiar: planos e complementos viram entradas, e permissões (entitlements) viram a fonte única de verdade para acesso a recursos. Essa mesma abordagem também funciona em construtores no-code como o AppMaster, porque você mantém as regras em dados e as consulta de forma consistente do backend, app web e apps móveis.

Termos-chave: plano, complemento, permissão (entitlement) e acesso

Muitos problemas de assinatura começam como um problema de vocabulário. Se todo mundo usa a mesma palavra para coisas diferentes, seu esquema vira casos especiais.

Aqui estão os termos que vale a pena manter separados em um esquema de planos e permissões:

• Plan (plano): O bundle padrão que alguém recebe ao assinar (por exemplo, Basic ou Pro). Um plano geralmente define limites base e recursos incluídos.
• Add-on (complemento): Uma compra opcional que altera a base (por exemplo, “assentos extras” ou “relatórios avançados”). Complementos devem poder ser anexados e removidos sem alterar o plano.
• Entitlement (permissão): O resultado final, calculado: “o que eles têm agora”, após combinar plano + complementos + overrides. É isso que seu app deve consultar.
• Permission (ou capacidade): Uma ação específica que alguém pode realizar (por exemplo, “exportar dados” ou “gerenciar cobrança”). Permissões frequentemente dependem de papel + entitlements.
• Access (acesso): O resultado no mundo real quando o app aplica as regras (a tela mostra ou esconde um recurso, uma chamada de API é permitida ou bloqueada, um limite é aplicado).

Feature flags são relacionadas, mas diferentes. Uma feature flag é tipicamente um interruptor de produto que você controla (rollouts, experimentos, desligar um recurso durante um incidente). Uma entitlement é acesso específico ao cliente, baseado no que ele paga ou no que você concedeu. Use flags quando quiser mudar comportamento para grupos sem tocar na cobrança. Use entitlements quando o acesso deve corresponder a uma assinatura, fatura ou contrato.

Escopo é outra fonte de confusão. Mantenha essas ideias claras:

• Usuário: Uma pessoa. Bom para papéis (admin vs membro) e limites pessoais.
• Conta (customer): A entidade pagante. Boa para informações de cobrança e propriedade da assinatura.
• Workspace (projeto/time): Onde o trabalho acontece. Muitos produtos aplicam entitlements aqui (assentos, armazenamento, módulos habilitados).

O tempo importa porque o acesso muda. Modele isso diretamente:

• Início e fim: Uma permissão pode estar ativa apenas dentro de uma janela (trial, promoção, contrato anual).
• Mudança agendada: Upgrades podem começar agora; downgrades frequentemente começam na próxima renovação.
• Carência e cancelamento: Você pode permitir acesso limitado após falha no pagamento, mas só até uma data final clara.

Exemplo: uma empresa está no Pro, adiciona “Relatórios Avançados” no meio do mês e depois agenda um downgrade para Basic no próximo ciclo. O plano muda depois, o complemento começa agora, e a camada de entitlements continua sendo o único lugar para perguntar: “Este workspace pode usar relatórios avançados hoje?”

Um esquema central simples para planos e recursos

Um bom esquema de banco de dados para planos e entitlements começa pequeno: separe o que você vende (planos e complementos) do que as pessoas podem fazer (recursos). Se você mantiver essas duas ideias limpas, upgrades e novos complementos viram mudanças de dados, não reescritas.

Aqui está um conjunto prático de tabelas que funciona para a maioria dos produtos por assinatura:

• products: a coisa vendável (plano base, plano Team, add-on de assentos extras, add-on de suporte prioritário).
• plans: opcional, se você quiser que planos sejam um tipo especial de product com campos só de plano (intervalo de cobrança, ordem pública de exibição). Muitas equipes simplesmente armazenam planos dentro de products e usam uma coluna product_type.
• features: o catálogo de capacidades (acesso à API, max projetos, export, SSO, créditos SMS).
• product_features (ou plan_features se você separar planos): uma tabela de junção que indica quais recursos vêm com qual produto, geralmente com um valor.

Essa tabela de junção é onde mora a maior parte do poder. Recursos raramente são apenas on/off. Um plano pode incluir max_projects = 10, enquanto um complemento pode adicionar +5. Então product_features deve suportar pelo menos:

• feature_value (número, texto, JSON ou colunas separadas)
• value_type (boolean, integer, enum, json)
• grant_mode (replace vs add), para que um complemento possa “adicionar 5 assentos” em vez de sobrescrever um limite base

Modele complementos também como products. A única diferença é como são comprados. Um produto de plano base é “um por vez”, enquanto um produto add-on pode permitir quantidade. Mas ambos mapeiam para recursos da mesma forma. Isso evita casos especiais do tipo “se add-on X então habilita recurso Y” espalhados pelo código.

Recursos devem ser dados, não constantes de código. Se você hardcodar verificações de recurso em vários serviços, eventualmente terá divergências (a web diz sim, o mobile diz não, o backend discorda). Quando os recursos vivem no banco de dados, o app pode fazer uma pergunta consistente e você pode aplicar mudanças editando linhas.

Nomear importa mais do que se espera. Use identificadores estáveis que nunca mudem, mesmo que o nome de marketing mude:

• feature_key como max_projects, sso, priority_support
• product_code como plan_starter_monthly, addon_extra_seats

Mantenha rótulos de exibição separados (feature_name, product_name). Se você estiver usando o Data Designer do AppMaster com PostgreSQL, tratar essas chaves como campos únicos compensa imediatamente: você pode regenerar com segurança enquanto mantém integrações e relatórios estáveis.

A camada de entitlements: um lugar para perguntar “eles podem?”

A maioria dos sistemas de assinatura sai do trilho quando “o que compraram” está armazenado em um lugar, mas “o que eles podem fazer” é calculado em cinco caminhos diferentes do código. A solução é uma camada de entitlements: uma tabela única (ou view) que representa o acesso efetivo de um sujeito num ponto no tempo.

Se você quer um esquema de planos e permissões que sobreviva a upgrades, downgrades, trials e concessões pontuais, essa camada é a parte que torna tudo previsível.

Uma tabela de entitlements prática

Pense em cada linha como uma afirmação: “este sujeito tem acesso a este recurso com este valor, de tal hora até tal hora, vindo desta fonte.” Uma forma comum é:

• subject_type (por exemplo, "account", "user", "org") e subject_id
• feature_id
• value (o valor efetivo para esse recurso)
• source (de onde veio: "direct", "plan", "addon", "default")
• starts_at e ends_at (ends_at anulável para acesso contínuo)

Você pode implementar value de algumas maneiras: uma única coluna text/JSON mais value_type, ou colunas separadas como value_bool, value_int, value_text. Mantenha simples e fácil de consultar.

Tipos de valor que cobrem a maioria dos produtos

Recursos nem sempre são on/off. Esses tipos de valor geralmente cobrem necessidades reais de cobrança e controle de acesso:

• Booleano: habilitado/desabilitado ("can_export" = true)
• Número de cota: um limite ("seats" = 10, "api_calls" = 100000)
• Nível de tier: uma classificação ("support_tier" = 2)
• String: um modo ou variante ("data_retention" = "90_days")

Precedência: como conflitos são resolvidos

Conflitos são normais. Um usuário pode estar em um plano que permite 5 assentos, comprar um complemento que adiciona 10, e também receber uma concessão manual do suporte.

Defina uma regra clara e mantenha-a em todos os lugares:

1. Concessão direta (manual) tem prioridade sobre plano
2. Depois os add-ons
3. Depois os defaults

Uma abordagem simples é armazenar todas as linhas candidatas (derivadas do plano, do add-on, diretas) e computar um “vencedor” final por subject_id + feature_id ordenando pela precedência da source, depois pela starts_at mais recente.

Aqui está um cenário concreto: um cliente faz downgrade do plano hoje, mas já pagou por um add-on que dura até o fim do mês. Com starts_at/ends_at nas permissões, o downgrade entra em vigor imediatamente para recursos baseados em plano, enquanto o add-on permanece ativo até seu ends_at. Seu app pode responder “eles podem?” com uma única query em vez de lógica de caso especial.

Assinaturas, itens e acesso limitado no tempo

Seu catálogo de planos (planos, complementos, recursos) é o “o que”. Assinaturas são o “quem tem o quê, e quando”. Se você mantiver esses separados, upgrades e cancelamentos deixam de ser assustadores.

Um padrão prático é: uma assinatura por conta, e muitos subscription items sob ela (um para o plano base, mais zero ou mais complementos). Em um esquema de planos e permissões, isso te dá um local limpo para registrar mudanças ao longo do tempo sem reescrever regras de acesso.

Tabelas centrais para modelar a linha do tempo de compra

Você pode manter simples com duas tabelas fáceis de consultar:

• subscriptions: id, account_id, status (active, trialing, canceled, past_due), started_at, current_period_start, current_period_end, canceled_at (nullable)
• subscription_items: id, subscription_id, item_type (plan, addon), plan_id/addon_id, quantity, started_at, ends_at (nullable), source (stripe, manual, promo)

Um detalhe comum: armazene cada item com suas próprias datas. Assim você pode conceder um add-on por apenas 30 dias, ou deixar um plano rodar até o fim do período pago mesmo se o cliente cancelar a renovação.

Mantenha proration e cobrança fora da lógica de acesso

Proration, faturas e tentativas de pagamento são problemas de cobrança. Acesso a recursos é um problema de permissões. Não tente “calcular acesso” a partir de linhas de fatura.

Em vez disso, deixe eventos de cobrança atualizarem registros de assinatura (por exemplo, estender current_period_end, criar uma nova linha em subscription_item, ou definir ends_at). Seu app então responde perguntas de acesso a partir da linha do tempo da assinatura (e, depois, da camada de entitlements), não da matemática de cobrança.

Mudanças agendadas sem surpresas

Upgrades e downgrades costumam entrar em vigor num momento específico:

• Adicione pending_plan_id e change_at em subscriptions para uma única mudança de plano agendada.
• Ou use uma tabela subscription_changes (subscription_id, effective_at, from_plan_id, to_plan_id, reason) se você precisar de histórico e múltiplas mudanças futuras.

Isso evita hardcoding de regras do tipo “downgrades acontecem no fim do período” espalhadas pelo código. A agenda é dada por dados.

Onde os trials se encaixam

Trials são apenas acesso limitado no tempo com uma fonte diferente. Duas opções limpas:

• Tratar trial como um status de assinatura (trialing) com trial_start/trial_end.
• Ou criar itens/permissões de trial com started_at/ends_at e source = trial.

Se você está construindo isso no AppMaster, essas tabelas mapeiam bem para o Data Designer no PostgreSQL, e as datas facilitam consultar “o que está ativo agora” sem casos especiais.

Passo a passo: implemente o padrão

Um bom esquema de planos e permissões começa com uma promessa: a lógica de recursos vive em dados, não espalhada por caminhos de código. Seu app deve fazer uma pergunta: “quais são as permissões efetivas agora?” — e obter uma resposta clara.

1) Defina recursos com chaves estáveis

Crie uma tabela feature com uma chave estável e legível que você nunca renomeará (mesmo que o rótulo da UI mude). Boas chaves: export_csv, api_calls_per_month, seats.

Adicione um tipo para que o sistema saiba como tratar o valor: boolean (on/off) vs numérico (limites/cotas). Mantenha simples e consistente.

2) Mapear planos e complementos para permissões

Agora você precisa de duas fontes de verdade: o que um plano inclui e o que cada complemento concede.

Uma sequência prática simples é:

• Coloque todos os recursos em uma tabela feature com chaves estáveis e um tipo de valor.
• Crie plan e plan_entitlement onde cada linha concede um valor de recurso (por exemplo seats = 5, export_csv = true).
• Crie addon e addon_entitlement que concedem valores extras (por exemplo seats + 10, api_calls_per_month + 50000, ou priority_support = true).
• Decida como combinar valores: booleanos geralmente usam OR, limites numéricos costumam usar MAX (maior vence), e quantidades como assentos frequentemente usam SUM.
• Registre quando as permissões começam e terminam para que upgrades, cancelamentos e proration não quebrem checagens de acesso.

Se você está construindo isso no AppMaster, pode modelar essas tabelas no Data Designer (PostgreSQL) e manter as regras de combinação como uma pequena tabela de “política” ou enum usada pela lógica de Business Process.

3) Produza “permissões efetivas”

Você tem duas opções: calcular na leitura (consultar e mesclar toda vez) ou gerar um snapshot em cache quando algo muda (mudança de plano, compra de add-on, renovação, cancelamento). Para a maioria dos apps, snapshots são mais fáceis de raciocinar e mais rápidos sob carga.

Uma abordagem comum é uma tabela account_entitlement que armazena o resultado final por recurso, mais valid_from e valid_to.

4) Aplique o acesso com uma checagem única

Não espalhe regras pela UI, endpoints e jobs em segundo plano. Coloque uma função no código do app que leia as permissões efetivas e decida.

can(account_id, feature_key, needed_value=1):
  ent = get_effective_entitlement(account_id, feature_key, now)
  if ent.type == "bool": return ent.value == true
  if ent.type == "number": return ent.value >= needed_value

Uma vez que tudo chame can(...), upgrades e complementos viram atualizações de dados, não reescritas.

Cenário de exemplo: upgrade mais add-on sem surpresas

Uma equipe de suporte de 6 pessoas está no Starter. Starter inclui 3 assentos de agente e 1.000 mensagens SMS por mês. No meio do mês eles crescem para 6 agentes e querem um pacote de 5.000 SMS extra. Você quer que isso funcione sem código especial do tipo “se plano = Pro então...”.

Dia 1: começam no Starter

Você cria uma subscription para a conta com um período de cobrança (por exemplo, Jan 1 a Jan 31). Então você adiciona um subscription_item para o plano.

No checkout (ou via job noturno), você grava concessões de permissões para aquele período:

• entitlement_grant: agent_seats, valor 3, início Jan 1, fim Jan 31
• entitlement_grant: sms_messages, valor 1000, início Jan 1, fim Jan 31

Seu app nunca pergunta “em que plano eles estão?” Ele pergunta “qual é a permissão efetiva agora?” e obtém seats = 3, SMS = 1000.

Dia 15: fazem upgrade para Pro e adicionam pacote SMS no mesmo dia

Em Jan 15 fazem upgrade para Pro (inclui 10 assentos de agente e 2.000 SMS). Você não edita concessões antigas. Você adiciona novos registros:

• Fecha o item do plano antigo: seta subscription_item (Starter) fim para Jan 15
• Cria um novo item de plano: subscription_item (Pro) início Jan 15, fim Jan 31
• Adiciona um novo item add-on: subscription_item (SMS Pack 5000) início Jan 15, fim Jan 31

Então concessões para o mesmo período são acrescentadas:

• entitlement_grant: agent_seats, valor 10, início Jan 15, fim Jan 31
• entitlement_grant: sms_messages, valor 2000, início Jan 15, fim Jan 31
• entitlement_grant: sms_messages, valor 5000, início Jan 15, fim Jan 31

O que acontece imediatamente em Jan 15?

• Assentos: os assentos efetivos passam a ser 10 (você escolhe uma regra como “pegar o máximo para assentos”). Eles podem adicionar mais 3 agentes naquele dia.
• SMS: o total de SMS efetivo passa a ser 7.000 para o resto do período (você escolhe “somar concessões aditivas” para pacotes de mensagens).

Nenhum uso existente precisa ser “movido”. Sua tabela de uso continua contando mensagens enviadas; a checagem de permissões simplesmente compara o uso deste período com o limite efetivo atual.

Dia 25: agendam um downgrade, mantêm acesso até o fim do período

Em Jan 25 eles agendam um downgrade de volta para Starter começando em Feb 1. Você não mexe nas concessões de Jan. Você cria itens futuros (ou concessões futuras) para o próximo período:

• subscription_item (Starter) início Feb 1, fim Feb 28
• Nenhum item de pacote SMS iniciando em Feb 1

Resultado: eles mantêm os assentos Pro e o pacote SMS até 31 de Jan. Em 1 de Fev, os assentos efetivos caem para 3 e os SMS voltam aos limites do Starter para o novo período. Isso é fácil de raciocinar e mapeia bem para um fluxo no-code no AppMaster: mudar datas cria novas linhas, e a query de permissões permanece a mesma.

Erros comuns e armadilhas

A maioria dos bugs de assinatura não são bugs de cobrança. São bugs de acesso causados por lógica espalhada pelo produto. A maneira mais rápida de quebrar um esquema de planos e permissões é responder “eles podem usar isso?” em cinco lugares diferentes.

Uma falha clássica é hardcodar regras na UI, na API e em jobs em segundo plano separadamente. A UI esconde um botão, a API esquece de bloquear o endpoint, e um job noturno ainda roda porque checa outra coisa. Você acaba com relatórios confusos de “às vezes funciona” que são difíceis de reproduzir.

Outra armadilha é usar checagens por plan_id em vez de checagens por recurso. Parece simples no começo (Plano A pode exportar, Plano B não), mas desmorona no momento em que você adiciona um add-on, um cliente grandfathered, um trial gratuito ou uma exceção enterprise. Se você alguma vez diz “if plan is Pro then allow...”, está construindo um labirinto que terá de manter para sempre.

Casos extremos de tempo e cancelamento

O acesso também fica “preso” quando você armazena apenas um booleano como has_export = true e nunca coloca datas. Cancelamentos, reembolsos, chargebacks e downgrades no meio do ciclo precisam de janelas temporais. Sem starts_at e ends_at, você vai conceder acesso permanente por acidente, ou remover acesso cedo demais.

Um checklist simples para evitar isso:

• Toda concessão de permissão deve ter uma source (plano, add-on, override manual) e um intervalo de tempo.
• Toda decisão de acesso deve usar “now entre start e end” (com regras claras para end nulo).
• Jobs em segundo plano devem re-checar permissões em tempo de execução, não assumir o estado de ontem.

Não misture cobrança e acesso

Equipes também se complicam misturando registros de cobrança e regras de acesso na mesma tabela. Cobrança precisa de faturas, impostos, proration, IDs do provedor e estados de retry. Acesso precisa de chaves de recurso claras e janelas de tempo. Quando estão entrelaçados, uma migração de cobrança vira uma pane de produto.

Por fim, muitos sistemas pulam um rastro de auditoria. Quando um usuário pergunta “por que eu posso exportar?”, você precisa de uma resposta como: “Habilitado pelo Add-on X de 2026-01-01 a 2026-02-01” ou “Concedido manualmente pelo suporte, ticket 1842.” Sem isso, suporte e engenharia chutam.

Se você construir isso no AppMaster, mantenha campos de auditoria no seu modelo do Data Designer e faça a verificação “eles podem?” um único Business Process usado por web, mobile e fluxos agendados.

Checklist rápido antes de lançar

Antes de lançar seu esquema de planos e permissões, faça uma última revisão com perguntas reais, não teoria. O objetivo é que o acesso seja explicável, testável e fácil de mudar.

Perguntas de verificação da realidade

Escolha um usuário e um recurso, então tente explicar o resultado como faria para suporte ou finanças. Se você só conseguir responder “eles estão no Pro” (ou pior, “o código diz isso”), você sentirá dor na primeira vez que alguém fizer upgrade no meio do ciclo ou fechar um acordo pontual.

Use este checklist rápido:

• Você consegue responder “por que este usuário tem acesso?” usando apenas dados (itens de assinatura, complementos, overrides e janelas de tempo), sem ler código da aplicação?
• Todas as checagens de acesso usam chaves de recurso estáveis (como feature.export_csv) em vez de nomes de planos (como “Starter” ou “Business”)? Nomes de planos mudam; chaves de recurso não deveriam.
• As permissões têm tempos claros de início e fim, incluindo trials, períodos de carência e cancelamentos agendados? Se tempo estiver faltando, downgrades viram discussão.
• Você pode conceder ou remover acesso para um cliente usando um registro de override, sem ramificar sua lógica? Assim você lida com “dê 10 assentos extras este mês” sem código customizado.
• Você pode testar um upgrade e um downgrade com algumas linhas de exemplo e obter resultados previsíveis? Se precisar de um script complexo para simular, seu modelo é muito implícito.

Um teste prático: crie três usuários (novo, com upgrade no meio do mês, cancelado) e um add-on (como “assentos extras” ou “relatórios avançados”). Então rode sua query de acesso para cada um. Se os resultados forem óbvios e explicáveis, você está pronto.

Se estiver usando uma ferramenta como o AppMaster, mantenha a mesma regra: faça um único lugar (uma query ou um Business Process) responsável por “eles podem?” para que toda tela web e mobile use a mesma resposta.

Próximos passos: facilite a manutenção de upgrades

A melhor maneira de manter upgrades sob controle é começar menor do que pensa. Escolha um punhado de recursos que realmente geram valor (5–10 é suficiente) e construa uma verificação de permissão que responda a uma única pergunta: “Esta conta pode X agora?” Se você não conseguir responder isso em um lugar, upgrades sempre serão arriscados.

Quando essa verificação funcionar, trate caminhos de upgrade como comportamento de produto, não apenas como comportamento de cobrança. A maneira mais rápida de pegar casos estranhos é escrever alguns testes de acesso baseados em movimentos reais de clientes.

Aqui estão próximos passos práticos que costumam compensar imediatamente:

• Defina um catálogo mínimo de recursos e mapeie cada plano para um conjunto claro de permissões.
• Adicione complementos como “itens” separados que concedem ou estendem permissões, em vez de embuti-los nas regras do plano.
• Escreva 5–10 testes de acesso para caminhos comuns (upgrade no meio do ciclo, downgrade na renovação, add-on adicionado e depois removido, trial para pago, período de carência).
• Faça mudanças de preço só por dados: atualize linhas de plano, mapeamentos de recursos e concessões, não o código da aplicação.
• Crie o hábito: todo novo plano ou add-on deve vir com pelo menos um teste que prove que o acesso se comporta como esperado.

Se estiver usando um backend no-code, ainda dá para modelar esse padrão limpo. No AppMaster, o Data Designer é um bom local para construir as tabelas centrais (plans, features, subscriptions, subscription items, entitlements). Então o Business Process Editor pode conter o fluxo de decisão de acesso (carregar entitlements ativos, aplicar janelas de tempo, retornar permitir/negar) para que você não fique codificando checagens espalhadas pelos endpoints.

O ganho aparece na próxima vez que o preço mudar. Em vez de reescrever regras, você edita dados: um recurso sai do “Pro” e vira um add-on, a duração de uma permissão muda, ou um plano legado mantém suas concessões antigas. Sua lógica de acesso permanece estável, e upgrades viram uma atualização controlada, não uma corrida de código.

Se quiser validar seu esquema rapidamente, tente modelar um upgrade e um add-on de ponta a ponta, e rode esses testes de acesso antes de adicionar qualquer outra coisa.