Modo sandbox para demos: semeie um tenant de demonstração e bloqueie e-mails reais

O que pode dar errado quando você faz uma demo em um sistema ao vivo

Uma demo ao vivo parece rápida porque tudo já está configurado. Também é o lugar onde cliques pequenos podem virar ações reais: e-mails reais, cobranças reais e alterações reais nos dados.

A surpresa mais comum é a comunicação. Um usuário de demo atualiza um perfil, convida um colega ou aciona um reset de senha e seu app felizmente envia um e-mail para um endereço real. Se a conta de demo usa configurações de produção, até um “teste” pode notificar clientes reais, spammer uma lista de envio ou vazar informações privadas em um template.

Pagamentos podem ser piores. Basta um fluxo de checkout conectado a um processador ao vivo, um cartão salvo ou um passo de “verificação de $1” para cobrar dinheiro por engano. Às vezes não acontece nem durante a chamada: um usuário clica em “upgrade”, seu job de faturamento roda depois e uma conta é cobrada quando você já esqueceu.

“É só usar staging” nem sempre resolve. Staging frequentemente compartilha integrações de terceiros (email, SMS, webhooks) e costuma ser menos bloqueado. Ou sua demo precisa de dados e velocidade parecidos com produção, então times acabam fazendo demo na produção mesmo.

Uma sandbox de demo segura deve proteger quatro coisas:

• Pessoas (nenhum e-mail, SMS ou convite acidental)
• Dinheiro (sem cobranças reais, reembolsos, faturas ou eventos de pagamento)
• Dados (sem acesso a registros de clientes e sem ações de demo que modifiquem contas reais)
• Reputação (sem notificações-surpresa a parceiros via webhooks ou integrações)

Imagine um fundador demonstrando para um investidor. Ele digita um e-mail real durante o cadastro, clica em “invite teammate” e seu app envia um convite para uma pessoa aleatória. Depois clica em “upgrade” e o sistema cria uma assinatura real. Esse é o tipo de história de demo que você precisa ouvir apenas uma vez.

O que “sandbox mode” realmente significa em termos simples

Um sandbox mode para demos é uma promessa que você faz a si mesmo e à sua audiência: o produto deve parecer real, mas não pode causar impacto no mundo real.

Essa promessa é diferente de um ambiente de staging. Staging geralmente é uma cópia separada do app onde engenheiros testam mudanças. Pode ainda enviar e-mails se alguém o configurar errado e costuma ter dados meio reais e bagunçados. Sandbox mode é um comportamento que seu app aplica, mesmo quando a interface parece produção.

Também é diferente de uma simples “conta de teste”. Uma conta de teste é só outro registro de usuário. Se seu app estiver ligado a e-mail real, pagamentos reais e integrações reais, essa conta ainda pode disparar efeitos colaterais.

Efeitos colaterais são tudo que sua demo pode acidentalmente fazer fora do app. Os suspeitos habituais são mensagens de saída (email/SMS), pagamentos, webhooks e integrações (atualizações de CRM, pings no Slack, automações) e gravações de dados que criam objetos reais (clientes, pedidos, tickets de suporte).

Uma boa sandbox mantém a experiência realista simulando resultados. O usuário clica em “Invite teammate”, vê “Invite sent”, o log de atividade é atualizado, mas nenhum e-mail sai do sistema. O usuário clica em “Upgrade”, vê uma tela convincente de recibo e um selo “Plan: Pro”, mas nada é cobrado.

Decida o que fingir, bloquear ou permitir em uma demo

Antes de construir qualquer coisa, faça um inventário de cada efeito “do mundo real” que seu app pode disparar. Um bom sandbox é menos sobre dados falsos bonitos e mais sobre garantir que nada escape do seu tenant de demo.

Comece por tudo que pode causar dano ou confusão: e-mails, SMS, pagamentos, webhooks, uploads de arquivos e analytics. Não esqueça riscos silenciosos como resets de senha, links de convite, exportações e jobs em background.

Então decida o que deve ser bloqueado, o que pode ser permitido e o que deve ser simulado para parecer real. Uma regra simples: leituras geralmente são seguras; envios, cobranças e notificações devem ser bloqueados ou simulados.

Uma divisão prática para a maioria dos produtos parece com isto:

