Canopy
Un panel de administración de sistema operativo que construí primero para el estudio que lo entrega, y después desplegué como instalación cero para un cliente real. The Star Auto Service, en Richardson, Texas, es el primer Canopy externo: saca a la superficie datos de visitantes de primera mano, rendimiento, embudo, automatización, salud de operaciones y prospección impulsada por Pathlight, todo en el propio dominio del cliente y detrás de un inicio de sesión de Google. Hoy es un compromiso productizado, desde $30,000 y entregado en aproximadamente cuatro a ocho semanas, con la licencia del código para que el comprador lo opere en casa.
Construido primero para mí, para operar DBJ Technologies. The Star Auto Service es la instalación cero, el campo de pruebas de la arquitectura detrás del compromiso productizado de Canopy.
El problema
La mayoría de los negocios pequeños opera sobre una pila de suscripciones SaaS separadas que no se hablan entre sí. La analítica en una herramienta. El monitoreo de rendimiento en otra. El seguimiento de errores en una tercera. La entregabilidad regada en la plataforma de correo que se haya elegido. Un CRM que nadie actualiza. Hojas de cálculo tapando los huecos. Cada herramienta cobra una cuota mensual. Cada herramienta es dueña de los datos. Cada herramienta tiene su propio acceso, su propia interfaz de administración, sus propios límites de exportación, su propio correo de "vamos a descontinuar esa función". El costo se acumula. Los datos se fragmentan. Y el comprador nunca obtiene lo único que de verdad necesita: una sola imagen de su negocio que una lo que hizo mercadotecnia con en qué se convirtieron de verdad los clientes. El consejo estándar es "nada más usa las integraciones". Pero las integraciones se rompen, las integraciones dejan de ser gratis, y las integraciones dejan los datos en el centro de datos de alguien más. Para cuando un negocio pequeño está gastando de cientos a miles al mes en suscripciones SaaS por capacidades que podría poseer por completo, la alternativa arquitectónica ya no es obvia. Nada más parece el costo de hacer negocios. No es el costo de hacer negocios. Es el costo de aceptar la dispersión de SaaS como algo inevitable.
Qué recibe
Un solo panel. Un solo muro de autenticación. Una sola fuente de verdad. En el dominio del comprador, en la base de datos del comprador, detrás del inicio de sesión del comprador. Canopy es el panel de sistema operativo que construí primero para operar DBJ Technologies, y después entregué como la primera instalación externa a The Star Auto Service. El mismo código base, la misma arquitectura, configurada por instalación. Visitantes, usuarios recurrentes, embudos, comportamiento de búsqueda, métricas de rendimiento, oportunidades, contactos, empresas, cotizaciones, pronóstico, un calendario sincronizado con páginas públicas de reserva, secuencias, automatizaciones, salud de infraestructura, entregabilidad, volumen de errores y margen de presupuesto viven todos en un solo lugar. El comprador entra a una sola URL, ve un solo aviso que resume lo peor de cada señal de toda la pila, y profundiza en la sección que necesita atención. Nada se renta. La base de datos Postgres es del comprador. El muro de autenticación es del comprador. El dominio es del comprador. El registro de auditoría captura cada cambio significativo, para que una actualización equivocada sea recuperable. La arquitectura es por instalación, no multiinquilino, así que no hay infraestructura compartida que se filtre entre clientes ni proveedor a quien llamarle cuando algo se rompe. Lo construí primero para mí, lo que significa que cada decisión es la que tomé cuando el cliente era yo.
Analítica y rendimiento
El comprador gasta en plataformas de analítica, herramientas de monitoreo de usuarios reales y servicios de inteligencia de búsqueda, y aun así no puede responder la pregunta que importa: cuál visitante se volvió cuál cliente. Canopy captura datos de visitantes de primera mano, comportamiento de usuarios recurrentes, embudos de conversión, consultas de búsqueda y Web Vitals directo en el Postgres del comprador. Cada evento lleva marca de tiempo y es consultable. Los datos de rendimiento viven junto a los de conversión, en la misma base de datos, con la misma puerta de autenticación. Cuando aparece una regresión después de un despliegue, el comprador la ve en el mismo panel donde revisa su embudo. Sin cambiar de pestaña. Sin reconciliar exportaciones entre un SaaS y otro. Sin la conversación trimestral sobre si los números de la herramienta de analítica y los del CRM coinciden. Son los mismos números, en la misma base de datos, propiedad del mismo comprador. La exclusión honesta: Canopy no está construido para sistemas con miles de millones de eventos al día. Está construido para negocios pequeños que hacen de miles a decenas de miles de eventos al día, donde la propiedad arquitectónica importa más que la escala horizontal.

