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. Hoy son más de ciento diez pantallas: el pipeline y el buzón y la línea telefónica y el expediente de obra y las facturas y la analítica, todo en el propio dominio del cliente, detrás de su propio inicio de sesión, cargando su propio nombre. 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, el buzón, la línea telefónica, el expediente de obra, facturas y pagos, 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. En concreto, estas son las suscripciones que sustituye, y la razón por la que el conteo es un rango y no un número: una plataforma de analítica, una herramienta de monitoreo de usuarios reales, un rastreador de errores, un monitor de disponibilidad y dominios, un CRM, una herramienta de agenda, una herramienta de secuencias de correo, una herramienta de facturación, una aplicación de servicio en campo con almacenamiento de fotos, un servicio de filtrado o de recepción de llamadas, un portal de cliente y una herramienta de reportes. Nadie está corriendo las doce. La mayoría corre ocho o nueve y sigue pagando la décima por costumbre. 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.

Leer la arquitectura completa de 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.
Continúa en /es/proyectos/canopy/analitica
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.

Leer la arquitectura completa de 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.
Continúa en /es/proyectos/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.

Leer la arquitectura completa de 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.
Continúa en /es/proyectos/canopy/automatizacion
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.

Leer la arquitectura completa de 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.
Continúa en /es/proyectos/canopy/operaciones
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.

Leer la arquitectura completa de 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.
Continúa en /es/proyectos/canopy/pathlight
El correo y la línea telefónica
Dos cosas quedan siempre fuera de cualquier CRM que un negocio pequeño haya comprado: la bandeja de entrada y el teléfono. Así que el seguimiento vive en un lugar, el hilo que lo explica vive en otro, y la llamada que arrancó todo el asunto no vive en ninguna parte. Canopy sostiene los dos. El buzón se refleja, no se reemplaza: la cuenta real sigue siendo la cuenta real, y marcar algo como leído aquí lo marca leído allá. Cada mensaje se hila a la persona de quien vino, la correspondencia completa de un cliente se junta sola en su expediente por dominio, así que un hilo anterior al registro en el CRM también aparece, los adjuntos llegan con el mensaje, y el spam se marca en lugar de esconderse, porque el mensaje que un filtro enterró es justo el que alguien anda buscando. La línea telefónica se filtra antes de sonar. Bloquear spam de uno en uno nunca converge, porque un marcador automático falsea un identificador nuevo en cada llamada y cada bloqueo cae sobre un número que ya no existe. Así que el comportamiento por defecto se invierte: los números conocidos entran directo y nunca escuchan nada, y todos los demás prueban que son personas, dicen quiénes son y qué quieren, y llegan con un resumen de una línea susurrado al operador mientras la llamada conecta. Cada llamada queda registrada con su transcripción y con lo que la operadora telefónica cobró de verdad por ella. Nada se bloquea solo, nunca, porque un bloqueo equivocado tira en silencio a un cliente real y él no recibe ninguna señal de que pasó. Y si el filtro se apaga o algo adentro falla, las llamadas se reenvían directo, sin filtrar. Un filtro roto se comporta exactamente como no tener uno.

