Modo sandbox para demos: crear un tenant de demostración y bloquear correos reales

Qué puede salir mal cuando haces una demo en un sistema en vivo

Una demo en vivo se siente rápida porque todo ya está configurado. También es el lugar donde un par de clics pueden convertirse en acciones reales: correos reales, cargos reales y cambios reales en datos.

La sorpresa más común es la mensajería. Un usuario de demo actualiza un perfil, invita a un compañero o pide restablecer la contraseña y tu app envía un correo real. Si la cuenta de demo usa configuraciones de producción, incluso una “prueba” puede notificar clientes reales, spamear una lista o filtrar datos privados en una plantilla.

Los pagos pueden ser peor. Basta con un flujo de checkout conectado a un procesador real, una tarjeta guardada o un paso de verificación de “$1” para cobrar por error. A veces ni siquiera ocurre durante la llamada: un usuario pulsa “upgrade,” tu job de facturación corre después y se factura una cuenta cuando ya lo olvidaste.

“Solo usa staging” no siempre lo resuelve. Staging a menudo comparte integraciones de terceros (email, SMS, webhooks) y suele estar menos restringido. O tu demo necesita datos y velocidad parecidos a producción, así que los equipos acaban haciendo demos en producción de todos modos.

Un sandbox seguro para demos debería proteger cuatro cosas:

• Personas (no correos, SMS o invites accidentales)
• Dinero (sin cargos, reembolsos, facturas o eventos de payout reales)
• Datos (sin acceso a registros de clientes reales y sin acciones de demo que modifiquen cuentas reales)
• Reputación (sin notificaciones sorpresa a partners vía webhooks o integraciones)

Imagina a un fundador demoando ante un inversor. Teclea un correo real al registrarse, pulsa “invite teammate” y tu app envía una invitación a una persona aleatoria. Luego pulsa “upgrade” y el sistema crea una suscripción real. Ese tipo de historia solo hace falta una vez.

Qué significa realmente “modo sandbox” en términos sencillos

Un modo sandbox para demos es una promesa que te haces a ti mismo y a tu audiencia: el producto debe verse y sentirse real, pero no debe poder causar impacto en el mundo real.

Esa promesa difiere de un entorno de staging. Staging suele ser una copia separada de la app donde los ingenieros prueban cambios. Puede seguir enviando correos si alguien lo malconfigura y a menudo tiene datos a medio camino entre falsos y reales. El modo sandbox es un comportamiento que la app aplica, incluso cuando la UI parece producción.

También es distinto a una simple “cuenta de prueba”. Una cuenta de prueba es solo otro registro de usuario. Si tu app está conectada a email real, pagos reales e integraciones reales, esa cuenta aún puede disparar efectos secundarios.

Los efectos secundarios son todo lo que tu demo puede hacer accidentalmente fuera de la app. Los sospechosos habituales son mensajes salientes (email/SMS), pagos, webhooks e integraciones (actualizaciones CRM, pings a Slack, automatizaciones) y escrituras de datos que crean objetos reales (clientes, pedidos, tickets de soporte).

Un buen sandbox mantiene la experiencia realista simulando resultados. El usuario pulsa “Invite teammate”, ve “Invite sent”, el registro de actividad se actualiza, pero ningún correo sale de tu sistema. El usuario pulsa “Upgrade”, ve una pantalla creíble de recibo y una insignia “Plan: Pro”, pero no se cobra nada.

Decide qué falsificar, bloquear o permitir en una demo

Antes de construir nada, haz inventario de cada efecto “del mundo real” que tu app pueda disparar. Un buen modo sandbox se trata menos de datos falsos bonitos y más de asegurarse de que nada escape de tu tenant de demo.

Empieza por lo que puede causar daño o confusión: emails, SMS, pagos, webhooks, subidas de archivos y analítica. No olvides riesgos más silenciosos como restablecimientos de contraseña, enlaces de invitación, exportaciones y jobs en background.

Luego decide qué debe bloquearse, qué puede permitirse y qué debe simularse para que parezca real. Una regla simple: las lecturas suelen ser seguras; los envíos, cargos y notificaciones deben bloquearse o simularse.

Una división práctica para la mayoría de productos podría ser:

