Arquitectura y propiedad

La pregunta que dio forma a todas las demás respuestas: quién es dueño de los datos cuando termina el servicio. Casi todo el software para negocios pequeños contesta esa pregunta con la frase 'nosotros'. El comprador renta el acceso a sus propios datos y paga una suscripción mensual por el privilegio. Los datos viven en la infraestructura del proveedor, detrás de la autenticación del proveedor, gobernados por los términos del proveedor, y el único recurso del comprador es la amenaza de cancelar, que con un aviso contractual de noventa días suele ser más lento que el siguiente ciclo de planeación trimestral. La arquitectura que construí para Canopy invierte eso. El comprador es dueño de los datos, de la infraestructura y de la autenticación, y puede despedirme el día que quiera y seguir operando a la mañana siguiente. Esa es la prueba que la propiedad tiene que pasar de verdad, y le dio forma a todas las demás decisiones técnicas del stack. El mecanismo es que todo es por instalación. Cada instalación de Canopy recibe su propia base de datos Postgres, su propio despliegue en un proyecto de Vercel del comprador, su propio cliente OAuth de acceso con Google conectado a una lista blanca de correos de administración que el comprador controla, su propio dominio registrado a nombre del comprador, su propio certificado SSL emitido para ese dominio, su propia infraestructura de monitoreo y su propio registro de auditoría. El cliente A y el cliente B no comparten nada en ejecución, ni datos, ni superficie de autenticación. No hay un tablero central de administración donde el estudio pueda saltar entre instalaciones eligiendo un cliente de una lista. El estudio tiene acceso a la instalación de un comprador únicamente porque ese comprador agregó a mano el correo del estudio a la lista blanca de esa instalación, y puede revocarlo cualquier día con un solo cambio de configuración. Consideré el patrón estándar de SaaS multi-inquilino: seguridad a nivel de fila dentro de tablas compartidas, un tablero maestro de facturación, un solo despliegue que atiende a todos los clientes. Ese camino es muchísimo más barato de operar para el estudio. La infraestructura es una base de datos, un despliegue, un muro de autenticación, un sistema de facturación; los clientes nuevos se vuelven filas en tablas en lugar de infraestructura por aprovisionar. Casi todos los tableros hechos por agencias se construyen así, porque la alternativa cuesta más de operar. Lo rechacé por el peor caso del comprador. Cada sistema multi-inquilino del que he leído ha terminado por filtrarse entre inquilinos, sea por una configuración equivocada de seguridad a nivel de fila, por una consulta que olvidó el filtro de inquilino, por un administrador que entró al cliente equivocado, o por una brecha del proveedor que afectó la infraestructura compartida. El comprador que importa en esta decisión es el que lee la autopsia y se acuerda, no el que en su peor día tuvo un acceso lento. Si el peor caso para el comprador es que una fila de sus datos aparezca en la cuenta de otra persona, ese peor caso es demasiado malo para diseñar hacia él, y el ahorro operativo no lo vale. La arquitectura por instalación tiene consecuencias que absorbo del lado del estudio. Aprovisionar una instalación nueva es más trabajo que agregar una fila a una tabla: implica crear un proyecto de Vercel nuevo, una base de datos Postgres nueva, un cliente OAuth de Google Cloud nuevo, configurar el DNS, emitir el certificado SSL, correr las migraciones de esquema contra la base vacía, configurar los ajustes de esa instalación y dar de alta al comprador en el acceso de administración. Eso son unas horas de trabajo por instalación en lugar de unos segundos. El costo acumulado de esa decisión es real y la tomé a propósito, porque el costo de la alternativa cae sobre el comprador, y el comprador es quien está pagando. Del patrón por instalación también salen consecuencias de operación. Las actualizaciones de software se despliegan a cada instalación por separado, porque los despliegues son separados. No hay un lanzamiento central. Las migraciones de esquema se aplican a cada base de datos. Los parches de seguridad que tocan la capa de autenticación se despliegan instalación por instalación. Construí herramientas que automatizan esas operaciones desde un solo comando, así que el impuesto operativo está acotado, pero el impuesto es real y el comprador es quien se beneficia de él: su instalación no se migra a otra región sin su permiso, no recibe un cambio de esquema que no aprobó, y no le voltean una bandera de funcionalidad por el ticket de soporte del cliente de alguien más. La autoridad dentro de una instalación se acota con roles por niveles, configurados por comprador. La lista blanca de administración gobierna quién puede entrar siquiera. Ya adentro, la asignación de roles determina qué secciones puede ver un operador, qué registros puede editar, qué ajustes puede cambiar y si puede administrar el acceso de otros operadores. Ninguno de esos permisos cruza los límites de la instalación, y el administrador principal del comprador puede revocar cualquiera de ellos cualquier día sin que el estudio intervenga. Cada cambio a un registro queda atribuido a un operador concreto en el registro de auditoría, y los cambios de asignación de roles también son entradas de auditoría. Toda la arquitectura está diseñada alrededor del principio de que el comprador debe poder responder 'quién hizo qué' en cualquier punto de la historia de su instalación. El registro de auditoría es el sistema de constancia para la atribución de cambios y se trata como inmutable en operación normal. Cada cambio significativo a una entidad guarda una foto del antes y el después, atribuida al operador que lo hizo, con su marca de tiempo y la regla o acción que lo produjo. El administrador principal del comprador puede consultar la auditoría sin ninguna mediación del proveedor. Si el comprador alguna vez necesita investigar algo como 'quién marcó este negocio como cerrado perdido en esta fecha y cuál era el valor anterior', la respuesta está a una consulta de distancia. Si alguna vez necesita investigar una pregunta de seguridad como 'alguien fuera de nuestro equipo de operadores entró al registro de este contacto', la respuesta también está a una consulta. Eso es lo que significa la atribuibilidad en la práctica: no solo que el sistema deje constancia de quién hizo qué, sino que el comprador pueda hacer la pregunta sin que yo esté en medio. La historia de portabilidad también importa. Como la instalación es el despliegue del comprador, su base de datos, su autenticación y su dominio, el comprador se puede llevar el stack completo el día que quiera. No hay un patrón de exportar a CSV que esconda la estructura de los datos detrás de un archivo plano desnormalizado. Los datos ya están en la base de datos del comprador en su forma nativa; puede correr el SQL que quiera contra ellos, replicarlos a otra base de datos, o contratar a otro desarrollador para extenderlos. Las integraciones con las que habla la instalación están configuradas con las credenciales del comprador, no con las del estudio; el comprador puede rotar esas credenciales y el estudio pierde acceso a ellas. El despliegue es el proyecto de Vercel del comprador; puede cambiar los enlaces de despliegue para que apunten a otro repositorio si quiere bifurcar el código. La prueba del despido es la forma más limpia que he encontrado de articular qué tiene que significar la propiedad. Si el comprador despierta una mañana y decide que ya no quiere trabajar con el estudio, debe poder seguir operando a la mañana siguiente. Los datos siguen ahí. La autenticación sigue funcionando. El dominio sigue resolviendo. El despliegue sigue atendiendo tráfico. La auditoría sigue siendo consultable. Las asignaciones de roles siguen vigentes. Nada se rompe, porque el papel del estudio en la instalación siempre fue de asesoría y configuración, nunca algo de lo que dependa la ejecución. El comprador puede entregarle la instalación a otro desarrollador para el mantenimiento continuo, puede extender el código sin que yo participe, y puede operar la instalación durante años sin volver a hablar conmigo. Esa es la prueba que la propiedad tiene que pasar, y la arquitectura por instalación es la versión del sistema que la pasa. La consecuencia operativa que el comprador siente es la que atraviesa en voz baja cada una de las otras secciones de este caso de estudio: una instalación de Canopy es una pieza de infraestructura que el comprador posee por completo, no una suscripción de SaaS con un procedimiento largo de exportación. Los tableros, los datos, la autenticación, el dominio, el rastro de auditoría y el despliegue viven todos donde el comprador guarda el resto de su negocio. El trabajo del estudio es construir la instalación bien y entregarla; el trabajo del comprador es operarla. Esa entrega es el momento en que la propiedad se vuelve real, y la arquitectura es lo que hace de la entrega una línea limpia en lugar de un contrato renovable.