Leer la arquitectura completa de El correo y la línea telefónica →
La pregunta de fondo de esta sección: cuánto vale un sistema de registro cuando los dos canales por los que corre el negocio quedan los dos fuera de él. La respuesta es que el buzón se refleja en lugar de reemplazarse, y el teléfono se filtra en lugar de bloquearse. Leer un mensaje en Canopy lo marca leído en la cuenta real, así que trabajar dentro del CRM no duplica el trabajo. El correo se reúne sobre un contacto por dirección, de modo que la correspondencia anterior al registro también llega al expediente. Consideré convertir a Canopy en el cliente de correo. Lo rechacé por dos razones: un operador no abandona un cliente de correo en el que es rápido a cambio de un beneficio de CRM, y meter la correspondencia del comprador dentro de mi software debilita el argumento de propiedad en lugar de reforzarlo. El modo de falla que más cuidé: un filtro que decide solo. Nada bloquea de forma automática, nunca, porque un bloqueo equivocado descarta a un cliente real en silencio y él no recibe ninguna señal de que ocurrió. Cree que llamó y que nadie contestó. El filtro depura y resume; nunca decide. Y si algo en él falla, las llamadas pasan directo sin filtrar, así que un filtro roto se comporta igual que no tener ninguno. La consecuencia operativa: el seguimiento, el hilo que lo explica y la llamada que lo originó están en un solo expediente, puestos ahí por el trabajo y no porque alguien se acordó de archivarlos.
Continúa en /es/proyectos/canopy/correo
Hasta el campo
Un negocio no tiene dirección, ni fotos, ni cuadrilla. Así que una empresa cuyo trabajo ocurre en una propiedad acaba corriendo un CRM para la venta y una aplicación de campo aparte para la obra, con una hoja de cálculo reconciliando las dos y un teléfono lleno de fotos que nadie encuentra. Canopy tiene un expediente de trabajo: una obra en una dirección, cargando al cliente, la propiedad, los oficios, la prioridad, el responsable, y una tira de etapas que escribe su propia historia conforme el trabajo se mueve. Por debajo, un trabajo es un negocio con un expediente de obra encima, y esa es la parte que importa: cada función de dinero, archivos, correo, calendario, automatización y reportes que ya existe en el producto funciona sobre un trabajo desde el primer día, porque todas se apoyan en el mismo registro. Los trabajos no son una isla aparte. El muro de fotos está hecho para el techo, no para el escritorio. Las fotos se ordenan por cuándo se tomaron, no por cuándo se subieron, así que un conjunto que subió en tres tandas se lee en el orden en que la obra realmente ocurrió. Álbumes y etiquetas se editan en el lugar. Y una foto tomada sin señal no se pierde y no espera a nadie: se guarda en el teléfono en el momento en que se elige y se sube sola cuando vuelve la cobertura, esté o no la aplicación abierta. Fotografíe el techo, regrese a cobertura, y llega. Todo el panel se instala en el teléfono como aplicación, sin nada que descargar de una tienda y sin una segunda contraseña. Instalarlo cambia dónde vive, no lo que puede hacer.

Leer la arquitectura completa de Hasta el campo →
La pregunta que dio forma a esta sección: qué le falta a un registro de negocio cuando el trabajo no ocurre en un escritorio. La respuesta es que un trabajo es un negocio con un registro de obra encima, no un tipo de registro nuevo. Todo lo que ya existe en la instalación, dinero, archivos, correo, calendario, automatización e informes, funciona sobre un trabajo desde el primer día, porque todo se apoya en el mismo registro. Consideré construir la obra como su propio módulo con sus propios registros, que es la forma habitual. Lo rechacé porque entonces cada capacidad existente tendría que extenderse para conocer los trabajos, una por una, para siempre, y las que se quedaran atrás serían invisibles hasta que un operador fuera a buscarlas. El modo de falla que más cuidé: la foto tomada donde no hay señal. Un techo, un sótano, una propiedad rural. La foto se guarda en el teléfono en el momento en que se elige y se sube sola cuando vuelve la cobertura, siga o no abierta la aplicación. El trabajo de quien está en la obra es tomar la foto, y ese es todo su trabajo. La consecuencia operativa: ninguna hoja de cálculo en medio, porque no hay dos sistemas que conciliar. La venta, la obra, la evidencia, la factura y el margen son un mismo registro continuo.
Continúa en /es/proyectos/canopy/campo
El dinero, y el registro que lo acompaña
La mayoría de los CRM para negocios pequeños se detiene en ganado. Todo lo que viene después, la factura, el pago, lo que la obra costó entregar de verdad, y el reporte que el cliente merece a fin de mes, regresa a una hoja de cálculo y a un procesador de texto. Canopy corre el resto. Una cotización se vuelve factura, una factura se congela en el momento en que se emite y su PDF ya no cambia, y los pagos registrados contra ella la caminan por su propio estado sin que nadie lo fije a mano. Una corrección es una cancelación con motivo y una reemisión con número nuevo, nunca una edición silenciosa del documento que alguien ya tiene. Los recordatorios recurrentes se disparan la mañana que toca y luego se reprograman solos, así que un día perdido se dispara una vez y conserva el calendario original. El vencimiento se calcula desde la fecha límite cada vez que se dibuja la página, no por un proceso de fondo que pudo no haber corrido. El costo de entrega se registra contra el trabajo al que pertenece, horas o gastos, para que el margen de un cliente sea un número que se lee y no un número que se supone. Utilidad y salud pone el efectivo recibido junto a lo que se registró para ganarlo, con una gráfica de doce meses y una tabla por cliente al lado. Y el reporte mensual al cliente se arma con lo que la instalación ya tiene. La parte que más me importa es lo que hace cuando no tiene respuesta: una sección vacía se queda en la página y dice de qué tipo de vacío se trata. Medido significa que la respuesta está aquí. Nada este periodo significa que busqué y genuinamente no hubo. No se puede medir significa que eso no lo alcanzo a ver para este cliente. Son tres afirmaciones distintas, y una sección que desaparece el mes en que su número empeoró le suena al cliente a que algo se está escondiendo. La exclusión honesta: el lado de costos cuenta lo que Canopy mismo registra, así que el margen es una lectura sobre sus propios datos de operación, no una cifra contable. El libro se exporta a CSV para quien le lleve la contabilidad.

