La autonomía es una arquitectura, no una promesa

Cualquier proveedor puede escribir un párrafo sobre cuánto respeta sus datos. No cuesta nada y no protege nada. La única versión de esa afirmación que vale algo es estructural: construir el producto de modo que el proveedor sea técnicamente incapaz de guardar sus registros. Esa restricción dio forma a cada decisión que sigue.

Tres cosas que decidimos temprano

01

Una sola línea de producto, nunca un fork. En el momento en que deja que el despliegue de cada cliente se desvíe, tiene una consultoría disfrazada de producto, y el cliente con el entorno más viejo deja de recibir correcciones sin que nadie lo note. Cada cuenta corre la misma versión probada. Lo que cambia es la configuración —región, dominio, integraciones, feature flags— nunca el código.

02

Gestionado tiene que significar gestionado. Entregar un repositorio y llamarlo soberanía es pasarle la factura operativa al cliente. El pipeline lo llevamos nosotros: versiones, migraciones de esquema, rotación de secretos, monitoreo, actualizaciones. Sus ingenieros deberían escribir lógica de negocio, no operar una plataforma.

03

La salida tiene que ser real para contar. Un camino de migración que solo funciona mientras la relación va bien no es un camino de migración. Si desaparecemos mañana, la infraestructura sigue sirviendo, la base de datos sigue aceptando escrituras y su dominio sigue resolviendo —porque nada de eso fue nuestro en ningún momento.

El producto, de cerca

La propiedad es el sustrato. Esto es lo que su equipo abre cada mañana —idéntico en cualquier cuenta de nube donde esté corriendo.

Un solo lugar donde vive el contexto

Embudos, registros, contenido y responsables en una sola vista, en lugar de una hoja de cálculo que hay que cuadrar contra cinco pestañas del navegador. La dirección lee el estado sin pedirlo. Los operadores ven qué necesita atención sin que nadie se lo diga.

Una estructura que sobrevive al contacto con la realidad

Su modelo de datos del primer día es una suposición. Aquí las tablas, los filtros y las relaciones están hechos para editarse a medida que la suposición mejora, y los mismos registros de base alimentan cada vista de CRM, cada tarea y cada flujo de trabajo de la aplicación —así que cambiar la forma una vez la cambia en todas partes.

Los números, donde esté

Informes de verdad en el teléfono entre reuniones, calculados con las mismas definiciones que finanzas y operaciones ya acordaron en el escritorio. Cifras en vivo, no una hoja de cálculo que alguien exportó el martes.

Un tablero cuando las etapas importan más que las filas

Pase los mismos registros a una vista kanban cuando la pregunta es en qué etapa está algo. Tratos, tareas y contenido en un solo embudo, lo que termina con la discusión sobre cuál exportación era la definitiva.

Conectado con lo que ya usa

Facturación, CRM, herramientas de productividad, servicios de IA. Los datos se mueven en ambas direcciones de forma automática, lo que elimina la capa de copiar y pegar y el desacuerdo lento entre dos sistemas que cada uno se cree la fuente de verdad.

Cómo está construido

La ingeniería interesante en un producto bring-your-own-cloud no son las funciones. Es enviar la misma versión a decenas de cuentas que no son suyas, cada semana, sin romper ninguna.

  • Dos backends, una plataforma

    postgraph sobre Django y PostgreSQL para el trabajo relacional y analítico. nodegraph sobre Node y RethinkDB para datos en vivo y eventos. Cumplen el mismo contrato, así que un cliente puede usar uno, el otro o los dos sin que el front end note la diferencia.

  • La infraestructura como artefacto

    Toda la huella —red, base de datos, contenedores, balanceo de carga, CDN, certificados, DNS, secretos, configuración— es Terraform. Sube con un comando y baja con otro, que es también lo que vuelve creíble la salida.

  • Despliegues en orden estricto

    Primero la infraestructura, después los backends en paralelo, con las migraciones como tarea única y controlada antes de que ninguna imagen nueva entre en servicio. Si una migración falla, la imagen nueva nunca llega al servicio en marcha.

  • Evidencia, no garantías verbales

    “¿Qué hay en producción?” se responde con una versión fijada, un digest de imagen y un historial de despliegues que su equipo de plataforma puede entregarle a un auditor. Cada entorno sube al tren de versiones al ritmo que usted elija.

Hacia dónde va esto

Estamos construyendo hacia una apuesta bastante concreta sobre los próximos años.

La IA volvió urgente, y no académica, la pregunta de la propiedad. Para ser útil, un modelo tiene que leer los registros reales: los tratos, los documentos, el historial. Cada equipo está a punto de descubrir que el precio de una IA útil, con la arquitectura actual, es enviar todo su historial operativo a un tercero. Ejecutar el modelo donde ya viven los datos es la única versión de eso que sobrevive a una revisión de seguridad seria.

Así que la hoja de ruta apunta a que su cuenta sea el mejor lugar para hacer ese trabajo: la elección del modelo bajo su control, recuperación de información que nunca sale de su perímetro, y agentes que actúan sobre sus registros con los mismos permisos y el mismo rastro de auditoría que un usuario humano. Sus datos, su cómputo, su política.

El objetivo de fondo es más aburrido y más importante. Queremos software aburrido y bien operado que un equipo regulado pueda adoptar sin un desvío legal de seis meses —y ser la razón por la que un fundador deja de tratar la residencia de datos como lo que bloquea el contrato.

Si quiere una plataforma operada de extremo a extremo que nunca tome custodia de sus datos, hablemos.