• Permitir: búsqueda, filtrado, dashboards, ver reportes, editar campos de perfil
• Falsificar: “enviar invitación”, “recibo por email”, “subir de plan”, “notificar al equipo” (mostrar UI de éxito y registrar el evento)
• Bloquear: cobrar una tarjeta, enviar emails/SMS reales, llamar webhooks de clientes, exportar datos reales
• Restringir: acciones destructivas como borrar, actualizaciones masivas o cambios de admin (requerir confirmación)

A continuación, define qué puede ver y cambiar el tenant de demo. El objetivo es un campo de juego seguro, no una cuenta admin que pueda entrar en ajustes parecidos a producción. Por ejemplo, puedes permitir crear proyectos y tareas, pero prohibir cambiar detalles de facturación, claves de API o ajustes de autenticación.

Anota las reglas en un solo lugar para que el equipo vaya alineado. Sé breve y concreto:

• Qué puede hacer el tenant de demo
• Qué está siempre bloqueado (sin excepciones)
• Qué se simula y cómo aparece al usuario
• Dónde se registra la actividad de demo para troubleshooting
• Quién puede activar o desactivar el modo demo

Ejemplo: durante una llamada de ventas, alguien puede registrarse, crear un workspace, invitar a un compañero (simulado) y pulsar “Upgrade” para ver funciones de plan (simulado), pero la app nunca envía un email ni intenta un cargo real.

Paso a paso: sembrar un tenant de demo que puedas resetear

Empieza creando un tenant dedicado solo para demos. Dale un nombre inequívoco (por ejemplo “DEMO - ACME”) y guarda una bandera clara en la base de datos (por ejemplo is_demo_tenant = true). Esa bandera será tu red de seguridad para reglas posteriores como bloquear emails y pagos.

Luego siembra datos realistas para que el producto parezca vivo. Apunta a “lo justo”: un par de usuarios de muestra, uno o dos proyectos y un conjunto pequeño de ítems que muestren los flujos centrales. Usa nombres y estados creíbles, pero nunca datos de clientes reales.

Mantén el script de seed pequeño y repetible. Si no puedes volver a ejecutarlo de forma segura, aún no es un script de seed. Prefiere IDs determinísticos o un “namespace de demo” consistente para que los resets no creen duplicados.

Un patrón de reset que funciona para la mayoría de apps:

• Borrar todos los datos del tenant de demo (o restaurar desde una snapshot limpia)
• Re-crear el tenant de demo con la bandera de demo
• Insertar usuarios y roles de muestra (admin, miembro, viewer)
• Insertar unos pocos registros realistas (proyectos, mensajes, facturas)
• Verificar que las pantallas clave cargan sin arreglos manuales

Haz que el reset sea fácil. Un reset con un clic para uso interno es ideal, y un reset nocturno programado es un buen respaldo. Finalmente, añade un indicador visible de “Demo mode” en la UI (barra superior, encabezado o banner) para que nadie olvide dónde está.

Paso a paso: añadir un interruptor de demo que sea difícil de ignorar

Una demo segura empieza con un interruptor claro que cambie cómo se comporta toda la app. Elige un único lugar para controlarlo (una variable de entorno, una configuración por tenant o una feature flag), y haz que todo lo demás lea desde ahí.

1) Elige un interruptor y haz que “seguro” sea el valor por defecto

Para muchos equipos, una variable de entorno es lo más simple: DEMO_MODE=true. Si necesitas tener tenants reales y de demo en el mismo entorno, usa una configuración a nivel de tenant como tenant.is_demo.

Haz que el valor por defecto sea seguro. Los accidentes suelen ocurrir cuando alguien olvida ajustar una variable.

2) Centraliza las comprobaciones (no ifs dispersos)

Crea un único módulo “demo guard” al que la app llame antes de cualquier acción riesgosa. El guard decide: permitir, bloquear o reemplazar por una respuesta falsa. Cada envío de email, llamada de pago, webhook y exportación de datos debería pasar por él.

Enruta a través del guard:

• Mensajes salientes (email, SMS, push)
• Pagos y reembolsos
• Webhooks y llamadas a APIs de terceros
• Exportaciones de archivos (CSV, facturas, reportes)
• Acciones de admin (borrar, invitar, cambios de rol)

3) Registra todo lo que bloquees (para poder probarlo)