• Permitir: busca, filtros, dashboards, visualização de relatórios, editar campos de perfil
• Fingir: “enviar convite”, “e-mail de recibo”, “upgrade de plano”, “notificar o time” (mostrar UI de sucesso e registrar o evento)
• Bloquear: cobrar um cartão, enviar e-mails/SMS reais, chamar webhooks de clientes, exportar dados reais
• Controlar: ações destrutivas como excluir, atualizações em massa ou mudanças administrativas (exigir uma etapa de confirmação)

Depois, defina o que o tenant de demo pode ver e mudar. O objetivo é um playground seguro, não uma conta admin que pode vasculhar configurações parecidas com produção. Por exemplo, permita criar projetos e tarefas, mas proíba alterar detalhes de faturamento, chaves de API ou configurações de autenticação.

Escreva as regras em um lugar só para o time ficar alinhado. Mantenha curto e concreto:

• O que o tenant de demo pode fazer
• O que é sempre bloqueado (sem exceções)
• O que é simulado e como aparece para o usuário
• Onde a atividade de demo é registrada para troubleshooting
• Quem pode ligar ou desligar o modo demo

Exemplo: durante uma ligação de vendas, alguém pode se cadastrar, criar um workspace, convidar um colega (simulado) e clicar em “Upgrade” para ver recursos do plano (simulado), mas o app nunca envia e-mails nem tenta uma cobrança real.

Passo a passo: semear um tenant de demo que você possa resetar

Comece criando um tenant dedicado apenas para demos. Dê um nome inconfundível (como “DEMO - ACME”) e grave uma flag clara no banco de dados (por exemplo is_demo_tenant = true). Essa flag vira sua rede de segurança para regras posteriores como bloquear e-mails e pagamentos.

Em seguida, semeie dados realistas para que o produto pareça vivo. Mire em “o suficiente”: alguns usuários de exemplo, um ou dois projetos e um pequeno conjunto de itens que mostrem os fluxos principais. Use nomes e status críveis, mas nunca dados reais de clientes.

Mantenha o script de seed pequeno e repetível. Se você não consegue rodá-lo com segurança várias vezes, ainda não é um script de seed. Prefira IDs determinísticos ou um namespace consistente de demo para que resets não criem duplicatas.

Um padrão de reset que funciona para a maioria dos apps:

• Apagar todos os dados do tenant de demo (ou restaurar de um snapshot limpo)
• Recriar o tenant de demo com a flag de demo
• Inserir usuários e papéis de exemplo (admin, member, viewer)
• Inserir alguns registros realistas (projetos, mensagens, faturas)
• Verificar que telas chave carregam sem correções manuais

Facilite o reset. Um reset com um clique para uso interno é ideal, e um reset agendado à noite é um bom backup. Por fim, adicione um indicador visível de “Demo mode” na UI (barra superior, cabeçalho ou banner) para que ninguém esqueça onde está.

Passo a passo: adicionar um switch de demo que seja fácil de notar

Uma demo segura começa com um switch claro que muda o comportamento do app inteiro. Escolha um lugar para controlá-lo (uma variável de ambiente, uma configuração do tenant ou uma feature flag) e faça todo o resto ler dessa fonte.

1) Escolha um switch e faça o “seguro” ser o padrão

Para muitas equipes, uma variável de ambiente é a mais simples: DEMO_MODE=true. Se você precisa de tenants reais e de demo no mesmo ambiente, use uma configuração por tenant como tenant.is_demo.

Torne o padrão seguro. Acidentes costumam acontecer quando alguém esquece de setar uma variável.

2) Centralize as checagens (sem ifs espalhados)

Crie um módulo único de “demo guard” que seu app chame antes de qualquer ação arriscada. O guard decide: permitir, bloquear ou substituir por uma resposta falsa. Todo envio de e-mail, chamada de pagamento, webhook e exportação deve passar por ele.

Encaminhe por esse guard primeiro:

• Mensagens de saída (email, SMS, push)
• Pagamentos e reembolsos
• Webhooks e chamadas a APIs de terceiros
• Exportações de arquivo (CSV, faturas, relatórios)
• Ações administrativas (excluir, convidar, mudança de papéis)

3) Registre tudo que você bloqueia (para poder provar)

