Plataforma Inmobiliaria: DUNE CITY

#Dune City, una interfaz sobre una base de datos en movimiento

Trescientos treinta apartamentos. En un folleto esa cifra es una línea de marketing; en un modelo de contenido es el proyecto entero. Cada apartamento tiene superficie, planta, orientación, distribución, edificio, etapa de venta, estado y precio, y al menos la mitad de esos campos cambia con el tiempo. Un sitio de promotora no es, por tanto, un escaparate con fotografías: es una interfaz sobre una base de datos que sigue moviéndose mientras alguien la lee.

El complejo es Dune Resort, en Mielno, sobre la franja de arena que separa el mar Báltico del lago Jamno, unos diez kilómetros al norte de Koszalin. El inversor es Firmus Group y el proyecto arquitectónico salió de los estudios SAS y Mellon. Los apartamentos van de una a cuatro habitaciones, y el edificio B alberga una zona wellness de uso anual con piscinas interiores. El encargo cubrió la capa de identidad además del propio sitio, y por eso esta entrada aparece a la vez en la categoría de logotipos y en la de sitios web.

La implementación salió en 2017 y duró alrededor de seis semanas. Como desarrollador WordPress construí un tema a medida y los módulos que presentan la oferta. El layout y la colocación de los elementos los aportó el cliente; sobre esa base levanté las plantillas y el modelo de contenido.

#Qué decide la compra y qué no cabe en un formulario

Quien compra un apartamento frente al mar recorre el sitio al revés que quien reserva una habitación. No mira la oferta, la descarta. Llega con una restricción dura, normalmente el presupuesto o la superficie, elimina la mayor parte del inventario en el primer minuto y solo entonces empieza a mirar fotografías. Eso invierte la jerarquía habitual de una página: aquí el filtro es contenido de primer orden y la capa visual solo empieza a trabajar cuando la lista se ha reducido a una decena de posiciones.

El segundo criterio es espacial y no cabe en un formulario. En una promoción levantada sobre una franja de arena, lo que importa es en qué lado del edificio queda la vivienda, porque eso decide si la vista va al mar, al lago o al bloque contiguo. Ningún control deslizante formula esa pregunta. La selección tiene que poder hacerse sobre el plano de planta y sobre el mapa del terreno, no solo en una lista de resultados.

El tercer factor es propio de esta localización. Mielno es una localidad estacional, pero comprar un apartamento no es una decisión estacional, y una parte considerable de los compradores trata la operación como inversión para alquilar, no como segunda residencia. Son dos conversaciones distintas sostenidas sobre las mismas páginas. Quien compra para sí pregunta por la distribución y por el silencio; quien compra para alquilar pregunta cuántas semanas al año se puede arrendar la vivienda y si el edificio ofrece algo que alargue la temporada. La zona wellness de uso anual del edificio B responde exactamente a esa segunda pregunta, así que en la arquitectura de información no puede quedar como una tarjeta de equipamiento más junto al aparcamiento.

Queda la confianza. Una promoción vende algo que en el momento de la compra a menudo todavía no existe, o al menos no en el estado en que se entregará. Todo lo que el sitio presenta como hecho tiene que ser verificable o estar marcado con claridad como render. Es una decisión editorial con consecuencia técnica directa: los renders y las fotografías de obra tienen que ser distinguibles dentro del modelo de contenido, no volcados juntos en una misma galería.

#Funcionalidades clave y módulos

El módulo de mapas combina la integración con Google Maps API y la biblioteca Leaflet.js, y atiende tanto el mapa del terreno como los planos interactivos de planta. Separar ambas cosas es deliberado. El mapa del terreno responde a dónde está esto respecto a la playa y al paseo, y ahí los datos geográficos tienen sentido. Un plano de planta no es un mapa del mundo, sino una imagen con regiones pulsables, y empujarlo por el mismo mecanismo que un mapa termina en un escalado que se rompe en el teléfono.

La búsqueda y la ordenación se apoyan en campos personalizados y taxonomías, con los resultados recuperados de forma asíncrona mediante AJAX. El filtrado por varias dimensiones a la vez es el punto donde un catálogo inmobiliario suele venirse abajo, porque cada atributo añadido multiplica el número de combinaciones. Una implementación ingenua consulta la base una vez por cada interruptor, y con trescientos treinta viviendas y seis filtros eso se convierte en decenas de consultas por clic. Aquí el conjunto de valores disponibles se calcula una vez y se mantiene en memoria caché, y un cambio de filtro sustituye la lista de resultados en lugar de recargar la página.

