01 — CONTEXT
El contexto
Una agencia inmobiliaria necesita mucho más que publicar propiedades: catálogo, búsqueda, captación de leads, seguimiento comercial, idiomas, analítica y administración forman parte del mismo sistema.
02 — PROBLEM
El problema
Construir una plataforma distinta para cada agencia multiplica el código, el mantenimiento y cada mejora. La alternativa era un único núcleo capaz de adaptarse a cada negocio sin mezclar nada entre ellos.
03 — CONSTRAINTS
Las restricciones
- 01Cada agencia conserva su identidad: colores, logo, tipografía y textos propios.
- 02Cada agencia llega por su dominio o su subdominio y ve solo lo suyo.
- 03El aislamiento entre agencias no puede depender del frontend.
- 04Contenido en español, inglés y portugués.
04 — SYSTEM
Qué decidí construir
Una arquitectura de un solo núcleo y varios inquilinos: una única aplicación Nuxt que identifica la agencia por el dominio de la petición y carga su configuración, su marca, sus permisos y sus datos.
05 — ARCHITECTURE
Arquitectura del sistema
SOFTWARE
Software
- Web pública por agencia: catálogo, fichas de propiedad, mapas, favoritos y onboarding.
- Panel de agencia con dashboard, leads con estados, propiedades, ubicaciones y textos.
- Superadministración para crear y clonar agencias y configurar su marca.
- Emails a la agencia en su idioma con las propiedades que ha visto cada lead.
DATA
Datos
- Supabase sobre PostgreSQL con Row Level Security: cada fila pertenece a una agencia.
- Borrado lógico y visibilidad por estado: lo archivado o en borrador no llega a la web pública.
- Leads con las propiedades vistas y las preferencias inferidas de la navegación.
- Dashboard con propiedades más vistas, leads por origen y mapa de actividad.
AI / AUTOMATION
IA y automatización
- Búsqueda en lenguaje natural: «villa con piscina en Marbella hasta 500k» se convierte en filtros de tipo, zona, precio y características.
- Los filtros aparecen como chips editables y los resultados se actualizan al escribir.
- Captación proactiva: cuando el visitante muestra intención, el sistema le pide el contacto y adjunta lo que ha visto.
- Leads «calientes» señalados en el panel a partir de su actividad.
La interpretación de la búsqueda no depende de un modelo de IA: se resuelve con reglas, rápida y predecible.
06 — DECISIONS
Decisiones importantes, y por qué
El aislamiento, en la base de datos
Ocultar datos en la interfaz no es seguridad. Las políticas RLS impiden que una agencia lea o escriba filas de otra aunque una consulta llegue mal formada.
La agencia se resuelve en el servidor
Un middleware identifica la agencia por dominio propio, subdominio o URL registrada antes de pintar nada. La web no sabe que existen otras agencias.
Marca como configuración, no como código
Colores, logo, tipografías y textos viven en datos. Una agencia nueva no necesita un despliegue nuevo.
Las rutas del panel también comprueban
RLS es la primera barrera; además, cada ruta del panel valida la sesión, la agencia y el rol antes de consultar.
07 — RESULT
Resultado
- Una plataforma vertical reutilizable: varias agencias sobre el mismo núcleo, cada una con su marca y sus datos.
- Las agencias nuevas se crean o se clonan desde el panel de superadministración, sin construir un producto nuevo.
- Pendiente, y documentado como tal: la gestión de dominios propios desde el panel y la facturación.
Sin cifras de negocio inventadas: lo que se muestra es lo que existe y está documentado.
08 — STACK
Stack técnico
- Nuxt 4
- Vue 3
- TypeScript
- Supabase
- PostgreSQL
- RLS
- Tailwind CSS
- i18n
- Leaflet
09 — SIMILAR PROBLEMS
Qué problema parecido puedo resolver
- →Varias marcas, delegaciones, franquicias o clientes necesitan el mismo sistema con datos separados.
- →Mantienes versiones casi iguales de una misma web o aplicación, una por cliente.
- →Necesitas que cada cliente vea solo lo suyo y que eso no dependa de la interfaz.
Este proyecto es un ejemplo de software a medida y datos e inteligencia.