Read the full architecture of Analítica y rendimiento →
La pregunta que hice primero: qué cambia cuando los datos de visitantes y los de conversión viven en la misma base de datos bajo la misma puerta de autenticación. La respuesta es el tipo de pregunta que se puede hacer. Con analítica de terceros se puede preguntar "cuál fue mi tasa de rebote la semana pasada". No se puede preguntar "de los prospectos que se volvieron oportunidades el trimestre pasado, de qué fuente de mercadotecnia vinieron y cuál fue su tiempo mediano de cierre". Esa segunda pregunta exige unir dos sistemas que el contrato del SaaS no deja unir, y la reconciliación de exportaciones que finge soportarla nunca termina de coincidir. Consideré la pila estándar: un SDK de analítica en el frontend, el CRM por su API, un puente de webhooks entre los dos. La rechacé porque cada capa le renta al comprador el acceso a sus propios datos, y el puente es lo primero que se rompe. Lo que Canopy hace en su lugar: la captura de visitantes escribe directo en el Postgres del comprador. La captura de conversión también escribe ahí. Los Web Vitals, la profundidad de desplazamiento y el tiempo de permanencia publican en la misma tabla. La presión de bots se separa de los visitantes reales en la capa de ingesta, para que las cifras principales se queden honestas. El panel lee desde vistas ya agregadas para seguir siendo rápido conforme crecen los datos. La consecuencia operativa: cuando aparece una regresión después de un despliegue, el comprador puede responder "¿esto es real o nada más presión de bots?" contra la misma base de datos que guarda el embudo. Sin cambiar de pestaña. Sin junta trimestral sobre de quién son los números correctos.
Continued at /work/canopy/analytics
Embudo y relaciones
Oportunidades regadas en hojas de cálculo. Seguimientos que se caen por las grietas. Registros de contacto actualizados por última vez cuando el equipo se acordó. El CRM que nadie actualiza es el software más caro que puede comprar un negocio pequeño, porque no produce valor alguno a precio completo. Canopy tiene la etapa de la oportunidad como eje principal. El tablero kanban del embudo es la fuente de verdad de dónde está parado cada prospecto. La vista de detalle del contacto reúne cada interacción que el comprador haya tenido con esa persona, de forma automática: envíos de formulario, reportes de escaneo, respuestas de correo, llamadas registradas, notas agregadas, cambios de etapa. Nada tiene que copiarse a mano entre sistemas porque no hay otros sistemas. Las acciones en bloque manejan las operaciones repetitivas. La navegación por teclado funciona como espera un operador que vive en la herramienta todos los días. Cada cambio escribe una instantánea de antes y después en el registro de auditoría, así que la pregunta "quién marcó esta oportunidad como perdida y cuándo" tiene una respuesta definitiva en lugar de un hilo de mensajes. Las cotizaciones y sus partidas se construyen sobre un catálogo de productos compartido. Puede correr más de un embudo a la vez, cada uno con sus propias etapas y una marca cuando una oportunidad lleva demasiado tiempo parada. Los contactos duplicados se fusionan limpiamente, una búsqueda global alcanza cada registro, y cuando un prospecto ha sido escaneado, lo que el escaneo aprendió de su negocio aparece justo en el contacto. El embudo acumula pronósticos ponderados. La línea de tiempo del contacto reconcilia con el registro de auditoría. Los datos son del comprador, y el equipo del comprador puede irse cuando quiera y llevarse la base de datos completa.