La integración con sistemas externos por REST API sincroniza disponibilidad, estados de reserva y actualizaciones de la oferta. Es la parte más delicada de todo el montaje, porque la fuente de verdad sobre el estado no es el sitio, sino el sistema comercial de la promotora. Cualquier retraso en esa sincronización tiene un coste muy concreto: alguien llama por una vivienda vendida ayer y la primera frase de la conversación comercial es una rectificación.

Las herramientas analíticas muestran qué viviendas se consultan más y cómo se reparte el interés entre etapas. Para la promotora eso es información operativa, no un informe para una reunión: si una distribución concreta acumula visitas y no genera contactos, el problema está en el precio o en la descripción, y ambas cosas se pueden cambiar la misma semana.

La capa de rendimiento se apoya en memoria caché (Redis, Memcached) y en distribución de contenido mediante CDN. La tensión aquí es exactamente la contraria a la de un sitio de imagen: una web de promotora tiene que ser rápida y estar al día al mismo tiempo, y en arquitectura de caché esas dos propiedades tiran en sentidos opuestos.

#Soluciones técnicas y compromisos

El tema se construyó totalmente responsive y modular, sobre HTML5 y SASS. La modularidad no es aquí un adorno arquitectónico, sino una respuesta al ciclo de vida de este tipo de promoción. Las etapas se lanzan una tras otra, cada una recibe su edificio, su bolsa de viviendas y su campaña, y el sitio tiene que absorber una etapa nueva sin reconstruir las plantillas. Un proyecto donde el edificio A está escrito a fuego en una docena de sitios cuesta una semana en el edificio C en lugar de una hora.

La integración de datos de geolocalización exigió endpoints dedicados que devuelven la posición y los parámetros de cada vivienda para mostrarlos de forma dinámica sobre el mapa. La dificultad no está en dibujar puntos. Está en que el plano de planta y la lista de resultados tienen que mostrar el mismo estado: quien filtra viviendas de dos habitaciones espera que se iluminen en el plano exactamente esas. Mantener una sola fuente de estado para dos vistas tan distintas es el trabajo real.

El procesamiento asíncrono mediante AJAX y REST API mejora la comodidad de navegación y se paga en un lugar fácil de olvidar. Los resultados de un filtro cargados sin recarga no tienen dirección propia, así que no se pueden enviar a nadie ni indexar. La respuesta consiste en reflejar el estado de los filtros en la URL y devolver una respuesta completa del servidor para una entrada directa, manteniendo la vía asíncrona para los cambios siguientes. Eso es aproximadamente el doble de trabajo que la capa AJAX por sí sola, y la única manera de que los resultados existan fuera de una sesión de navegador.

La estructura de direcciones merece párrafo aparte, porque decide si la promoción existe en buscadores más allá de su propio nombre. Nadie busca el nombre de una promoción antes de conocerlo: busca un apartamento de dos habitaciones en Mielno con vistas al mar. Eso significa que las combinaciones de filtros tienen potencial de búsqueda real, pero solo algunas. Todas a la vez producen miles de direcciones casi idénticas, que es la forma clásica de diluir un sitio. La salida es elegir una docena de combinaciones que correspondan a preguntas que la gente escribe de verdad, darles dirección y contenido propios, y dejar el resto del espacio de filtros fuera del índice.

Conviene nombrar el compromiso de caché sin rodeos, porque es el que define este proyecto. Las descripciones, las fotografías, los planos y el texto de marketing pueden quedarse en memoria caché durante semanas. El estado y el precio de una vivienda no pueden quedarse ahí ni una hora. Si ambas capas caen bajo una sola política, la política tiene que seguir a la más corta, lo que equivale a renunciar a la caché para la mayor parte del contenido, que nunca la necesitó. Separarlas significa que el esqueleto de la página y la galería salen del borde de red, mientras que el fragmento con el estado llega en una petición aparte y barata.

La medición del rendimiento significa aquí otra cosa que en un sitio corporativo. La vista más pesada no es la portada, sino la lista de resultados una vez aplicados los filtros, y esa vista no tiene dirección fija, así que una auditoría estándar de portada nunca llega a ella. Las pruebas tienen que seguir los caminos por los que circula el tráfico, y preferiblemente sobre una copia de producción con el inventario completo cargado. En una instalación vacía con diez viviendas de ejemplo todo va rápido y no se aprende nada.