Leer la arquitectura completa de El dinero, y el registro que lo acompaña →
La pregunta que abre esta sección: qué le pasa a un negocio pequeño en el momento exacto en que su CRM dice ganado. Lo que pasa es que el software se detiene y empiezan las hojas de cálculo. Así que Canopy corre el resto: una cotización se vuelve factura, una factura emitida se congela y su PDF no vuelve a cambiar, y los pagos registrados la mueven por su propio estado sin que nadie lo fije a mano. Consideré dejar la factura editable, que es lo que un procesador de texto regala de entrada. Lo rechacé porque un documento financiero es una afirmación de la que otra persona tiene una copia. Una corrección es una anulación con motivo y una reemisión con número nuevo, nunca una edición silenciosa de un documento que ya está en la bandeja de un cliente. El modo de falla que más cuidé: un proceso en segundo plano que decide qué está vencido. Si ese proceso no corre, el reporte de antigüedad se ve sano y nada indica que el número está viejo. Lo vencido se calcula desde la fecha de vencimiento cada vez que la página se dibuja, así que no puede equivocarse con el calendario. La exclusión honesta: el lado de costos cuenta lo que Canopy mismo registra, así que el margen es una lectura sobre sus propios datos de operación, no una cifra contable. Se exporta a CSV para quien lleve los libros. La consecuencia operativa: la cadena de la cotización al margen no tiene ningún hueco donde un número se vuelva a teclear, se redondee o se olvide.
Continúa en /es/proyectos/canopy/dinero
Un asistente, con correa
Un asistente que puede leer su negocio es genuinamente útil. Un asistente que puede cambiarlo sin preguntar es un pasivo que alguien más tiene que limpiar. Canopy trata eso como dos decisiones distintas, y la segunda viene apagada de fábrica. De entrada, el asistente lee. Responde desde sus registros de verdad, acotado a exactamente lo que su propio inicio de sesión ya podía ver, y está instruido para consultar lo pertinente antes de explicar por qué algo se ve mal, y para decir claramente que no puede ver algo en vez de ofrecer una causa que no verificó. Dejarlo actuar se enciende carril por carril. El carril seguro se ejecuta de inmediato y es seguro por construcción: cada acción es reversible, toca un solo registro, tiene tope por mensaje, y queda en la bitácora de auditoría a su nombre. Los carriles que borran algo o envían algo no actúan en absoluto. Arman una tarjeta con una lectura fresca del registro, muestran exactamente lo que va a pasar, y esperan un clic. Las tarjetas son de un solo uso y expiran. La regla debajo de todo: el asistente actúa solo sobre lo que usted escribe. El contenido dentro de un registro, un correo entrante, una nota, un campo importado, nunca puede autorizar una acción, y los carriles de confirmar primero se sostienen de todos modos. Cada llamada de IA cruza las mismas tres verificaciones independientes que cuidan un escaneo pagado, incluido un presupuesto mensual en dólares que arranca en cero, y cada llamada se mide hasta lo que costó. La exclusión honesta: esto no es un agente al que se le entrega el negocio. Es un lector rápido con una correa corta, y la correa es un ajuste que usted controla.