Cuando el guard bloquee una acción, escribe un evento de log claro con qué se intentó, qué tenant/usuario lo hizo y por qué fue bloqueado. Ejemplo: durante una demo, alguien pulsa “Invite teammate” y devuelves “Invite queued (demo)” mientras registras blocked_email_send. Si un stakeholder pregunta “¿Se envió algo?”, tendrás la respuesta.

4) Haz que evadirlo sea difícil

Añade un banner visible tipo “DEMO MODE” e inclúyelo en los logs de servidor al arrancar. También añade una prueba que falle si el modo demo está desactivado en un entorno de demo.

Paso a paso: evitar correos reales, SMS y webhooks

La forma más rápida en que una demo sale mal es cuando tu app habla con personas reales o sistemas reales. En modo sandbox, trata todos los mensajes salientes como inseguros por defecto y luego permite solo lo que puedas controlar completamente.

1) Evita que el email saliente abandone tu sistema

Empieza por el email porque suele estar ligado al registro, invites, resets y recibos.

• Enruta todo el email saliente a un buzón sink, o desactiva el envío en demo
• Reemplaza cada dirección destinataria por una dirección de prueba segura (incluso si el usuario escribió la suya)
• Añade un banner en la app que diga “Email suprimido en demo” para evitar confusiones
• Registra el contenido del correo en la UI (asunto y vista previa) para que la demo siga pareciendo real
• Evita retries en background para que un email suprimido no se encole indefinidamente

Ejemplo: durante una demo, alguien invita a [email protected]. Tu app debe cambiarla por una dirección segura (por ejemplo [email protected]), luego mostrar un toast: “Invite email suppressed in demo. View message.” Así la historia sigue sin contactar a un cliente real.

2) Bloquea SMS, push, webhooks y jobs en background igual

Aplica la misma regla a SMS y push: nunca enviar a un dispositivo real en demo. Para webhooks, pausar la entrega o stubearla y mostrar qué se habría enviado.

Si tienes jobs en background (secuencias de bienvenida, reintentos de facturación, sync con CRM), impide que se ejecuten para tenants de demo o forzarlos a una ruta segura no-operativa.

Paso a paso: hacer que los pagos parezcan reales pero sean seguros

Los pagos son donde las demos se vuelven riesgosas rápidamente. Un buen modo sandbox hace que el checkout parezca real, pero garantiza que no se mueva dinero real, aunque alguien pulse todos los botones.

1) Usa el entorno de prueba del proveedor por defecto

Conecta tu app al entorno de test del proveedor de pagos con claves de prueba. Mantén esas claves separadas de producción y cárgalas desde variables de entorno para no “meter” claves reales en una build de demo.

Si puedes tener tenants reales y de demo en el mismo entorno, una bandera a nivel de tenant como is_demo_tenant es más fiable que una configuración global.

2) Bloquea totalmente cualquier cargo real en tenants de demo

Incluso con claves de test, añade una segunda red de seguridad: cuando is_demo_tenant sea true, no llames a capture/charge en absoluto. Devuelve una respuesta controlada desde tu backend.

Un flujo simple:

• El usuario pulsa “Pay” o “Upgrade”
• El backend detecta tenant de demo y omite la llamada al proveedor
• El backend guarda un registro de transacción falso (estado, importe, moneda)
• La UI recibe un resultado realista de “éxito” y muestra la pantalla de recibo
• Las páginas admin muestran el mismo pago falso de forma consistente

3) Mantén consistencia en suscripciones, reembolsos y facturas

Las demos fallan cuando una pantalla dice “Suscrito” pero la lista de facturas está vacía. Elige un conjunto de estados falsos y reutilízalos en todas partes: fecha de inicio de suscripción, próxima fecha de cobro, IDs de factura y estado de reembolso.

Ejemplo: un usuario “sube” a Pro en la demo. Generas INV-DEMO-1042, la marcas como pagada y pones renovación a 30 días. Si pulsa “Refund”, cambia los mismos registros a reembolsados y muestra la nota de crédito correspondiente.

4) Ignora webhooks de pago en modo demo

Los webhooks pueden reescribir tu estado falso. Cuando llegue un webhook, comprueba el tenant (o metadata) y descártalo si apunta a un tenant de demo. Regístralo para poder demostrar que se bloqueó.