Read the full architecture of Embudo y relaciones →
La pregunta que guía el modelo de datos: qué significa decir que un CRM es "la fuente de verdad". Para la mayoría de los CRM de negocio pequeño la respuesta es "lo que sea que haya escrito la última persona que tocó el registro". Eso no es verdad, es la creencia más reciente. Canopy trata la verdad como el registro de auditoría. Cada cambio significativo escribe una instantánea de antes y después atribuida al usuario que lo hizo. El estado actual de cualquier registro es la proyección de esos eventos. La implicación es que la base de datos puede responder preguntas que el equipo no sabía que iba a hacer cuando escribió el registro, porque los eventos siguen ahí para reproducirse. Consideré hacer del estado del contacto el eje principal, con la oportunidad como campo derivado del contacto. Lo rechacé porque todo negocio real tiene clientes que regresan y oportunidades paralelas. Colapsar el estado de la oportunidad dentro del estado del contacto pierde el segundo compromiso, y el segundo compromiso es donde vive la mayor parte de los ingresos. Así que las oportunidades son el eje; el estado del contacto es un espejo desnormalizado que se conserva por compatibilidad, no la fuente de verdad. La vista de detalle del contacto reúne cada interacción que el comprador haya tenido con esa persona, de forma automática. Envíos de formulario, respuestas de correo, reportes de escaneo, llamadas registradas, citas agendadas, notas agregadas, cambios de etapa, todo en una sola línea de tiempo. Nada tiene que copiarse a mano entre sistemas porque no hay otros sistemas. La consecuencia operativa: alguien del equipo se va, la base de datos se queda. Las preguntas son consultables. Las respuestas son verificables. La exportación, si algún día ocurre, es la propia base de datos del comprador.
Continued at /work/canopy/pipeline
Automatización
Los seguimientos manuales son por donde se fugan los ingresos. El recordatorio del calendario se descarta. El "le escribo mañana" nunca pasa. El cambio de etapa de la oportunidad no dispara ninguna de las cosas que deberían seguirle. Canopy corre secuencias, flujos y automatizaciones basadas en reglas sobre el registro de auditoría. Las secuencias mandan salidas de varios pasos con salida por respuesta, así que un prospecto que contesta deja de recibir el siguiente mensaje de la cadena. Los flujos se disparan con eventos del dominio: una oportunidad nueva llega a una etapa, una oportunidad vieja se queda callada por una ventana larga, un reporte de escaneo marca un hallazgo que amerita seguimiento. Las reglas se condicionan sobre lo que cambió en el registro de auditoría, lo que significa que puedo expresar "cada vez que una oportunidad pase a propuesta, manda el correo de prueba de oficio y asigna una tarea de seguimiento" sin escribir código a la medida. Las plantillas de correo llevan versión. Las acciones en bloque cubren los casos donde automatizar sería exagerado. Cada acción automatizada escribe en el registro de auditoría con la regla que la disparó, así que cuando algo se automatiza y no debía, la respuesta está a una consulta de distancia. Las reglas de flujo ahora se construyen de forma visual, con condiciones y-o y ramas si-entonces, sin código. Las notificaciones dentro de la aplicación y las menciones entre compañeros mantienen al equipo al tanto, y cada persona puede guardar sus propias vistas filtradas del embudo. La exclusión honesta: esta no es una suite de automatización de mercadotecnia para programas de ciclo de vida de mil pasos. Está construida para operadores de equipo pequeño que necesitan que las siguientes diez cosas pasen sin tener que recordarlas.