El comportamiento en campaña es la segunda medición que conviene planificar. La promotora lanza publicidad sobre una etapa y en una hora una sola subpágina recibe más tráfico que en todo el mes anterior. Ese patrón es previsible, así que se puede atender barato: la página de etapa es cacheable por completo salvo el fragmento de estado, y ese fragmento es ligero. Sin esa separación, la misma campaña significa pagar capacidad de servidor por un día.

El móvil merece una nota, porque el primer contacto con la oferta ocurre en el teléfono mientras la compra se cierra en un ordenador. Un plano de planta en una pantalla de cuatrocientos píxeles es ilegible si se trata como una imagen para desplazar. Las regiones pulsables tienen que tener tamaño de dedo y no de cursor, y en una pantalla pequeña eso suele significar que el plano deja de ser un mapa y se convierte en una lista con resaltado. No es una versión móvil simplificada, es otra respuesta a la misma pregunta del usuario.

#Nuestras acciones

Para Dune City entregamos el sitio con sus módulos de mapa, la búsqueda y la sincronización externa, de forma que alguien pueda comprobar la oferta vigente sin recorrer a mano una docena de subpáginas, además de la capa de identidad alineada con el resto de materiales de la promoción.

El trabajo se diferenció de un sitio corporativo habitual porque el contenido se produjo en paralelo a la obra. Los planos cambiaron durante el proyecto, algunas viviendas se renumeraron y la fotografía llegó por fases. El modelo de contenido tenía que soportar que una misma posición lleve primero un render, después una fotografía de obra y al final un interior terminado, sin que ninguna de esas sustituciones obligue a tocar una plantilla.

La numeración de viviendas es lo que más a menudo se rompe un año después del lanzamiento, y no el día del lanzamiento. Cambia durante la obra con más frecuencia de la que nadie supone al diseñar el modelo de datos, y si el identificador de la vivienda es también el número que ve el cliente, cada cambio rompe enlaces que ya circulan por correo y en documentación comercial. Separar el identificador interno de la etiqueta visible cuesta un campo en la base de datos y ahorra una semana de correcciones.

La fotografía es el segundo de esos lugares. Las sesiones de interiores suelen hacerse después de entregar el primer edificio, así que el sitio vive de renders durante más de un año. El momento del cambio es crítico para la credibilidad: si renders y fotografías comparten galería, lo que queda después es una mezcla en la que nadie sabe qué está mirando. Por eso ambos tipos de material tienen estado propio en el modelo de contenido y la vista puede mostrarlos en paralelo con un pie claro.

El tercero es la lista de precios. Las promotoras cambian precios por etapas y a menudo prefieren no publicarlos completos, entregándolos tras un contacto. Eso obliga a que el precio sea un campo aparte con su propia regla de visibilidad, y no un párrafo escrito dentro de la descripción. Los tres casos comparten naturaleza: lo que cambia de forma independiente tiene que ser su propio campo, o cada cambio se convierte en trabajo de redacción en una docena de sitios a la vez.

#Resumen

Dune City es un proyecto donde la capa de presentación es la parte menos interesante del trabajo. La dificultad vive en el modelo de datos, en sostener un solo estado a través de la lista, el plano y el mapa, en la sincronización con el sistema comercial y en separar lo que se puede cachear de lo que tiene que estar fresco. En esta página tampoco hay métricas de resultado. El número de contactos, el ritmo de ventas y los porcentajes de crecimiento pertenecen al inversor y no al caso de estudio de quien ejecuta, y ninguno podría atribuirse aquí a una fuente comprobable. Lo que sí se traslada al siguiente proyecto es el orden de las preguntas: establecer qué cambia y con qué frecuencia, y elegir la tecnología después.

Una parte del complejo la gestiona un operador de alquiler, City Apartments, con cerca de doscientas cincuenta viviendas bajo administración. Eso cambia el destinatario del sitio a mitad de su vida. La misma dirección sirve a un propósito distinto cuando termina la venta del que servía en fase de promoción, y la arquitectura de información tenía que preverlo en lugar de suponer que el sitio muere con la última vivienda vendida. Quien compró para alquilar sigue necesitando páginas que describan el edificio y su entorno mucho después de que no quede nada a la venta. Las dos direcciones habituales para ampliar un montaje así son una integración más profunda con el sistema comercial, que elimine el paso manual de actualización, y el soporte de la fase posterior a la venta. Cada una es un alcance aparte, presupuestado tras análisis.

Queda una pregunta que conviene hacerse antes de elegir framework en un proyecto de este tipo. Dentro de dos años, cuando arranque un edificio nuevo, ¿podrá alguien añadirlo sin un programador en la sala? La respuesta se decide en el modelo de datos y no en la capa visual, y se decide al principio.