Cómo Crear un Comparador de Propiedades Inmobiliarias con Python y JavaScript

Casascope: Diseño y desarrollo de una plataforma inteligente para el análisis inmobiliario

Tomar decisiones informadas en el mercado inmobiliario puede ser un reto: la información suele estar dispersa, es difícil comparar propiedades de manera efectiva y muchas plataformas priorizan la cantidad sobre la calidad de la experiencia de usuario. En este contexto, surgió la idea de casascope, una plataforma web creada para facilitar la visualización, comparación y análisis de propiedades inmobiliarias, combinando filtros avanzados, visualizaciones interactivas y un diseño elegante y funcional.

El objetivo de este post es compartir el proceso técnico detrás de casascope: desde la definición del problema, pasando por la arquitectura y las decisiones tecnológicas, hasta los retos y aprendizajes obtenidos. El código se encuentra en un repositorio privado.

¿Por qué crear casascope?

El mercado inmobiliario está saturado de portales que ofrecen grandes listados, pero muy pocos permiten comparar propiedades de manera visual y profunda. Como usuario, quería responder preguntas como:

¿Qué zonas ofrecen mejor relación calidad/precio para mi perfil?
¿Cómo evoluciona el precio por metro cuadrado en diferentes áreas?
¿Puedo filtrar y comparar propiedades según criterios personalizados y ver tendencias?

Las plataformas existentes no cubrían bien estos puntos, así que decidí diseñar una herramienta que pusiera la experiencia de análisis y la visualización de datos en el centro.

Arquitectura técnica: un stack moderno y flexible

¿Qué stack tecnológico elegí y por qué?

La arquitectura de casascope necesitaba ser:

Interactiva: para visualizaciones dinámicas y filtros en tiempo real.
Escalable: para incorporar nuevas fuentes de datos y funcionalidades fácilmente.
Mantenible: usando tecnologías conocidas y bien soportadas.
Flexible: para integrar tanto scraping de datos como futuras APIs.

Tecnologías principales

Frontend:

- JavaScript (con TypeScript en componentes clave): robustez y typing.

- HTML + CSS: diseño responsive y elegante.

- Librerías de visualización:

- D3.js para gráficos personalizados.

- Leaflet para mapas interactivos.

Backend:

- Python: ideal para el procesamiento de datos y scraping.

- Flask: microframework para endpoints API ligeros.

Persistencia:

- SQLite (fase inicial) por simplicidad; migrable a PostgreSQL para producción.

Otros:

- Node.js (para ciertas tareas asíncronas y procesamiento paralelo).

- Docker (para facilitar el despliegue y reproducibilidad).

Esquema general de la arquitectura

graph TD
    A[Scraper Python] -->|Procesa datos| B[Base de datos SQLite]
    B -->|APIs REST| C[Backend Flask]
    C -->|JSON| D[Frontend JS/TS]
    D --> E[Usuario: visualización y filtros]

Loading diagram...

Componentes principales del sistema

1. Scraper y procesamiento de datos (Python)

Para poblar la base de datos con propiedades reales, desarrollé un scraper en Python capaz de:

Navegar portales inmobiliarios públicos (respetando términos de uso).
Extraer información relevante: precio, ubicación, superficie, características, imágenes, etc.
Normalizar y limpiar datos, gestionando inconsistencias frecuentes (por ejemplo, superficies mal formateadas o precios en diferentes monedas).
Enriquecer los datos calculando métricas adicionales como precio por m² o ratio de crecimiento.

Snippet: extracción y normalización de datos

python

1def parse_price(raw_price):
2    # Elimina símbolos y separadores, convierte a float
3    clean = raw_price.replace('€', '').replace(',', '').strip()
4    return float(clean)
5 
6def normalize_listing(listing):
7    return {
8        "title": listing.get("title", "").strip(),
9        "price": parse_price(listing["price"]),
10        "surface": float(listing["surface"].replace("m²", "").strip()),
11        # ... otros campos
12    }

2. Backend API (Flask + SQLite)

El backend expone endpoints REST para:

Listar propiedades filtradas por parámetros: precio, zona, superficie, etc.
Obtener estadísticas agregadas (medias, tendencias históricas).
Servir datos geolocalizados para mapas.

Snippet: endpoint de búsqueda avanzada

python

1@app.route('/api/properties', methods=['GET'])
2def search_properties():
3    min_price = request.args.get('min_price', 0)
4    max_price = request.args.get('max_price', 1e7)
5    # ... otros filtros
6    query = """
7        SELECT * FROM properties
8        WHERE price BETWEEN ? AND ?
9        -- otros filtros dinámicos
10    """
11    # Ejecutar query y devolver resultados como JSON

3. Frontend interactivo (JavaScript/TypeScript)