Read the full architecture of Automatización →
Dos formas de conectar reglas de automatización: como efectos secundarios en la ruta de escritura, o como suscriptores a un registro de eventos duradero. Elegí la segunda. Cada mutación en Canopy escribe primero en el registro de auditoría; las reglas leen del registro y actúan. Eso es unos cientos de milisegundos más lento que disparar las reglas en línea. También es la razón por la que una regla que se dispara mal es recuperable. La acción registra la regla que la disparó. La mutación registra al actor. El registro de auditoría guarda las dos. Así que la pregunta "por qué se mandó este correo" tiene una consulta, no una sesión de depuración contra los registros internos de un proveedor. Consideré un constructor de automatización sin código con programas de ciclo de vida de cien pasos y ramificaciones. Lo rechacé porque el operador que necesita eso ya compró Hubspot. El operador que todavía no ha comprado nada necesita que las siguientes diez cosas pasen sin tener que recordarlas, no un programa de cien pasos que nadie en el edificio entiende para el cuarto mes. El mecanismo: las secuencias son salidas de varios pasos con salida por respuesta, así que un prospecto que contesta deja de recibir el siguiente mensaje de la cadena. Las reglas de flujo se condicionan sobre lo que cambió en el registro de auditoría. Las plantillas de correo llevan versión para poder revertir una sin perder el historial de envíos. La exclusión honesta: esto no es software de mercadotecnia de ciclo de vida. Está construido para operadores de equipo pequeño que necesitan que la automatización sea una ayuda de memoria, no una estrategia. Cuando algo se automatiza y no debía, la regla que se disparó está a una consulta de explicarse sola.
Continued at /work/canopy/automation
Operaciones y salud
La mayoría de los negocios pequeños no puede responder "¿está todo bien ahora mismo?" sin revisar cinco paneles distintos. El estado del despliegue está en un lado. El volumen de errores en otro. El vencimiento del certificado TLS no está en manos de nadie. La entregabilidad es lo que haya dicho el último reporte de rebotes del proveedor de correo. La imagen de costos es una hoja de cálculo que alguien actualiza cada mes. Canopy colapsa todo eso en un solo aviso en la parte alta del panel. Lo peor de cada señal: verde cuando todo está bien, ámbar cuando algo necesita atención esta semana, rojo cuando algo necesita atención ahora mismo. Profundice en el aviso y se abre el subsistema correspondiente con los datos de abajo: vencimiento de TLS por dominio, expiración de WHOIS, estado de autenticación de correo, entregabilidad en tiempo real, volumen de errores a nivel de función, gasto en tiempo real contra los techos de presupuesto configurados. Las revisiones de salud de infraestructura corren en un cron diario y escriben en el registro de auditoría, así que un certificado TLS de un dominio que va a vencer se saca a la superficie mucho antes de que venza. Si la entregabilidad se degrada porque la autenticación del dominio remitente no pasó la validación, el aviso lo refleja en la siguiente revisión. Todo el punto de la telemetría de operaciones es interrumpir al operador cuando importa y quedarse callada cuando no. Operaciones no es un panel que uno visita. Es un aviso en el que uno confía.

Read the full architecture of Operaciones y salud →
La pregunta que moldeó la superficie: qué necesita ver de verdad un operador, y qué es nada más panel bonito. Casi toda superficie de operaciones intenta mostrar todo. Cinco gráficas, doce medidores, una docena de widgets. El operador o se entrena a sí mismo para ignorar la página, o responde en pánico al medidor que casualmente esté en amarillo. Ninguno de los dos resultados sirve. Construí la superficie de operaciones de Canopy alrededor de la disciplina inversa: quedarse callada hasta que algo importe. El estado por omisión es un solo aviso que resume la peor señal de toda la pila. Verde significa que todo lo que me molesto en monitorear está bien. Ámbar significa que algo necesita atención esta semana. Rojo significa que algo necesita atención ahora mismo. El operador visita el panel por el trabajo al que vino, no porque la página de operaciones le exija atención. Consideré alertas en tiempo real siempre encendidas. Las rechacé porque la mayoría de los negocios pequeños recibe tres alertas y luego silencia el canal, y un canal silenciado es peor que ningún canal, porque fabrica confianza falsa. Un cron diario alcanza para todo lo que reviso en la capa de operaciones: vencimiento de certificado, expiración de dominio, postura de autenticación de correo. El tiempo real se reserva para las señales que de verdad cambian minuto a minuto, entre ellas la salud del despliegue y la entregabilidad del correo. El modo de falla contra el que construí: un certificado TLS venciendo a las dos de la mañana. El aviso reflejó ese riesgo en la revisión del día anterior, antes de que ningún visitante llegara a un sitio roto. Al comprador se le avisó en horario laboral, cuando los avisos pueden convertirse en tickets en lugar de en incidentes.
Continued at /work/canopy/operations
Integración con Pathlight
Pathlight es la plataforma de diagnóstico de sitios web que DBJ opera como la parte alta de su embudo de ventas. Canopy es donde las señales de Pathlight se vuelven flujos de trabajo para el operador: investigación de candidatos de prospección, monitoreo de cambios en sitios de clientes existentes con reescaneos disparados a mano, y escaneos de inteligencia competitiva sobre competidores directos del comprador. Cada llamada a Pathlight desde dentro de Canopy pasa por barreras de protección antes de dispararse. Los límites de gasto, las reglas de alcance y las condiciones de disparo tienen que pasar todas; si alguna bloquea la llamada, no se dispara nada y el operador ve por qué. El comprador nunca recibe una factura sorpresa por un ciclo desbocado, porque la arquitectura no permite ciclos desbocados. Los candidatos de prospección fluyen al embudo con el contexto de su escaneo adjunto. Las alertas de monitoreo de cambios aparecen en el aviso de operaciones. Los escaneos competitivos se guardan junto al registro del prospecto, para que la siguiente conversación tenga contexto. La integración es opcional, monitoreada y con tope, que es la única manera en que una partida de costo por llamada pertenece a un compromiso productizado. La exclusión honesta: esta integración va incluida con Canopy, no se vende por separado. Pathlight como producto independiente tiene su propia superficie. Esta sección describe cómo Canopy lo usa.