Quando o guard bloqueia uma ação, escreva um evento de log claro com o que foi tentado, qual tenant/usuário fez e por que foi bloqueado. Exemplo: durante uma demo, alguém clica em “Invite teammate” e você retorna “Invite queued (demo)” enquanto loga blocked_email_send. Se um stakeholder perguntar “Algo saiu?”, você tem a resposta.

4) Torne o bypass difícil

Adicione um banner alto como “DEMO MODE” e inclua isso nos logs do servidor no startup. Também adicione um teste que falhe se o modo demo estiver desligado em um ambiente de demo.

Passo a passo: impedir e-mails reais, SMS e webhooks

A maneira mais rápida de ferrar uma demo é quando seu app fala com pessoas reais ou sistemas reais. No modo sandbox, trate toda mensagem de saída como insegura por padrão e só permita o que você controla totalmente.

1) Pare e-mails de sair do sistema

Comece pelo e-mail porque normalmente está conectado ao cadastro, convites, resets de senha e recibos.

• Direcione todos os e-mails de saída para uma caixa de retenção, ou desabilite o envio completamente em demo
• Substitua todo endereço destinatário por um endereço de teste seguro (mesmo que o usuário tenha digitado o próprio)
• Adicione um banner na app tipo “Email suprimido em demo” para não confundir as pessoas
• Registre o conteúdo do e-mail na UI (assunto e pré-visualização) para que a demo ainda pareça real
• Prevenir retries em background para que um e-mail suprimido não fique na fila para sempre

Exemplo: durante uma demo, alguém convida [email protected]. Seu app deve trocar para um endereço seguro (como [email protected]) e mostrar um toast: “Invite email suppressed in demo. View message.” Assim a história avança sem contactar um cliente real.

2) Bloqueie SMS, push, webhooks e jobs em background da mesma forma

Use a mesma regra para SMS e notificações push: nunca envie para um dispositivo real em demo. Para webhooks, pause a entrega ou stub a chamada e mostre o que teria sido enviado.

Se você tem jobs em background (sequências de boas-vindas, retries de cobrança, sincronização com CRM), impeça que rodem para tenants de demo ou forçe um caminho seguro que não faça nada.

Passo a passo: fazer pagamentos parecerem reais, mas permanecerem seguros

Pagamento é onde demos viram arriscadas rápido. Um bom sandbox faz o checkout parecer real, mas garante que nenhum dinheiro real se mova, mesmo que alguém clique em todos os botões.

1) Use o ambiente de teste do provedor por padrão

Conecte seu app ao ambiente de teste do provedor de pagamentos com chaves de teste. Mantenha essas chaves separadas da produção e carregue-as via configuração de ambiente para evitar que chaves live sejam acidentalmente enviadas numa build de demo.

Se você pode ter tenants reais e de demo no mesmo ambiente, uma flag por tenant como is_demo_tenant é mais confiável que uma configuração global.

2) Bloqueie rigidamente qualquer cobrança real em tenants de demo

Mesmo com chaves de teste, adicione uma segunda rede de segurança: quando is_demo_tenant for true, não chame captura/cobrança de jeito nenhum. Retorne uma resposta controlada do backend em vez disso.

Um fluxo simples:

• Usuário clica em “Pay” ou “Upgrade”
• Backend detecta tenant de demo e pula a chamada ao provedor
• Backend armazena um registro de transação falso (status, valor, moeda)
• UI recebe um resultado realista de “sucesso” e mostra a tela de recibo
• Páginas administrativas mostram o mesmo pagamento falso de forma consistente

3) Mantenha assinaturas, reembolsos e faturas consistentes

Demos quebram quando uma tela diz “Subscribed” e a lista de faturas está vazia. Escolha um conjunto de estados falsos e reutilize-os em todo lugar: data de início da assinatura, próxima cobrança, IDs de fatura e status de reembolso.

Exemplo: um usuário “faz upgrade” para Pro durante a demo. Você gera INV-DEMO-1042, marca como pago e define renovação em 30 dias. Se clicarem em “Refund”, troque os mesmos registros para reembolsado e mostre uma nota de crédito correspondente.

4) Ignore webhooks de pagamento em modo demo