La interfaz de usuario fue una prioridad: debía ser clara, intuitiva y potente. Algunos elementos clave:

Filtros avanzados: sliders, selectores de zona, checkbox de características.
Visualizaciones interactivas:

- Gráficos de precios históricos y comparativas usando D3.js.

- Mapa con propiedades geolocalizadas y agrupamiento por zonas.

Comparador: permite seleccionar varias propiedades y verlas lado a lado.

Snippet: renderizado reactivo de filtros y mapa

typescript

1function updateMap(filteredProperties: Property[]) {
2    markersLayer.clear();
3    filteredProperties.forEach(prop => {
4        const marker = L.marker([prop.lat, prop.lng])
5            .bindPopup(`<b>${prop.title}</b><br>€${prop.price}`);
6        markersLayer.addLayer(marker);
7    });
8}

Decisiones técnicas clave

Durante el desarrollo, hubo varias decisiones que marcaron el enfoque:

Separación de scraping y visualización: Evité mezclar el scraping con la app web, usando Python para la obtención y preprocesamiento, y sólo sirviendo datos ya limpios al frontend.
Uso de TypeScript en el frontend: Si bien muchos componentes están en JavaScript, incorporar TypeScript en las partes críticas (como el manejo de datos y lógica de visualización) elevó la robustez y mantenibilidad.
Visualizaciones personalizadas vs. librerías estándar: Aposté por D3.js en vez de librerías "plug-and-play" para tener control total sobre los gráficos y animaciones.
Persistencia simple inicialmente: SQLite permitió iterar rápido, aunque tengo claro que para escalar o multiusuario es necesario migrar a una base relacional potente como PostgreSQL.

Retos técnicos y cómo los resolví

1. Normalización y limpieza de datos

Los portales inmobiliarios suelen tener datos inconsistentes: superficies mal escritas, precios en diferentes formatos, ubicaciones ambiguas… Implementé múltiples funciones de parsing y validación, y un sistema de logging para detectar y corregir casos problemáticos.

2. Rendimiento de las consultas filtradas

Con cientos o miles de propiedades, los filtros complejos podían ralentizar la respuesta. Optimizé las queries SQL y añadí índices en los campos de búsqueda más frecuentes (precio, zona, superficie), logrando tiempos de respuesta <300ms incluso con filtros múltiples.

3. Sincronización de datos en frontend

Me encontré con problemas de sincronización entre los filtros activos y las visualizaciones (especialmente cuando hay cambios rápidos). Usar un estado global bien gestionado (con hooks personalizados en JS/TS) y debouncing en los inputs resolvió estos glitches.

4. Mapas y geolocalización

Algunas propiedades carecían de coordenadas precisas. Implementé una llamada a la API de OpenStreetMap Nominatim para obtener la lat/long a partir de direcciones, y añadí un sistema de caché para no saturar la API.

Resultados y métricas

Aunque casascope está en una fase temprana, ya permite:

Visualizar cientos de propiedades de manera fluida.
Comparar propiedades por múltiples criterios con una experiencia rica.
Explorar tendencias de precios y zonas con gráficos y mapas.
Filtrar en tiempo real con latencia mínima.

Impacto inicial:

Durante pruebas internas y con usuarios beta (agentes y compradores particulares), se reportó:

Mejor comprensión del mercado: gracias a la visualización clara de datos y comparativas.
Ahorro de tiempo: en la búsqueda y análisis de propiedades relevantes.
Feedback positivo sobre la interfaz: destacando la usabilidad y el look & feel.

Aprendizajes y mejoras futuras

Lo que aprendí

La importancia de la calidad de datos: sin datos limpios, hasta la mejor visualización pierde utilidad.
Lo útil que es modularizar el scraping y el backend, para iterar rápido y mantener el sistema.
El valor de visualizaciones personalizadas: permiten insights que las tablas tradicionales no muestran.

Próximos pasos

Migrar a PostgreSQL para mejor escalabilidad y manejo de usuarios.
Integrar APIs públicas para enriquecer el dataset (transporte, servicios cercanos…).
Añadir autenticación y favoritos para usuarios registrados.
Optimizar el scraper para detectar cambios en las propiedades y mantener el dataset actualizado.

Conclusión

Desarrollar casascope ha sido una experiencia muy enriquecedora, que combina scraping, backend, data engineering y UX/UI. Si te interesa saber más sobre la plataforma, no dudes en contactarme (el repositorio es actualmente privado).

¿Tienes dudas técnicas o sugerencias? Me encantará leerte en los comentarios o issues del repo 🚀

Javier Santos Criado

Ingeniero de IA & desarrollador full-stack

Apasionado por crear soluciones prácticas usando tecnología