El contrato es el núcleo de Nester. También era su parte más rígida.
La única opción era subir un PDF redactado fuera de Nester: sin poder editarlo, verlo ni borrarlo desde la plataforma. Era un archivo muerto adjunto a un registro, desconectado de los datos de propietarios, inquilinos e inmuebles que el sistema ya tenía.
Los gestores de propiedades rehacían el mismo documento una y otra vez, copiando datos que la plataforma ya guardaba. Las agencias y family offices con más de 10 plantillas lo pedían constantemente.
No era un extra: era algo básico que el sector esperaba, y todavía no lo teníamos.
Una sola plantilla tenía que funcionar para contratos que nunca son iguales.
Un número que nunca es fijo
Un contrato puede tener un propietario o cinco. Un inquilino o cinco. Un inmueble o varios. Ese número solo se conoce cuando el gestor rellena el contrato, nunca al crear la plantilla. Si diseñas para un número fijo de partes, el primer contrato que no encaje en el molde lo rompe.
Dos sistemas, una sola fuente de verdad.
Smart blocks frente a variables indexadas
Ambos sistemas leen del mismo lugar: el conjunto de propietarios, inquilinos e inmuebles asociados a ese contrato. Los smart blocks resuelven la parte que no se puede fijar de antemano: el gestor escribe una cláusula una vez y esta se repite para todas las partes que acabe teniendo el contrato, una o diez, con la gramática (comas, “y”) concatenada automáticamente. Las variables indexadas resuelven el caso contrario: partes que no son intercambiables, a las que se hace referencia de forma individual, hasta cinco: “el propietario 1 entrega las llaves, el propietario 2 recibe las notificaciones”.
La regla: si el texto se repite igual para cada parte, es un smart block; si las partes tienen roles distintos y ordenados, es una variable indexada.
Parte del front-end todavía funcionaba con Laravel y Bootstrap 4, en plena migración a Next.js: por eso elegimos TipTap para el editor y variables en forma de chips en lugar de texto plano. Antes de escribir una sola especificación, usé Claude y Lovable para probar la lógica gramatical en casos límite —un propietario frente a cinco, géneros mixtos, nombres inconsistentes—, de modo que estaba validada antes de empezar el desarrollo.
Todas las variables del sistema, a un menú de distancia
El slash menu muestra todo lo que Nester ya sabe —datos del inmueble, propietario, inquilino y contrato— organizado en siete categorías, para que el gestor nunca tenga que buscar un campo. Si algo todavía no está en el sistema, el mismo menú permite crear al momento una variable personalizada —o incluso una categoría nueva— y rellenarla a mano sin salir del documento.
Un código de colores para que un documento legal nunca salga a medias
Cada variable se resuelve con datos reales al crear el contrato y se marca en azul (dato existente, editable), amarillo (variable personalizada) o rojo (obligatoria, falta). La decisión de producto detrás: el contrato no se puede aceptar mientras queden campos en rojo. Un documento legal con huecos no es un bug de UI: es un riesgo real para el negocio.
Se construye una vez. Se reutiliza en cada contrato.
El editor de plantillas
Un editor tipo documento (TipTap), con las variables organizadas en 7 categorías —inmueble, propietarios, inquilinos, condiciones del contrato, datos financieros, extras y smart blocks—, además de la posibilidad de crear variables y categorías personalizadas cuando el sistema no cubre algo.
El documento en sí se puede personalizar con la marca, no solo rellenar. Se pueden mostrar los logos de la empresa y de los propietarios en la cabecera —a la izquierda, al centro o a la derecha, solo en la primera página o en todas—, y el sistema toma automáticamente el logo de cada propietario de su ficha. Un pie de página incluye un texto legal fijo o los datos de contacto de la agencia, repetido en cada página, con la numeración automática debajo. Un selector tipográfico (cinco tipografías) se aplica a todo —cuerpo del contrato, pie y numeración— y se actualiza en directo mientras el gestor lo ajusta, antes de exportar nada.
Crear un smart block abre un modal con tres pestañas: propietarios, inquilinos e inmuebles. El alias legal añade un sufijo automático cuando un bloque se repite entre varias partes (así “Propietario” pasa a ser “Propietario 1”, “Propietario 2” sin que el gestor tenga que nombrarlos), y la vista previa resuelve el bloque con dos registros de prueba reales lado a lado, para que el gestor vea exactamente cómo se concatena la gramática antes de guardarlo.
De la plantilla a un contrato listo para firmar
Al crear un contrato, el gestor elige una plantilla o sube un PDF. Si elige una plantilla, se abre la vista previa dinámica con el código de colores descrito arriba, y puede resolver cualquier campo pendiente directamente sobre el documento, sin salir de la vista previa.
La adopción respondió a la pregunta que no podíamos hacer directamente.
En los dos primeros meses tras el lanzamiento se crearon 60 plantillas de contrato distintas: una señal clara de que el problema era real. Los gestores no solo adoptaron la funcionalidad, sino que la adaptaron activamente a su propia operación, en distintos tipos de alquiler, regiones y perfiles de cliente.
Una pieza del ciclo de vida del contrato, no todo
Contract Templates resolvió cómo se construía un contrato dentro de Nester, pero construirlo bien no era lo mismo que cerrarlo. Los gestores ya tenían una forma rápida y precisa de generar un contrato, pero el ciclo no se completaba hasta que se firmaba. Ese hueco es el que recogió el siguiente proyecto: llevar la propia firma dentro de la plataforma.
Lo difícil nunca fue hacer que funcionara. Fue hacerlo comprensible.
Los smart blocks y las variables indexadas hacen el mismo trabajo técnico: convertir datos en texto. El verdadero reto de diseño fue construir algo en lo que una persona sin perfil técnico pudiera confiar para un documento legal: visible, editable y en el que equivocarse no tuviera consecuencias antes de firmarlo.