Webhooks podem sobrescrever seu estado falso. Quando um webhook chegar, verifique o tenant (ou metadata) e descarte se for para um tenant de demo. Logue para provar que foi bloqueado.

Noções básicas de segurança e privacidade para ambientes de demo

Um ambiente de demo deve ser seguro mesmo quando você está cansado, com pressa ou compartilhando acesso com alguém que você mal conhece. O objetivo é simples: sua demo pode parecer real, mas não pode tocar dados reais de clientes nem disparar ações irreversíveis.

Comece com separação rígida. Contas de demo não devem ser capazes de ver ou adivinhar IDs de tenants reais, usuários reais ou arquivos reais. Mantenha dados de demo em um banco/esquema e bucket de storage separados, e bloqueie leituras entre tenants por padrão. Se você tem views de admin, garanta que admins de demo só administrem o tenant de demo.

Bloqueie ações que causam dano

Mesmo em demo, alguns botões são perigosos demais. Remova-os, esconda-os atrás de um login interno ou torne-os no-ops em demo. Priorize controles como exportações, exclusões, edição de papéis/permissões e downloads em massa. Coloque limites em uploads (tipo e tamanho) e rejeite qualquer coisa executável.

Rate limits importam mais do que se pensa. Demos públicas são testadas constantemente. Coloque limites rígidos em tentativas de login, resets de senha e qualquer endpoint que possa gerar custos (uploads, chamadas a terceiros, SMS).

Logs de auditoria: assuma que você precisará reproduzir o que aconteceu

Registre detalhes suficientes para responder: quem acessou o demo, o que tentou e o que o sistema bloqueou. No mínimo, logue o ator (user ID), tenant, IP e user agent, além de eventos chave como login, tentativas de convite, tentativas de exportação e mudanças de papel. Redija campos sensíveis e armazene o resultado final (permitido/bloqueado).

Se você herdou um protótipo gerado por IA, verifique vazamentos comuns como segredos expostos, permissões admin amplas ou checagens de tenant faltando.

Erros comuns que tornam uma demo arriscada

A maioria dos desastres de demo acontece porque o app parece seguro na UI, mas o sistema por trás ainda age como produção. Um botão pode mostrar “Email disabled”, mas o backend ainda dispara o envio real. Ou você desliga a página de checkout, mas o webhook de pagamento ainda aciona quando alguém reativa um link antigo.

Erros que afundam demos com frequência:

• Bloquear apenas o front-end enquanto endpoints do backend ainda enviam e-mails, cobram cartões ou chamam APIs de terceiros
• Esquecer workers de background, jobs agendados e retries (eles costumam rodar com permissões completas e credenciais reais)
• Enviar uma build de demo que ainda contém chaves de API reais, credenciais SMTP ou segredos de webhook de produção
• Compartilhar uma conta de demo entre todos, fazendo com que configurações se deteriorem, dados fiquem bagunçados e você não saiba o que mudou
• Pular um plano de reset, fazendo o tenant de demo encher de lixo, estados quebrados e assinaturas “fantasma”

Um exemplo real: você demonstra um fluxo de “team invite”. O formulário de convite está oculto no modo demo, mas a rota API ainda está ativa. Um curioso abre dev tools, chama o endpoint direto e seu worker envia convites reais para endereços aleatórios. Agora você tem risco de privacidade, risco de spam e uma situação constrangedora.

Duas práticas evitam a maior parte disso. Primeiro, faça o comportamento seguro existir no backend, não só na UI. Bloqueie provedores externos quando demo mode estiver ativo e registre a intenção. Segundo, trate reset como um recurso: uma ação que recria o tenant de demo, re-semeia dados conhecidos e desliga jobs de longa execução para aquele tenant.

Checklist rápido antes de compartilhar uma demo

Uma demo segura parece chata por trás das cortinas. Isso é bom. Antes de passar uma demo para um prospect ou entrar em uma call, faça uma verificação rápida que prove que sua demo não pode enviar mensagens reais, cobrar dinheiro ou vazar dados reais.

As 5 checagens que evitam a maioria dos desastres de demo