Fundamentos de seguridad y privacidad para entornos de demo

Un entorno de demo debe ser seguro incluso cuando estás cansado, con prisa o compartiendo acceso con alguien que no conoces bien. El objetivo es simple: tu demo puede verse real, pero no tocar datos reales de clientes ni provocar acciones irreversibles.

Empieza con separación fuerte. Las cuentas de demo no deberían poder ver o adivinar IDs de tenants reales, usuarios reales o ficheros reales. Mantén datos de demo en su propia base de datos/schema y bucket de almacenamiento, y bloquea lecturas cross-tenant por defecto. Si tienes vistas de “admin”, asegúrate de que los admins de demo solo administren el tenant de demo.

Restringe las acciones que causan daño

Incluso en demo, algunos botones son demasiado peligrosos. Elimínalos, escóndelos tras un login interno o hazlos no-operativos en demo. Prioriza controles como exportaciones, borrados, edición de roles/permiso y descargas masivas. Pon límites a las subidas de archivos (tipo y tamaño) y rechaza cualquier contenido ejecutable.

Los límites de tasa importan más de lo que se piensa. Las demos públicas reciben mucho escrutinio. Pon topes estrictos en intentos de login, resets de contraseña y cualquier endpoint que pueda generar costes (subidas, llamadas a terceros, SMS).

Logs de auditoría: asume que necesitarás reproducir lo ocurrido

Registra suficiente detalle para responder: quién accedió a la demo, qué intentó y qué bloqueó el sistema. Como mínimo, loguea el actor (user ID), tenant, IP y user agent, más eventos clave como login, intentos de invite, intentos de export y cambios de rol. Redacta campos sensibles y guarda el resultado final (permitido/bloqueado).

Si heredaste un prototipo generado por IA, revisa fugas comunes como secretos expuestos, permisos admin demasiado amplios o cheques de tenant faltantes.

Errores comunes que hacen una demo peligrosa

La mayoría de desastres de demo ocurren porque la app parece segura en la UI, pero el sistema por detrás sigue comportándose como producción. Un botón puede decir “Email disabled”, pero el backend aún hace la llamada real. O apagas la página de checkout, pero el webhook de pago todavía se dispara si alguien intenta un enlace antiguo.

Errores que hunden sandboxes una y otra vez:

• Bloquear solo el front-end mientras los endpoints del backend siguen enviando emails, cobrando tarjetas o llamando APIs de terceros
• Olvidar workers en background, jobs programados y retries (a menudo corren con permisos completos y credenciales reales)
• Subir una build de demo que aún contiene claves de API reales, credenciales SMTP o secretos de webhook de producción
• Compartir una cuenta de demo entre todos, de modo que las configuraciones se mezclan, los datos se ensucian y no puedes saber qué cambió
• Omitir un plan de reset, de modo que el tenant de demo se llena de datos basura, estados rotos y “suscripciones fantasma”

Un ejemplo real: demoas un flujo de “invite team”. El formulario de invitación está oculto en modo demo, pero la ruta API sigue activa. Un usuario curioso abre dev tools, llama al endpoint directamente y tu worker envía emails reales a direcciones aleatorias. Ahora tienes riesgo de privacidad, spam y una mala impresión.

Dos hábitos previenen la mayoría de esto. Primero, aplica el comportamiento seguro en el backend, no solo en la UI. Bloquea proveedores salientes cuando el modo demo está activo y registra la intención en los logs. Segundo, trata el reset como una característica: una acción que recrea el tenant de demo, reseedear datos conocidos y deshabilitar jobs de larga duración para ese tenant.

Lista rápida antes de compartir una demo

Una demo segura se siente aburrida por detrás. Eso está bien. Antes de pasar una demo a un prospecto o entrar a una llamada, haz una pasada rápida que pruebe que la demo no puede enviar mensajes reales, cobrar dinero real ni filtrar datos reales.

Los 5 chequeos que evitan la mayoría de desastres