Leer la arquitectura completa de Un asistente, con correa →
La pregunta que definió la forma de esta función: qué se le debe permitir hacer por su cuenta a un asistente con acceso a un negocio. Nada, hasta que el comprador diga lo contrario, una capacidad a la vez. De fábrica lee, con el alcance exacto de lo que el propio inicio de sesión de esa persona ya podía ver. Dejarlo actuar se enciende carril por carril. Consideré el agente de propósito general, con permisos amplios de escritura y confianza en su criterio. Lo rechacé porque el comprador es un negocio pequeño sin equipo de seguridad y sin entorno de pruebas. El modo de falla de un agente amplio no es un error visible; es una acción equivocada de aspecto razonable, aplicada sobre cuarenta registros a las dos de la mañana y descubierta una semana después por un cliente. El modo de falla que más cuidé: una instrucción que llega como contenido. Un correo entrante, una nota, un campo importado, un nombre que un desconocido escribió en un formulario. Ninguno puede autorizar una acción, y los carriles que piden confirmación se sostienen sin importar lo que cualquiera de ellos diga. Los datos son datos. Solo quien escribe es la persona. La exclusión honesta: este no es un agente al que se le entrega el negocio. Es un lector rápido con correa corta, y la correa es un ajuste que usted controla. La consecuencia operativa: el noventa por ciento útil desde el primer día, con cada acción irreversible detrás de un clic que usted dio o de un interruptor que usted encendió.
Continúa en /es/proyectos/canopy/asistente
Su marca, sus módulos, su nombre encima
La forma más rápida de que un portal de cliente se sienta como software de alguien más es dejarle encima el nombre de alguien más. Así que una instalación de Canopy no es un tema visual sobre un sistema compartido. Es el sistema completo, cargando el nombre, la marca y los colores del comprador, con las partes que no necesita apagadas. Un solo código corre despliegues que se ven y se comportan como productos distintos: su propio nombre de producto, su propio logotipo, su propia paleta de acento en toda la interfaz, su propio asistente con su propio nombre y su propia frase de apertura, sus propias puertas de acceso, y su propio conjunto de módulos. Un negocio que no tiene buzón en el portal no recibe una bandeja vacía. Un negocio que nunca va a comprar un escaneo no recibe una pestaña para eso sentada permanentemente en cero, invitándolo a preguntarse qué se está perdiendo. Esa es la parte del argumento de propiedad que de verdad se puede probar. El resto es arquitectura: una instalación es una base de datos, un inicio de sesión y un despliegue, todos del comprador, sin infraestructura compartida entre él y nadie más. No hay una cuenta central mía por la que pasen los datos. Por eso el argumento es honesto y no un eslogan. Literalmente no hay nada que se pueda filtrar entre clientes, porque en la instalación no hay otros clientes. El acceso son cuatro niveles, asignados por persona y revocables en cualquier momento, y una cuenta deshabilitada no puede entrar en absoluto. Cada entidad se exporta a CSV y la base de datos completa se exporta de una vez, desde un control en la página de ajustes y no desde un ticket de soporte, porque la prueba que la propiedad tiene que pasar es que usted pueda correrme y seguir operando mañana en la mañana.

Leer la arquitectura completa de Su marca, sus módulos, su nombre encima →
La pregunta que responde esta sección: qué tiene que ser cierto antes de que un comprador ponga su propio nombre sobre software que construyó otra persona. Un solo código corre despliegues que se leen como productos distintos: su nombre, su marca, su paleta, su asistente, sus puertas de entrada y su conjunto de módulos. Un negocio sin buzón no recibe una bandeja vacía. Un negocio que nunca comprará un diagnóstico no recibe una pestaña fija en cero. Consideré un solo despliegue que sirva a todos los clientes y resuelva la marca por petición según el dominio, que es lo que hace casi todo en esta categoría. Lo rechacé porque en ese diseño la marca del comprador es una fila que mi código consulta en cada petición. Si la consulta sale mal en una sola versión, el cliente del comprador ve el nombre de otra empresa en el portal del comprador. El modo de falla que más cuidé queda eliminado en lugar de defendido: una instalación es una base de datos, un inicio de sesión y un despliegue. No hay ninguna columna de inquilino en ninguna parte que se pueda consultar mal, porque no hay otros clientes dentro de la instalación. La exclusión honesta: la capa de marca blanca es real y está corriendo, pero qué cliente usa qué edición les toca decirlo a ellos, no a mí. Las tres instalaciones del recorrido son inventadas. La consecuencia operativa: la salida es un control en la página de ajustes, no un ticket de soporte, porque la propiedad solo significa algo si usted puede ejercerla un martes por la tarde.
Continúa en /es/proyectos/canopy/marca
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.

Leer la arquitectura completa de 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.
Continúa en /es/proyectos/canopy/arquitectura
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.
Usted es dueño de toda la pila
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.
Telemetría de primera mano
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.
Visitantes reales, no ruido de rastreadores
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.
Privacidad por diseño
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.
Visible antes de que muerda
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.