• Confirme que você está no lugar certo: o tenant de demo está claramente rotulado e separado de dados de clientes reais
• Dispare os caminhos barulhentos: reset de senha, convite de usuário, notificações. Verifique que e-mail/SMS não entregam e webhooks de saída não fazem nada ou vão para um endpoint seguro
• Caminhe pela trilha do dinheiro: clique em upgrade e tente o checkout. Garanta que seja só com chaves de teste ou totalmente simulado e que não consiga cobrar um cartão
• Prove que dá para limpar: rode o reset e confirme que o tenant volta ao mesmo estado inicial conhecido
• Procure segredos acidentais: verifique config de ambiente, logs do servidor e código cliente por chaves de API reais, tokens ou valores privados. Se um navegador pode ver, assuma que outros também podem

Um roteiro curto para o apresentador (quando recursos estão desativados)

Diga uma frase e siga:

• “Isto é um sandbox, então mensagens estão bloqueadas por segurança.”
• “Pagamentos são simulados, mas as telas refletem o fluxo real.”
• “Após a call, nós resetamos este demo para que todos comecem limpos.”

Rode esse checklist uma vez por dia de demo. Leva poucos minutos e evita surpresas.

Exemplo: uma demo segura do produto do cadastro ao “upgrade”

Um fundador demonstra para duas pessoas na mesma call: um investidor e um cliente piloto. O objetivo é mostrar a jornada completa sem arriscar e-mails reais, cobranças reais ou mensagens acidentais a usuários reais.

A demo começa com um workspace “Acme Demo” limpo que foi semeado antes. Já tem projetos realistas, algumas tarefas e estatísticas de uso para que as telas não fiquem vazias. O fundador se cadastra com um e-mail novo só para provar que o onboarding funciona. Por trás, o sistema faz a rota para um tenant de demo dedicado e marca a sessão como sandbox mode.

Em seguida a audiência pede para convidar um colega. O fundador digita um e-mail com aparência real, clica em Invite e a UI mostra “Invite sent.” Por trás, o e-mail é suprimido e armazenado num log de auditoria com algo como “blocked in demo mode.” Se o cliente piloto perguntar “Meu colega recebeu?”, o fundador responde: “Não, convites são simulados aqui para não contatar ninguém por engano.”

Depois vem o momento do upgrade. O investidor quer ver preços e pagamento.

O que a audiência vê

Eles realizam três ações: cadastro, convite e upgrade. O fluxo de upgrade aceita um número de cartão de teste e mostra uma tela de sucesso; a conta muda para “Pro” com limites maiores.

O que acontece por trás

Pagamentos nunca atingem um processador live. O app cria um registro de pagamento de demo, retorna o status “paid” e mantém esse estado consistente entre faturas e páginas admin. Webhooks são ignorados para o tenant de demo e qualquer “recibo” por e-mail é suprimido.

Após a call, a equipe clica em um botão de reset (ou roda um script) que limpa o tenant de demo e re-semeia para o estado conhecido-bom.

Próximos passos: entregue uma demo que não te surpreenda

Comece escolhendo o lugar certo para demo. Sandbox mode serve para segurança dentro do mesmo app: você mantém a UI real, mas bloqueia efeitos colaterais (e-mails reais, cobranças reais, webhooks reais). Staging é uma cópia separada da produção: bom para testar releases, mas pode ainda enviar e-mails reais se você esquecer uma configuração. Muitas equipes precisam de ambos: staging para teste de entrega e sandbox mode para demos voltadas ao cliente.

Se você quer o caminho mais rápido para uma demo mais segura, implemente em passos pequenos:

• Bloqueie e-mail/SMS reais primeiro (substitua por log ou visualizador de inbox)
• Faça pagamentos parecerem bem-sucedidos sem cobrar cartões
• Desative webhooks de saída e jobs em background que falem com sistemas reais
• Adicione um botão de reset para o tenant de demo (ou um reset noturno automático)
• Só então polir dados semeados e fluxos

Adicione guardrails que falhem alto. Se alguém acidentalmente demoar no tenant errado, o app deve recusar ações arriscadas.

Se você herdou um código gerado por IA (Lovable, Bolt, v0, Cursor, Replit), vale a pena ter um segundo par de olhos na integração. FixMyMess (fixmymess.ai) foca em diagnosticar e reparar esse tipo de efeito colateral — coisas como ambientes mistos, segredos expostos e integrações apontando para produção — para que uma demo permaneça segura e repetível.