• Confirma que estás en el lugar correcto: el tenant de demo está claramente etiquetado y separado de cualquier dato de cliente real
• Activa los caminos ruidosos: restablecimiento de contraseña, invitación de usuario, notificaciones. Verifica que email/SMS no se entregan y que los webhooks salientes no hacen nada o apuntan a un endpoint seguro
• Recorre el camino del dinero: pulsa upgrade y prueba el checkout. Asegúrate de que sea solo test (claves de prueba) o totalmente simulado y no pueda cobrar una tarjeta
• Prueba que puedes limpiar: ejecuta reset y confirma que el tenant vuelve al mismo estado inicial conocido
• Escanea por secretos accidentales: revisa configuración de entorno, logs de servidor y código cliente en busca de claves reales, tokens o valores privados. Si un navegador puede verlo, asume que otros también pueden

Guion corto para el presentador (cuando características están deshabilitadas)

Di una frase y sigue:

• “Esto es un sandbox, así que los mensajes están bloqueados por seguridad.”
• “Los pagos están simulados, pero las pantallas coinciden con el flujo real.”
• “Después de la llamada, reiniciamos esta demo para que todos empiecen frescos.”

Corre esta lista una vez por día de demos. Toma minutos y previene sorpresas.

Ejemplo: una demo segura desde el registro hasta el “upgrade”

Un fundador demoa frente a dos personas en la misma llamada: un inversor y un cliente piloto. El objetivo es mostrar el recorrido completo sin arriesgar emails reales, cargos reales o mensajes accidentales a usuarios.

La demo empieza con un workspace “Acme Demo” limpio que se sembró antes. Ya tiene proyectos realistas, unas tareas y estadísticas de uso de muestra para que las pantallas no se vean vacías. El fundador se registra con un correo nuevo para demostrar que el onboarding funciona. Detrás, el sistema enruta esto a un tenant de demo dedicado y etiqueta la sesión como sandbox mode.

El público pide invitar a un compañero. El fundador escribe un correo real, pulsa Invite y la UI muestra “Invite sent.” Detrás, el email queda suprimido y almacenado en un log de auditoría con una nota como “blocked in demo mode.” Si el cliente piloto pregunta “¿Mi compañero lo recibió realmente?”, el fundador responde: “No, las invitaciones se simulan en este entorno para no escribir a nadie por error.”

Luego llega el momento del upgrade. El inversor quiere ver precios y pago.

Lo que ve la audiencia

Prueban tres acciones: registrarse, invitar a un compañero y subir de plan. El flujo de upgrade acepta un número de tarjeta de prueba y muestra una pantalla de éxito; después la cuenta cambia a “Pro” con límites superiores.

Lo que ocurre tras bambalinas

Los pagos nunca llegan a un procesador real. La app crea un registro de pago de demo, devuelve estado “paid” y mantiene ese estado consistente en facturas y páginas admin. Los webhooks se ignoran para el tenant de demo y cualquier “recibo” por email se suprime.

Después de la llamada, el equipo pulsa un botón de reset (o ejecuta un script) que borra el tenant de demo y lo vuelve a sembrar en el estado conocido bueno.

Próximos pasos: lanzar una demo que no te sorprenda

Empieza eligiendo el lugar correcto para hacer demos. El modo sandbox sirve para seguridad dentro de la misma app: mantienes la UI real pero bloqueas efectos secundarios (emails reales, cargos reales, webhooks reales). Staging es una copia separada de producción: útil para probar releases, pero aún puede enviar emails reales si olvidas una configuración. Muchos equipos necesitan ambos: staging para pruebas de despliegue y sandbox para demos orientadas a clientes.

Si quieres el camino más rápido hacia una demo más segura, impleméntalo en pasos pequeños:

• Bloquea email/SMS reales primero (reemplaza con un log o vista de inbox)
• Haz que los pagos parezcan exitosos sin cobrar tarjetas
• Desactiva webhooks salientes y jobs que hablen con sistemas reales
• Añade un botón de reset para el tenant de demo (o un reset nocturno automático)
• Solo entonces pule los datos seed y los flujos de demo

Añade guardrails que fallen de forma ruidosa. Si alguien accidentalmente demoa en el tenant incorrecto, la app debe negarse a ejecutar acciones riesgosas.

Si heredaste un código generado por IA (Lovable, Bolt, v0, Cursor, Replit), vale la pena que alguien más revise el wiring. FixMyMess (fixmymess.ai) se especializa en diagnosticar y reparar este tipo de efectos secundarios: entornos mezclados, secretos expuestos e integraciones que todavía apuntan a producción, para que una demo sea segura y repetible.