Z
Zulma
Socia titularLleva la cartera de propiedades VIP y la relación con dueños históricos.
El software interno de una inmobiliaria boutique de Coghlan. Tres socios, una oficina de barrio, un sistema que respeta cómo trabajan.
Cantú Propiedades atiende compradores y vendedores de departamentos en Coghlan, Villa Urquiza y Belgrano R. Es una de esas inmobiliarias de cuadra que conocen a los porteros, saben qué edificio tiene problemas de humedad y se acuerdan del nombre del perro de cada dueño.
Son tres socios. Trabajan así desde hace casi treinta años, antes de que existieran los CRMs inmobiliarios.
Lleva la cartera de propiedades VIP y la relación con dueños históricos.
Muestra propiedades, conduce visitas, cierra operaciones.
Sostiene la agenda, confirma visitas, mantiene el contacto activo con todos.
Caso real. Nombres y datos modificados por confidencialidad.
Cuando nos contactaron, el negocio andaba. Pero andaba a fuerza de Zulma, Martín y Carolina compensando los huecos del sistema.
El Excel personal de Zulma con sus dueños VIP vivía en su laptop. Si la laptop se rompía, se iba con ella un patrimonio relacional de quince años.
El calendario impreso de Carolina ocupaba media pared de la oficina. Las visitas se anotaban a lápiz. Cuando Martín reagendaba algo desde la calle, Carolina se enteraba dos horas después por WhatsApp.
Los leads llegaban por seis canales distintos. Cuando alguien escribía por Instagram y después llamaba por teléfono, terminaba cargado dos veces sin que nadie se diera cuenta.
Los reportes mensuales para los dueños se hacían a mano. Cada mes. Cada vez.
Nada de esto los hacía mala inmobiliaria. Los hacía una inmobiliaria con un techo invisible: no podían tomar más propiedades sin romper la operación.
Hicimos tres entrevistas la misma semana. Una a cada socio, por separado. Aprendimos cosas que ni siquiera estaban en el brief.
El brief hablaba de cinco canales de leads: Zonaprop, Mercadolibre, web propia, redes, recomendación. En la entrevista con Zulma apareció el sexto: "referido por mí". Es distinto a recomendación porque viene de su círculo personal y arrastra un compromiso particular. Es información que Zulma no comparte con todos los leads del equipo.
Ese canal terminó siendo una columna propia con permisos restringidos.
En la entrevista con Martín nos enteramos de que él no carga datos. Pasa información por WhatsApp y Carolina la pasa al sistema.
Si construíamos pensando en Martín como usuario operativo del software, íbamos a fallar. El usuario operativo es Carolina, y todo el sistema tiene que pensarse para ella primero.
Don Eduardo Vázquez (no es su nombre real) lleva veinte años vendiendo y comprando exclusivamente con Zulma. Nadie más del equipo puede saber el precio de reserva, las notas internas ni el acuerdo especial de comisión. No por desconfianza, sino porque ese tipo de información personalizada solo se sostiene desde una relación.
Implementar confidencialidad asimétrica a nivel base de datos fue una decisión que vino directamente de esa charla.
Después del discovery, el alcance cambió. Algunas cosas del brief inicial salieron. Otras que el brief no mencionaba entraron.
Zulma ve todo, incluidos los acuerdos especiales. Martín ve lo operativo pero no los acuerdos. Carolina ve la agenda completa pero no las notas internas. La diferencia no se construyó ocultando botones en el frontend, se construyó a nivel de Postgres. Si alguien intenta acceder por consola SQL a algo que no le corresponde, la base devuelve cero filas. Es la única forma sostenible para una operación con confidencialidad real.
Cuando alguien empieza a escribir un teléfono que ya existe, el sistema avisa antes de guardar. Sale directamente del problema de Lucía Fernández (no es su nombre real), que aparecía cargada dos veces en planillas distintas.
Mensajes cortos asincrónicos del tipo "el dueño quiere subir el precio, llamarlo el lunes". Visibles para los tres, marcados como leídos por quien los vio. Es lo más cercano a tener a los tres en la misma oficina.
El brief la pedía. La evaluamos. La descartamos para esta etapa: implementar billing AFIP serio son tres meses más de trabajo y no es donde el negocio pierde plata hoy. Esa conversación, dicha de frente al cliente, fue una de las más importantes del proyecto.
Tener un número Business verificado por Meta lleva entre dos y tres semanas y nadie quiere depender del calendario de Meta. Quedó planificado para más adelante.
Por ahora las propiedades se cargan con URL externa. La próxima vuelta lo incluye.
Cantú no necesitaba un dashboard SaaS más. Necesitaba algo que se sintiera como su carta de presentación. Por eso el sistema de diseño no salió de un kit moderno: salió de una conversación sobre qué le inspira confianza a un dueño que está por dejarle una llave a una inmobiliaria.
La referencia visual fue la papelería editorial: portales arqueados británicos, sellos de inmobiliarias antiguas, carteles tipográficos hechos por imprenta. No por nostalgia. Porque ese vocabulario funciona como sinónimo visual de oficio.
Una serif italiana moderna con detalles editoriales. Aparece en direcciones, nombres de leads y cifras importantes. No la usamos por bonita, la usamos porque vuelve protagonistas a los datos.
Sans limpia, neutra, que no roba protagonismo. Mono para los números tabulares y los labels uppercase. Los precios alineados a la derecha en tabular nums se leen distinto.
Cream cálido como fondo, un negro cálido como tinta, un único color de acento (brick) que aparece solo donde la mirada tiene que ir. No hay azul. No hay violeta. No hay verde de "OK" ni rojo de "error". La sobriedad es la decisión.
Stack: Next.js 14 con App Router en el frontend y los endpoints de API. Supabase para base de datos (Postgres), autenticación y almacenamiento. Tailwind v3 para el sistema de estilos. Vercel para hosting y deploys.
La base de datos tiene nueve entidades principales y aproximadamente treinta y dos políticas de Row Level Security activas. Cada query que pasa por la app es filtrada por esas políticas en Postgres antes de devolver datos. La confidencialidad de Don Eduardo no depende de que el frontend recuerde ocultar un botón: depende de Postgres negándose a devolver esa fila si el usuario que consulta no es Zulma.
El deploy es continuo. Cada commit a la rama principal de GitHub deploya automáticamente. No hay servidores que mantener, no hay procesos manuales de release. Si rompemos algo, lo notamos en treinta segundos. Si arreglamos algo, está vivo en treinta segundos.
La demo pública se resetea cada veinticuatro horas. Hay un cron job que corre a las cuatro de la mañana, hora Argentina, y reinicia los datos demo al estado original. Cualquier visitante puede probar el producto sin ensuciarlo permanentemente.
Trabajamos con Claude Code como par de programación. La descripción precisa es esa: par de programación, no piloto automático. Acelera la implementación pero no toma las decisiones de producto.
Las decisiones que ven en el caso (sexto canal, confidencialidad asimétrica, módulo de novedades, qué dejamos afuera) salieron de las entrevistas y de la cabeza del estudio. Claude Code escribió la mayoría del código que las implementa.
El producto está en cantu.js80.studio. Tiene tres usuarios de demo:
Entrá con cualquiera de los tres haciendo un click en los botones grandes del login. No hace falta contraseña. Los datos se resetean cada noche.
Eso quiere decir que sigue evolucionando. Próximas vueltas:
JS80 es un estudio de soluciones digitales con base en Buenos Aires. Construimos productos completos para negocios reales: una idea, un equipo, una entrega que funciona.