Read the full architecture of Integración con Pathlight →
La pregunta que abre esta sección: cómo se le permite a un operador apretar un botón que le cuesta dinero real al estudio, sin exponer al comprador a una factura desbocada. La respuesta son barreras que tienen que pasar todas: límites de gasto, reglas de alcance y condiciones de disparo, cada una capaz de detener la llamada. Si alguna bloquea la llamada, no se dispara nada y el operador ve por qué. El comprador nunca recibe una factura sorpresa por un ciclo desbocado, porque la arquitectura no permite ciclos desbocados. Consideré escaneos programados en segundo plano con cobro por uso. Lo rechacé porque el costo por llamada corre hacia ciclos desbocados más rápido que cualquier otra partida que yo haya entregado, y un negocio pequeño no puede absorber "el sistema escaneó ochocientos sitios mientras usted dormía, su cuenta es de cuatrocientos ochenta dólares". El encuadre honesto: un cargo externo por llamada pertenece a un compromiso productizado solo cuando es un máximo mensual conocido, no un comodín. El modo de falla que cuidé con más atención: dos clics de administrador en el mismo instante cuando al presupuesto le queda margen para un escaneo. Los dos tienen que no pasar. Verificar y reservar de forma atómica, no verificar y luego reservar. Un escaneo se dispara, el otro recibe un bloqueo visible para el usuario. La consecuencia operativa: la partida por llamada es un máximo mensual conocido, cada mes, por construcción.
Continued at /work/canopy/pathlight
Arquitectura y propiedad
Casi todo el software para negocios pequeños vive en el centro de datos de alguien más, detrás de la autenticación de alguien más, gobernado por los términos de servicio de alguien más. El comprador renta el acceso a sus propios datos y paga una suscripción mensual por el privilegio. Canopy invierte eso. Base de datos Postgres por instalación, inicio de sesión de Google por instalación con una lista de permitidos solo para administradores, despliegue por instalación en un proyecto de Vercel que el comprador posee. Sin infraestructura compartida entre clientes. Sin base de datos multiinquilino que se filtre entre cuentas. Sin correo de "lo estamos migrando a una región nueva". Los datos del comprador viven en una base de datos que el comprador paga directamente, detrás de un dominio que el comprador le pagó directo al registrador, con un certificado SSL emitido a nombre del comprador. El control de acceso basado en roles gobierna quién ve qué, con varios niveles de permiso configurables por instalación. Cada cambio significativo de entidad escribe una instantánea de antes y después en el registro de auditoría, atribuida al usuario que lo hizo. El registro de auditoría es consultable. Las asignaciones de rol son revocables. Toda la arquitectura es del comprador para inspeccionarla, modificarla, auditarla o migrar fuera de ella. Si a mí me atropella un camión, el comprador se queda con su base de datos, su autenticación, su dominio, sus datos y su sistema operativo. Eso es lo que de verdad significa la propiedad.

Read the full architecture of Arquitectura y propiedad →
La pregunta que moldeó todas las demás respuestas: de quién son los datos cuando termina el compromiso. Casi todo el software para negocios pequeños responde esa pregunta con "nuestros". Canopy la responde con "suyos". Base de datos Postgres por instalación, inicio de sesión de Google por instalación con una lista de permitidos solo para administradores, despliegue por instalación en un proyecto de Vercel que el comprador posee. El comprador le paga a Neon directo. El comprador le paga a Vercel directo. El comprador le paga a su registrador de dominio directo. No hay infraestructura compartida entre clientes. No hay base de datos multiinquilino que se filtre entre cuentas. No hay correo de "lo estamos migrando a una región nueva". Consideré un SaaS multiinquilino con seguridad a nivel de fila y un panel maestro de facturación. La infraestructura es más barata de operar así y la historia de soporte es más simple para mí. Lo rechacé porque todo sistema multiinquilino del que he leído terminó filtrándose entre inquilinos alguna vez, y el comprador que importa es el que lee el análisis del incidente y lo recuerda. Si el peor caso para el comprador es que aparezca un renglón suyo en los datos de alguien más, ese peor caso es demasiado malo. El control de acceso basado en roles gobierna quién ve qué, con varios niveles de permiso configurables por instalación. Cada cambio significativo es atribuible. Las asignaciones de rol son revocables. El registro de auditoría es consultable. La consecuencia operativa: una instalación de Canopy se puede inspeccionar, modificar, auditar o migrar sin mi permiso. El comprador me puede correr y seguir operando mañana en la mañana. Esa es la prueba que la propiedad tiene que pasar.
Continued at /work/canopy/architecture
Qué sigue
Canopy es hoy un compromiso productizado. Arranca en $30,000, se dimensiona por comprador, y se entrega en aproximadamente cuatro a ocho semanas. The Star Auto Service fue la instalación cero, el campo de pruebas, y hoy corre la pila completa en vivo. Lo que usted compra es el sistema operativo entero, levantado en su propio dominio, en su propia base de datos, detrás de su propio inicio de sesión, con el código licenciado a usted para operarlo y modificarlo en casa. Una cotización se construye por partes, no como un número redondo: el trabajo de implementación para migrar, integrar, marcar en blanco y personalizar; la licencia de código para uso interno; y, si yo lo alojo, una partida mensual con tope para hosting y soporte. Una personalización más pesada y la cobertura completa de Pathlight llevan el compromiso hacia la parte alta de la banda. Si tiene un negocio con ingresos reales, dispersión de SaaS y ganas de poseer la pila en lugar de rentarla, la forma más rápida de saber si Canopy encaja es una conversación de treinta minutos. Lo dimensiono, descompongo el número, y le muestro el costo a tres años de poseer Canopy contra la pila de suscripciones que reemplaza.
Las decisiones técnicas detrás de esta construcción.
You Own the Whole Stack
Cada instalación es su propia base de datos, su propio muro de autenticación, su propio dominio. Sin infraestructura multiinquilino compartida que mezcle los datos de un cliente con los de otro. Sin un acceso de proveedor que su equipo tenga que recordar. Sin contrato SaaS que renovar. El panel, los datos y las llaves viven todos donde el comprador guarda el resto de su negocio.
First-Party Telemetry
Analítica de visitantes, Web Vitals, profundidad de desplazamiento y tiempo de permanencia capturados desde el propio sitio del comprador y publicados directo en su propio panel. Sin SDK de terceros cargado. Sin script externo disparándose en cada página. Sin datos saliendo de la infraestructura del comprador para agregarse en otro lado y revenderse. Lo que se captura es lo que el comprador pidió, punto.
Real Visitors, Not Crawler Noise
La presión de bots es real y la mayoría de los paneles o la sobrecuenta (inflando cifras de vanidad) o la subcuenta (escondiendo un problema). Canopy separa el tráfico de bots del humano en la capa de ingesta, para que las cifras principales reflejen clientes potenciales de verdad, mientras la presión de bots se sigue mostrando con honestidad cuando el comprador quiere verla.
Privacy-First by Design
Las IP crudas de los visitantes nunca se persisten. Los identificadores son de primera mano únicamente, no cookies de rastreo de terceros. Toda la tubería de captura asume que alguien va a preguntar "¿puede defender esto ante un cuestionamiento de privacidad?", y la respuesta es sí. Esa postura también prepara la instalación para la siguiente ronda de desapariciones de cookies.
Surfaced Before It Bites
Postura de certificado, de dominio y de autenticación de correo revisada a diario por cada dominio monitoreado. Salud de despliegue y entregabilidad de correo ingeridas en tiempo real. El panel es rápido incluso cuando los datos de abajo son grandes, porque lee desde vistas ya agregadas. Los problemas aparecen como advertencias antes de volverse caídas.
Construido primero para DBJ Technologies como mi propio panel de sistema operativo interno. The Star Auto Service, en Richardson, Texas, es la instalación cero, la primera prueba externa de que la arquitectura se transfiere limpiamente fuera de la pila del estudio y hacia la de alguien más. Cada instalación se entrega como infraestructura propia del cliente, en sus propias cuentas, estructurada para que él la siga desplegando mucho después de que el trabajo termine.